Justus Spitzmüller

Hello, It is not clear to me from the table which tools are involved. Please always reference them with library name and ID e.g. ta_morphometry 14. The corresponding output then with the identifier e.g. HU which can be taken from the description in the properties window. I can't find the ones you assigned in the table in any of the tools. As a pure guess, however, I would say that the (height) results are in the same unit as the input data set. If the DEM has stored the heights in meters, the result...

Greetings, I also assume that many of SAGA's previous applications would run significantly faster on a GPU. However, running an application on a GPU usually means completely re-implementing this application. The two papers you mentioned used CUDA and OpenGL respectively for this. This is not viable for us in this form. The favored solution would be to use the offloading functions of the multiprocessing library OpenMP, which we already use for multi threading on the CPU. OpenAAC also looks promising...

I see that GDAL simply extends lines/polygons horizontally or vertically to the grid edges Okay good to know. But I believe that the proper way is to extrapolate or extend contours as in the another attached image (blue lines). No this is not the popper way. We will not extent or extrapolate the contour line. You will have to use tiling. This is the only proper way to handle this in my opinion. Also, overlap will not help on the outer edges of gridded data, because there will be no overlap there....

I see that GDAL simply extends lines/polygons horizontally or vertically to the grid edges Okay good to know. But I believe that the proper way is to extrapolate or extend contours as in the another attached image (blue lines). No this is not the popper way. We will not extent or extrapolate the contour line. You will have to use tiling. This is the only proper way to handle this in my opinion. Also, overlap will not help on the outer edges of gridded data, because there will be no overlap there....

This solution is kinda hacky so please take it with a grain of salt. You could copy the column at the meridian and then manipulate the metadata. For example if you have a .sg-grd file extension you cloud open it in a text editor an offset the POSITION_YMIN Value so it wraps around the dateline.

I'am sure this will be answered properly in the next days. I see no need for a feature request.

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. I don't think the filter is useless. As i said in this thread I understand the problem, but I can't say how much effort it would take to adapt the tool as suggested Note: I am not the author of the tool. And while my employer welcomes my participation in the open source project and...

I suppose that in both options there will be a problem with attributes. Can you explain this further? What problems are you seeing? 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. 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...