Menu
▾
▴
#84 Filter in 'Contour Lines from Grid' tool
It would be very useful to have a filter in 'Contour Lines from Grid' tool. Because almost always the tool produces very small features that are useless on the map, a sort of noise from points and tiny objects.
One of the possible options to add a parameter that allow to specify a minimum number of raster cells eligible to be used in contour line creation. With this option user can filter out all features that too small to be shown on the map.
Hi,
couldn't you simply calculate line length and filter per length afterwards?
Hi Volker.
I'm afraid this solution is not suitable for cases when not only contour lines generated, but also polygons. In this case post-processing becomes a problem (including holes in polygons after filtering). I have no idea how to get the same filtering results in this case so that the contour lines and polygons completely match.
Just to illustrate the need for the proposed filter, I've attached the image. With the proposed filter, it would be possible to clear the image of small details whose values (positive or negative landform) cannot be determined due to their size.
Such a filter is implemented in the cut parameter of GRASS 'r.contour' tool.
So when it comes to removing small polygons, I would also suggest post-processing with the tool "Polygon Generalization" from the "Polygons" library. There you can set the "Area threshold" and too small ones are then merged with the neighbors.
Justus,
this is good solution, but this solution is valid for polygons only. In my case I need polygons and contour lines (with additional intermediate levels added) separately. Because of the large amount of data it's processed by many tiles via command line. Due to external boundaries polygons are used for fill only, then contour lines are placed on top of them.
In such situation obtaining identical polygons and contour lines seems very problematic. So I believe that filtering during contours/polygon creation would be the right solution.
Okay then, I would suggest not to mix the two vector forms when generating the contour lines. For example, you could only generate lines and then filter them as suggested by Volker . And then use Polygon-Line Intersection to split the extent of the grid for the filling.
Or you work only with polygons, filter them with my suggested solution and then transfer them with Convert Polygons to Lines into the lines.
If you want the Filling to have less contours between the levels, you can also make two passes and then "merge" them with Union and then transfer to lines (Make sure that there are no identical levels because of the overlapping).
Maybe this also solves your tiling problem because you can do the steps described above in vector space and thus work on all objects at once in a realistic way by dissolving all the tiles at the end?
Last edit: Justus Spitzmüller 2023-10-31
Thanks for the suggestions.
First of all, in any case I'll have to work with tiles for performance reasons and hardware limitations. And I'm not very familiar with scripts.
I suppose that in both options there will be a problem with attributes.
In second option with polygons to lines conversion all unwanted outer lines of polygons will remain, which will need to be removed.
Unfortunately, all of this is complicated by extent issue.
Can you explain this further? What problems are you seeing?
Therefore, select a sufficient overlap. The extent problem mentioned is also "only" half a cell. If every tile with sufficient overlap has contour lines as polygons and these are then dissolved, in my opinion there should be no unwanted outer lines within the data set.
With the dissolve tool, the attribute can also be selected so that the neighbouring classes of the same level will blend with each other.
I'm sorry, with polygons to lines conversion there are no problems with attributes. But polygons to lines conversion produces duplicated lines which is undesirable. Thus, a new task arises: somehow get rid of duplicates while preserving the respective attributes.
I can't check the attributes in the result of a 'Polygon-Line Intersection' because the execution on one fragment is already taking over 2 hours. I'll let you know when it's finished (if it succeeds).
Dissolving such a large amount of data is not desirable for performance reasons. I understand that this step needed as a workaround because of 'Contour lines from Grid' extent issue. But I need the data to be split back into tiles. Even if we dissolve all world data there will be an outer border (like in image attached).
Thus, what we have:
1. Generate polygons for fill.
2. Dissolve polygons for fill.
3. Generalize polygons for fill.
4. Split polygons for fill into tiles.
5. Generate polygons for lines.
6. Dissolve polygons for lines.
7. Generalize polygons for lines.
8. Remove duplicated lines somehow (while preserving the attributes).
9. Remove outer border somehow.
10. Split lines into tiles.
10 steps instead of 2 (generate polygons for fill and generate contour lines) with the proposed filter implemented. I think this is irrational.
It's a pity, but it looks like you think the suggested filter is useless.
Note. Half a pixel is a real problem when you need to display data several zooms higher. Half a pixel west of 180° meridian and half a pixel east of 180° meridian, then 4x zoom up and you get a strip of 16 pixels of emptiness.
I don't think the filter is useless. As i said in this thread
Note: I am not the author of the tool. And while my employer welcomes my participation in the open source project and maintenance of SAGA. It will not be welcomed if i code your solutions, because you are not willing to build a processing pipeline and also i don't want to do it in my spare time, sorry.
So my involvement in this thread boils down to: "Hey if nobody in the community can help you: This are the steps for a workaround"
Speaking of workarounds: If you only need the polygons for filling you could categorize your elevation levels on grid scale an than Vectorizing Grid Classes.
You could use an Overlap and then Clip the Extent. Or Resample your grid and make it half a pixel bigger.
Actually, this thread and the thread you mentioned are about different things in one tool. I just found an issue with extent and reported it, and also suggested adding a filter. I really believe that this will be useful not only for me.
I understand that SAGA is open source software and that it's up to the developers to decide whether to do something or not. And I'm just waiting for their decision.
Justus, I really appreciate you trying to help me. But please understand me right: even with all my will I'm simply not able to implement this processing pipeline, because it's very difficult for me. Thank you for your help.