systemed
Incorrect render for a large multipolygon lake
I don't know if this is related to some existing and known issues:
The multipolygon area overlaps with other water area and there is a blank area without any water. This should be Lake Saimaa, https://www.openstreetmap.org/relation/7379046#map=9/61.3026/28.4216
As you can see, it is very complex area. The picture here is based on Geofabrik's latest Finnish file and is drawn here without any simplification. Are there any tricks that I could try?
This is made with the latest build from master branch. I'm wondering if this is related somehow to #181 although I understood that there should be a workaround for that in the latest commits.
Ugh, that's insanely complex. Unfortunately something that big is going to be near-impossible to reduce to a testcase.
One possible reason is that Tilemaker can't cope with non-closed inners, and there are several in here (e.g. https://www.openstreetmap.org/way/868890259). A quick hack to ignore them might be adding a check around line 247 of osm_store.h, viz:
Ring inner;
if (!ways.isClosed(*it)) { continue; } /* <--- new */
if (ways.count(*it)==1) { fillPoints(inner, ways.at(*it)); }
I found another position in which the lake polygon is not that complex:
https://www.openstreetmap.org/relation/409844#map=14/62.2353/28.8916
Yes, that does look like an issue with non-closed inners (the break at the top island is exactly where that would happen).
I've just pushed https://github.com/systemed/tilemaker/commit/12cb7422fa5431fbf52967daffcabf7c76d1fa21 which will piece together multiple ways to form an inner. It seems to fix both of the above examples on a quick test, though I've not looked in great detail.
There still appears to be an issue at z7/8 where Sääminginsalo disappears - unsure what's going on there but it's possibly a simplification issue.
Oh, that's cool! I'll compile the new version, recreate the tiles and see how it behaves. Thank you so much!
Hmm, here it looks like this:
and
I've used Osmium to pick only water areas osmium tags-filter finland-latest.osm.pbf a/natural=water --overwrite --verbose -o fin_water.osm.pbf but I guess it shouldn't otherwise affect the result.
The big area is 7.38/62.059/28.879 and the origin of spikes is 9.2/61.0754/28.0492. I use tileserver-gl-light to visualize the raw data of the mbtiles file. I processed these with the original Lua file in resources folder but removed the simplification for water totally and set min zoom level to be four for all.
Strange, the spikes will disappear in zoom level 9 after MapBox has redrawn the map. They come back when zooming to 8.
This can also be a problem with MapBox, I'll try to re-enable the simplification and setting a proper min zoom level. Probably the tile contains too much information.
I don't see any issues at z10, but at z9 various islands start getting dropped. I certainly don't see any renderings like the above, but different clients may of course treat invalid geometries in different ways.
I think this is going to need a bit of time to track down, creating a minimal test case (i.e. one that doesn't take hours to process!) and that's not time I have at the moment. But I'll keep this open for future reference.
Places to look (for my reference):
- Lake Saimaa northwest of Imatra - islands disappear at z8
- south of Puumala - islands disappear at z9
- around Savonlinna - islands disappear and massive misrendering at z8
Yes, this is unfortunately very time consuming. My tiles are still being processed.
I noticed yesterday that some lakes disappeared too quickly and realized that there might be a problem with setting the minimum zoom. The values (meters per pixel) apply for the equator but not for north: https://docs.mapbox.com/help/glossary/zoom-level/ And I'm not sure if they are one level off or not. That was the reason I disabled that part of the Lua code but didn't have more time yet to continue that research.
Finally got the new tiles with simplification and min zoom setting enabled. Those issues in the pictures above disappeared. So it was a MapBox GL JS issue. But I noticed that when zooming out, when the simplification will start, some land areas become water and vice versa. And there seems to be two overlays of water in some places. That is probably a simplification issue.
Another drawing issue is here:
https://www.openstreetmap.org/relation/445551#map=13/62.7629/28.5447
And somehow it feels that the latest commit is slower in generating the tiles, is the algorithm more time consuming?
It will be a bit slower, yes, because it's piecing together ways to make the multipolygon inner rings and that takes time. I think there's probably scope for a bit of optimisation though.
The land/water issue is the same as I'm seeing.
I can also see that some polygons get duplicated, such as this lake: https://www.openstreetmap.org/way/31185773 However, I'm not sure in which part of the process this happens. The raw viewer of tileserver-gl-light uses an opacity for the lakes and I can easily see that there are lots of this kind of duplicated lakes.
To validate the input data, I used osmium to produce a geojson file for the same water data and then I used tippecanoe to produce the tiles. I can see the duplicated lakes there as well so that is not related to tilemaker. The rendering issues were not visible in the result of tippecanoe.
The issue with overlapping lakes appears to be at least partly an OSM mapping issue.
Puruvesi (https://www.openstreetmap.org/relation/899111) and Saimaa (https://www.openstreetmap.org/relation/7379046) cover the same area, using the same member ways. This looks like pretty bad practice to me and I've just posted to the OSM lists about it.
I'll continue to look into the rendering issues.
Ok, this is a bit of a hack, but I think it's the only sensible way forward right now:
The Saimaa multipolygon is insane (7223 members) and entirely duplicates the geometry of other relations (Pihlajavesi, Puruvesi, Haukivesi, etc.). There is no need for tilemaker to render it.
I'm not sure exactly what it is that's causing tilemaker to flake out with it: it might be geometry breakage (tilemaker is less resilient at recovering from this than a PostGIS setup), it might simply be so big that it's hitting some internal limit, it might be an issue with Boost.geometry, or it might be that tilemaker has a design issue which is causing the processing the geometry properly. Because the multipolygon is so big and complex it's very, very hard to debug, even using a .pbf which just contains this multipolygon and nothing else.
I've started a conversation on the OSM lists about removing this multipolygon, but who knows where that will go. Until then, we can filter it out in the Lua script. At line 353 of process-openmaptiles.lua, adding:
if class=="lake" and way:Find("wikidata")=="Q192770" then return end
will skip over Saimaa. The individual lakes that make it up are still rendered, and as a bonus, processing speed is several times faster as it doesn't have to keep clipping this ridiculously large polygon!
@ttsirkia
I technically fixed the Saimaa multipolygon using JOSM today. There were a few issues needing resolving, including a self intersection. Would be interesting to know if this fixes your issues.
I did not resolve all warnings generated by JOSM, as they were irrelevant to the geometrical issues, nor did I resolve potential overlaps between different water tagged (multi)polygons (not sure if the current database contains any).
Thanks for pinging, wow! I took the latest version of tilemaker and downloaded the latest Finnish .osm.pbf. I couldn't find any problems with the lakes now.
I'll close this issue, thanks once more!
Actually, the only problem seems to be that the latest version of tilemaker doesn't show Saimaa at all, so this https://www.openstreetmap.org/relation/7379046 is missing.
9/61.4/27.8934
But maybe this is another story.
Oops, I had still the hack from February in the Lua file to skip that particular relation. Let me try again.
It took several hours to build the tiles now. Unfortunately, the problem still exists.
7/62.259/28.249
But for example. the location I mentioned yesterday now looks fine:
9/61.4/27.8934
It looks like those spikes are visible if the zoom level is 8 or less.
@ttsirkia
If the high zoom display of the relation is OK, than that seems to indicate that my fix of the multipolygon is fine, and that the issue is possibly related to the generalization routines likely used for low zoom display.