-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Comments
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.
I also worry that using |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Here the
0.5
is missing. Only1
and1.5
were output. Gdal 3.9.And it makes just as little sense as if
1.5
was missing, and only0.5
and1
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.)
The text was updated successfully, but these errors were encountered: