Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gdal_contour skips first contour when on edge #10167

Closed
jidanni opened this issue Jun 9, 2024 · 1 comment · Fixed by #10170
Closed

gdal_contour skips first contour when on edge #10167

jidanni opened this issue Jun 9, 2024 · 1 comment · Fixed by #10170
Assignees

Comments

@jidanni
Copy link
Contributor

jidanni commented Jun 9, 2024

Here the 0.5 is missing. Only 1 and 1.5 were output. Gdal 3.9.

gdal_create -q -outsize 2 2 a.xyz
perl -awnle '$F[-1]=$F[0]; print "@F"' a.xyz > d.xyz
cat d.xyz
0.5 -0.5 0.5
1.5 -0.5 1.5
0.5 -1.5 0.5
1.5 -1.5 1.5
gdal_contour -q -i 0.5 -a Z d.xyz d.csv
cat d.csv
ID,Z
0,1
1,1.5

And it makes just as little sense as if 1.5 was missing, and only 0.5 and 1 were output.

Nor does the man page document that the first contour is skipped if there are no data points below it.

Which is good, as documenting that would be just as bad as saying that the last contour is skipped if there are no data points above it.

If contours on edges are to be skipped, then at least skip consistently.

But that would leave us with only one contour, at 1.

Solution: fix the bug that arbitrarily skips the first contour, even though there are two or more data points right on it, that should become part of a new LINESTRING contour.

Else it is like buses that run every half hour from 8:30 AM to 5 PM (but oops, not the first bus.)

@rouault rouault self-assigned this Jun 9, 2024
rouault added a commit to rouault/gdal that referenced this issue Jun 9, 2024
… matches the first level

Fixes OSGeo#10167

There's currently an asymmetry since the maximum raster value is
included. This is due how the marching square thresholding compares
pixel values to the candidate contour levels. Add a special case to
modify the comparison for the level that matches the minimum raster
value.
rouault added a commit to rouault/gdal that referenced this issue Jun 9, 2024
… matches the first level

Fixes OSGeo#10167

There's currently an asymmetry since the maximum raster value is
included. This is due how the marching square thresholding compares
pixel values to the candidate contour levels. Add a special case to
modify the comparison for the level that matches the minimum raster
value.
rouault added a commit to rouault/gdal that referenced this issue Jun 10, 2024
… matches the first level

Fixes OSGeo#10167

There's currently an asymmetry since the maximum raster value is
included. This is due how the marching square thresholding compares
pixel values to the candidate contour levels. Add a special case to
modify the comparison for the level that matches the minimum raster
value.
@jidanni
Copy link
Contributor Author

jidanni commented Jun 10, 2024

I also worry that using -fl <first contour> explicitly might not work either, so do please check it. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants