-
Notifications
You must be signed in to change notification settings - Fork 364
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
Investigate failing rasterization #3160
Comments
I also came across this some time ago. The trace is as follows (for @moradology's case):
Looks like this indeed is a bug, because as @moradology mentioned, the polygon is valid. I've made a little investigation and, in short, I think it's a I assume that a variation of the scan-line algorithm is used, as described here: https://www.cs.rit.edu/~icss571/filling/how_to.html geotrellis/raster/src/main/scala/geotrellis/raster/rasterize/polygon/PolygonRasterizer.scala Lines 106 to 107 in b01b6e2
But in our problem case, the scan-line ( y=21.5 ) doesn't cross the vertex exactly (y=21.499999999998117 ). So the above-mentioned code doesn't treat the intersection point as a vertex. However, due to the imperfect precision of Double , the calculations of intersection x -coords for both edges yield the same Double . Which effectively means that the scan-line does intersect the edges in a vertex (which it doesn't). This leads to the parity sum being calculated as 0 + 0 = 0 later, while given a perfect precision it should have been either 2 or -2 . As a result the point is added to rowRuns and later crashes on geotrellis/raster/src/main/scala/geotrellis/raster/rasterize/polygon/PolygonRasterizer.scala Line 426 in b01b6e2
The most straight-forward fix could be to use geotrellis/raster/src/main/scala/geotrellis/raster/rasterize/polygon/PolygonRasterizer.scala Lines 106 to 107 in b01b6e2
|
wow @atararaksin thank you so much for looking into it. 💯 added a bug label If you have any ideas with fixing it with spire types / BigDecimal I'll be happy to assist you btw. For sure as you said, there can be some performance costs so in this case these changes would have to be benchmarked :/ |
@pomadchin I've set up a little benchmark and yeah, using |
So basically I chose to use This approach may look a bit ad-hoc, but it preserves the original algorithm logic and structure, doesn't affect performance, solves the issue and is unlikely to break anything. |
Signed-off-by: Andrey Tararaksin <[email protected]>
This combination of polygon and raster extent fails during rasterization with default rasterizer settings despite what appears to be a valid geometry. It would be nice to get better error messages/work around cases like this if possible
Polygon
RasterExtent
The text was updated successfully, but these errors were encountered: