-
Notifications
You must be signed in to change notification settings - Fork 231
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
Polygons from OSM layer are missing at some scales #421
Comments
Thanks for a great test case. This appears to be an issue with clipping. Commenting out lines 127-158 in output_object.cpp mostly fixes it (there's still some weirdness west of the channel). I don't yet know whether our algorithm for generating the clipping box is wrong, or whether we've unearthed an issue with (Note to self: The clipping code was mostly introduced in #234 so that's where to start looking.) |
I think #430 will fix this particular issue. There still appears to be some weirdness with this test case but I'm not sure that the relations in this OSM file are well-formed so I'm not concentrating on those! |
Thank you for trying to fix this issue, I built a binary using the "clip_endzoom" branch and regenerated mbtiles, unfortunately this problem seems to persist. Here are the results of generating similar problematic polygons at several levels: These pictures are around the coordinates (115.6472,40.2085), but this is not an isolated case, it can easily happen with large and complex polygons, such as the "wood" type of the "landcover" layer. By the way, I downloaded the data directly from geofabrik in osm.pbf format, without any special modifications. |
Hm, sorry about that. Would you be able to provide an .osm.pbf for the affected area, extracted either with |
Attached is a piece of data extracted using osmium with --strategy=smart, the bbox of data is 115.4207,40.0886,115.9086,40.3494 |
That's super helpful - thanks. I'll see what I can work out. FWIW https://www.openstreetmap.org/relation/5989768 is the issue. It doesn't seem to be simplification-related (same issues with simplification turned off). I'm not convinced it's well-formed. Looking at the multipolygon assembly code may be the first thing to do. Interestingly Overpass doesn't appear to recognise it either. |
Could you try #432? That appears to fix it for me. |
I tested it with this branch and it does seem to have solved the problem. 👍 |
Excellent! Thank you for your help with this. It turned out to be a bug in boost::geometry (which tilemaker uses internally for geometry operations) failing to clip the multipolygon correctly to tile boundaries. |
I found that some polygons from OSM layer were lost in the tiles at certain scales, so I made a test data reproduction of this phenomenon.
This is the polygon object that I picked from the OSM data that would cause the problem:
Then exported the polygon as a shapefile named "simplify-wrong.shp" and added each of these two data to the config:
And the process script is shown below:
Finally, use the command to generate mbtiles:
When rendering this mbtiles, you can see that at some scales, the polygons in the "from_osm" layer are partially missing, but the polygons in the "from_shapefile" layer are intact.
I have packaged the data and configuration related to this test in the attachment:
test.zip
The text was updated successfully, but these errors were encountered: