-
Notifications
You must be signed in to change notification settings - Fork 230
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
PR575 seems to break shapefile #580
Comments
Gah. Do you know any other locations where this happens? |
surfed around the coastlines for visual testing and it seems to appear in all regions. I also don't see a pattern in zoomlevel or similar. Will have to dig deeper ... e.g. southeast of Boston #9.31/42.0623/-70.2313 between Athens and Mykonos Cadiz / Spain Shetland Islands |
Reading the shape gives (and always had given in the past) some messages, maybe its related as follow up-effect Shapefile entity #1628 type 5 is invalid. Parts:28. Reason:Geometry has invalid self-intersections. A self-intersection point was found at (-110.642, 25.7673); method: i; operations: u/i; segment IDs {source, multi, ring, segment}: {0, 0, -1, 214}/{0, 0, -1, 216}... failed to correct. Reason: Geometry has invalid self-intersections. A self-intersection point was found at (-110.642, 25.7673); method: i; operations: u/i; segment IDs {source, multi, ring, segment}: {0, 0, -1, 214}/{0, 0, -1, 216} |
Great, thank you. I'll see what I can find. I don't think those output errors are connected though you never know. |
Try with #581. It uses the latest version of the geometry correct library which seems to fix this. I've tested with Cadiz and the Shetlands and in both cases it now works. Compiling might be a bit tricksy - if it fails to build, let me know what version of Boost you have installed. |
First the code stuff (as i don't know if this has side effects on the test): Then the test: Initial compile error |
Thanks for checking the Boost version - I have 1.76 on one machine and 1.68 on another so was slightly guessing, but a look at the commits makes it look like 1.76 is the breakpoint so I've updated that. Otherwise that shouldn't affect the behaviour. I'll take a look at those two examples. |
I've had a fairly in-depth look at this and it doesn't look like an easy one to fix - I suspect the simplify code is generating a problematic geometry even before we get to clipping it. My gut is to merge #581 which makes things better and then keep iterating on the few remaining failures. A peninsula on the eastern side of Andros which looks like this is being simplified to this (note the self-intersections) |
dang, all works great with extracts like europe or the us, but the planet doesn't finish as 2 threads seem to be stuck in an endless loop consuming 100% cpu since > 1 day. I managed to get the stacktrace with gdb but this points to geom correct i have no more info (can i get this with gdb ?) Generated points: 191992085, lines: 554101566, polygons: 657148788 gdb -p 90546 |
i recalculated with the current master, great work, good improvement :) All of the locations mentioned above are now looking good but unfortunately i found one problem area near Trieste. cannot say if its related to the South Uist / simplify effect mentioned in #597 or if it is still an edge-case in clipping |
Thanks. Out of interest, is that with Maplibre GL Native or JS? |
this is both and in inspect i see this effect in raw data In Stockholm i have an effect only in raster/maplibre-native so i didn't report it first (vector and inspect data seem to be ok in this case on first sight) |
Thanks - I'll take a closer look! |
3e90739 should fix the Trieste issue. It appears to be a rarely triggered bug in I then tried with Stockholm on Native (iOS) and that seemed ok to me - let me know how you find it. |
Unfortunately doesnt fix the problem :( |
Gah. How can running |
If I remove the outer.size check so that the line just reads
and additionally replace
(Tested with both Maplibre GL JS and Native. All using coastline-only data except Venice which is coastline+OSM.) So I'm tempted to go with that and then look at Boston (in particular) when time permits as that's the most egregious outstanding issue.
The |
#611 should fix the issues (famous last words). |
great improvement At the moment i would suggest merging the PR 611 as it fixes nearly all issues the current master has for all users |
That's great! Thanks for your help in identifying these issues. I've merged #611. Do drop any screenshots here if you spot issues. One of the changes with #611 is that it will now pro-actively drop very small polygons at lower zoom levels. This reduces tile sizes and rendering time, and removes artefacts and complexity that could cause rendering issues. The side effect is that you may occasionally see a polygon being 'clipped' if only a small amount of it is in one tile - for example, if a z6 tile is mostly land but has a very small bit of ocean polygon at one corner, that bit of ocean might be dropped. I have some ideas on what we can do about that, but it's a nice-to-have rather than an essential. If I can drill down the boost::geometry issues to a couple of reproducible testcases then I'll file issues accordingly. I think often we're in edge case territory, where self-intersecting geometries are causing more drastic failures than you would expect. |
@systemed i made an interesting observation related the "write_to" function. After yesterdays comments in issue 697 i deeply compared different profiles and saw the following when checking the area #14.13/47.61047/8.22883 which is part of the river rhine at the border Germany-Switzerland, far away from oceans and shapefiles (Maybe i'm understanding something wrong in the system. Idea in my profile is water_polygons normal at z14+, a bit simplified in medium zoom, more simplified at low zooms to increase rendering speed and shrink sizes) config.json relevant part process.lua relevant part for natural=water / waterway / water=river ... polygons
Does this help in debugging ? |
minzoom filtering by area in Lua is not really workable as a solution to geometry validity issues - it's something we need to address on the C++ side I think. But thanks. |
Hello,
the "correct invalid geometries" fix of #575 seems to break the water polygons shapefile
(https://osmdata.openstreetmap.de/download/water-polygons-split-4326.zip downloaded today)
in some regions e.g. New York / southwest of Manhattan in z12/13, raster as well as vector affected
(green-ish = ocean/shapefile, blue= osm water, Tile 13/2410/3081 empty)
Seems to be a side effect of the last change ...
The text was updated successfully, but these errors were encountered: