A fairly big but silent change in the openstreetmap.org map rendering infrastructure has been completed in the last days which is going to have a significant effect on mapper feedback through the standard style map.

here

Technically this is just a system and software update. This however includes a new osm2pgsql version which fundamentally changes the way multipolygon geometries are assembled. This change in osm2pgsql already happened more than a year ago but osm2pgsql had not been updated on the OSMF rendering servers since then.

Before this change standard style map rendering tried very hard to salvage whatever could be salvaged from a broken multipolygon geometry. This sometimes led to strange results but usually something was shown in some way even for invalid geometries. This led to mappers often being not very diligent about multipolygon geometries - as long as it shows up in the map it is fine. For data users not using osm2pgsql (like for example my low zoom map demo) this was a big problem because if they rely on valid geometries these invalid multipolygons are all unusable - yet customers of course expect them to be usable since you can see them in the map.

Long story short: That the standard map rendering should not try to be most tolerant about multipolygon validity but rather be more strict about it to give mappers better feedback about their mapping has been a demand of many people for a long time. This has now finally happened.

Osm2pgsql now uses libosmium for building multipolygons which means it is tolerant about

• duplicate nodes
• duplicate segments between nodes
• noded self intersections (i.e. rings intersecting with a node at the intersection)

It however is strict about

• non-noded self intersections
• open rings

Quite a few people have noticed during the last week or so already that there are a few prominent gaps in rendering where there previously were features shown. Many of these have already been fixed quickly because of this improved feedback. This is not yet very visible in the multipolygon error numbers because these count errors and do not consider their visual impact and what has been fixed quickly is primarily a few high impact cases. But there is hope that with this change in rendering and the resulting improvement in feedback to mappers about errors the increase in the number of errors in multipolygons might be stopped or at least be slowed significantly.

here

There are plenty of prominently visible gaps in the map due to broken multipolygons still waiting to be fixed of course. If you work on fixing such errors it is also a good idea to take the opportunity to split larger geometries into smaller features which can be maintained more easily and are less prone to breaking.

here

You can find these errors not only through missing geometries in the map but also through the OSM Inspector