search

gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.53k stars 819 forks source link

Some boundaries of protected areas do not render due to complicated geometry #4198

Closed paulw1010 closed 4 years ago

paulw1010 commented 4 years ago

Hello,

I wanted to report a bug with what I believe is how the Standard layer processes multipolygons. Multiple national forests in the United States refuse to render, despite being valid multipolygons according to JOSM's validator. I believe this is due in part to checkerboarding and other oddities with land ownership. I've attached some examples of how these complicated boundaries prevent rendering.

  1. I had to remove this large area of checkerboarding to force Prescott National Forest to render. Before it was removed, it did not render. Screen Shot 2020-08-31 at 6 21 40 PM

Same location on standard layer:

https://www.openstreetmap.org/#map=12/35.0636/-112.8928

  1. Superior National Forest, with a complicated boundary like this in many spots, will not render at all. (outer role members in red) https://www.openstreetmap.org/relation/11558095

    Screen Shot 2020-08-31 at 6 17 47 PM

  2. Manistee National Forest, with a similarly complicated boundary, also will not render. https://www.openstreetmap.org/relation/11565336

To clarify, all of these are valid boundaries according to the JOSM validator. There are no intersecting ways or anything like that. I also did not see any problems with any of them when I manually checked them. So I'm assuming it's due to the layer treating them as invalid for some reason. I know it has nothing to do with tagging either, because the same tags work on other national forests. I know that the tiles can take awhile to update on the OSM website, too, but I took that into consideration by using the export feature and cleared my cache, but still they do not render. Unfortunately I am not familiar with how the layer works so I'm sorry I can't pinpoint further what's causing the issue

kennykb commented 4 years ago

No idea what might be going on in the main rendering.

As a practical matter, I've had trouble with various data consumers rendering correctly in the case that there is more than one outer ring of a multipolygon sharing nodes at a corner, or when an outer and inner ring share one or more nodes. I've worked around that by offsetting one corner or the other by a few inches, so that no two rings share a node, and that's usually made it work. It also used to be that there wasn't any way to make a multipolygon pass JOSM validation with the shared nodes, but that appears to have changed at some point.

Sometimes, if you have the misfortune of editing at a busy time, it's weeks before levels 12 and coarser get re-rendered. Anyone who's worked with rendering knows that 12 is often a problem level because it has to ingest such a huge data volume per tile, but is still detailed enough that it has to process all that data and can't discard very much up front.

jeisenbe commented 4 years ago

Welcom @paulw1010 This is the github repository for OpenStreetMap Carto, the style used to render the "standard" map layer on Openstreetmap.org, but this rendering problem does not appear to be caused by this style. Rather, whether or not a relation will be imported correctly as a polygon is also determined by osm2pgsql (https://github.com/openstreetmap/osm2pgsql), which has certain limits on what polygons are considered valid. Unfortunately it is not clear to me what characteristic about his relation is causing it to fail to be recognized by osm2pgsql.

jeisenbe commented 4 years ago

(I also note that Mantee National Forest - which is now mapped as https://www.openstreetmap.org/relation/11565336 - was previously mapped as a much simpler area. This is still rendered at z10 and below, since those tiles do not re-render very often. Are you certain that the new area is correct? The National Forest website map shows the old area:

z8 old area of Manistee National Forest (still rendering until the next update)

Screen Shot 2020-08-31 at 15 47 37

Same area on official National Forest website:

Screen Shot 2020-08-31 at 15 49 01

What does the new, more complex boundary represent? The land ownership perhaps? Generally the outer boundary of a protected area is mapped, rather than actual land parcel ownership, in most OpenStreetMap communities:

Screen Shot 2020-08-31 at 15 53 32

)

jeisenbe commented 4 years ago

@paulw1010 - I now recall that this issue is a duplicate of #4181 which you opened back on July 20th. As mentioned then https://github.com/gravitystorm/openstreetmap-carto/issues/4181#issuecomment-663624457

"There are in principle three possibilities here:

"1) The multipolygon relation is invalid. Then you need to fix it. See https://wiki.openstreetmap.org/wiki/Multipolygon for what makes a valid multipolygon and what errors can make it invalid and https://tools.geofabrik.de/osmi/?view=areas for a QA tool identifying multipolygon errors. To practically analyze multipolygon validity in real time while trying to fix it you can also use https://docs.osmcode.org/osmium/latest/osmium-export.html and https://github.com/osmcode/osm-area-tools.

"2) The multipolygon relation is valid but libosmium fails to correctly build it. That is unlikely but given the complexity of your relation here it is not impossible. You would need to check processing it with the latest version of osmium (see above) and if possible reduce it to a simple test case and if a clearly valid polygon does not assemble file a bug report on https://github.com/osmcode/libosmium

"3) There is a glitch in the database on the OSMF servers. That is unlikely as well but if the polygon builds fine with osmium then this would be the most likely explanation."

"None of these can be fixed in this style"