#85 Grid extent option for 'Contour Lines from Grid' tool

[Andrey]

Dear developers,

because any grid have two different registration types (node (point) / cell (area)) it's useful to have an appropriate option in the 'Contour Lines from Grid' tool. (Only for readers unfamiliar with the grid cell registration I've attached an image taken from Grid Cell Registration by NCEI.)
Currently this tool produces output suitable only for node-registered grids. For cell-registered grids the output is less than the grid extent. This may be critical, especially for the whole world data or for tiled data with no overlap. In the latter case an extent of 1/2 pixel on each side of the combined grid will be lost anyway.

[Andrey]

Attached image.

[Volker Wichmann]

Hi Andrey,

the node vs. cell registration is just about how the (e.g.) lower left coordinate of a dataset is referenced - this coordinate can either represent the lower left corner of the cell area or the lower left grid node.

Elevation data is in both cases only available at the cell centers, i.e. the grid nodes. The contour tool requires to interpolate elevations, and this is only possible at the cell centers (grid nodes). So your request does not help with your problem (you've posted in the forum). If you require your contour lines to reach out to the edge of the cell area, you must process your data with an overlap of one cell and clip the contours afterwards. Then they will perfectly match at tile borders.

As SAGA is very powerful regarding automated processing, this can be easily achieved by scripting. As there is no other solution, I close this feature request.

Best regards,
Volker

[Andrey]

Hi Volker,

actually, this request does help with problem. Moreover, this is how gdal_contour works.
Also, overlap will not help on the outer edges of gridded data, because there will be no overlap there.
Unfortunately, the 'Contour Lines from Grid' tool often produces incorrect polygons, and is therefore almost useless for that.

[Volker Wichmann]

Hi Andrey,

what leads you to the assumption that gdal_contour works like this? I just had a quick look at the sources and found this:

https://github.com/OSGeo/gdal/blob/master/alg/contour.cpp#L396

... so it also seems to work on grid nodes. And how should something work on outer edges when there is simply no data available to compute something? You could apply some tricks like duplicating the outermost cells etc. but that will not give correct results (and would also show artifacts at tile borders). The only correct way to solve this is to prepare your input data accordingly. You can't blame the software if you are not willing to prepare your input data correctly.

The polygon option is another issue, if it does not work fixes are welcome.

[Andrey]

what leads you to the assumption that gdal_contour works like this?

I tried GDAL before SAGA. I attached the results on top of the grid:
green - GDAL,
red - SAGA.

And how should something work on outer edges when there is simply no data available to compute something?

I see that GDAL simply extends lines/polygons horizontally or vertically to the grid edges. Image attached. But I believe that the proper way is to extrapolate or extend contours as in the another attached image (blue lines).

The polygon option is another issue, if it does not work fixes are welcome.

I'm not a programmer…

[Volker Wichmann]

I see that GDAL simply extends lines/polygons horizontally or vertically to the grid edges. Image attached. But I believe that the proper way is to extrapolate or extend contours as in the another attached image (blue lines).

Ok, but these image clearly show that the approach used by GDAL is producing wrong contours at the grid border (how could it be different?) and thus these results would always show non matching contours lines at tile borders. So with GDAL you would also need to process your data with an tile overlap in order to get correct results.
The "proper way" to extrapolate/extend the contours you suggest is not possible without using an overlap, where should the required information come from?

I hope with this discussion I can finally convince you that there is no other solution than using an overlap - there is no magic to achieve this otherwise.

[Andrey]

the approach used by GDAL is producing wrong contours at the grid border

Yes, it's true. But I would prefer such a solution rather than no solution at all. Especially for polygons.

where should the required information come from?

From available data using extrapolation. For overlap there is no need for extrapolation, there will be interpolation as usual.

that there is no other solution than using an overlap - there is no magic to achieve this otherwise.

Where overlap is possible - no problem. But where not? Extrapolation may be used there. But I understand that you don’t want to use it in this tool. I made my proposal, you rejected it, and I won’t insist any longer. Especially since there is a more serious problem with the tool. Should I post a bug report or is it a known issue (I mean broken polygons)?

[Justus Spitzmüller]

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.

As i wrote in this thread the metadata manipulation is a little bit hacky so i wrote a new tool which lets you copy and move a grid from one position to an other. With this you can easily expand your tiled world dataset by one column (or row) of tiles at the date line on each side. With this option you don't have any problems with the tiling approach at the date line. Have a look at the attached screenshot. Note: This tool is still a draft...

Also with this and this commit it seems there is some progress on the other feature request. But iam sure there will be an proper answer if the work is finished.

I understand that scripting such a complex task can be difficult and intimidating but here are some tips. Did you know you can save a tool script from the gui? (Manager Window > Tools > Tool Library > Tool Name) and then right click "Save to Script File"?

And are you aware of this folder or the parent folder? Or saga_cmd --create-batch as a starting point?

[Andrey]

i wrote a new tool which lets you copy and move a grid from one position to an other

Thanks, I'll take a look after it's released.

Also with this and this commit it seems there is some progress on the other feature request

Good to know, thanks!

Did you know you can save a tool script from the gui?

No, I didn't.

And are you aware of this folder or the parent folder?

Yes.

Or saga_cmd --create-batch as a starting point?

No.
Thank you again for your assistance.