Possible improvements of OSMF style deployment to better serve our goal of providing mapper feedback

[imagico]

This issue is meant to collect ideas how the deployment of OSM-Carto by the OSMF might be improved to better serve our goal to provide mappers with constructive feedback on their work.

We receive frequent comments on the map lagging in updates after edits (like recently in #4826) - causing confusion among mappers if their edits have been correctly uploaded. So timeliness of updates in general is an obvious concern. But this is not what this issue is about because general optimization of timeliness in updates is known to be an ongoing concern in OSMF operations already.

Possible improvements beyond that which come to mind for me:

• more frequent low zoom re-renderings has been a significant concern in the past (it has been monthly for a long time) but i think this has been improved already (https://github.com/openstreetmap/operations/issues/648#issuecomment-1374567338 indicates as much).
• deferred coastline updates would be a significant improvement - because the coastlines are not rendered from the minutely updated database an edit to the coastline with no subsequent edits in the same area at subsequent days will typically lead to long term mismatches and the only option for the map user (after the /dirty feature has been disabled) is to make another edit to trigger an update. My understanding is that no functionality for this exists so far so this would be a development project at this stage, not an operations issue. This would equally be of benefit for the Antarctic land ice rendering (which suffers from the same problem).
• real time coastline updates would be an alternative to that. In principle this is possible, based on local, tiled processing of coastline data triggered by tile expiry just like rendering. Would likewise be a development project at this stage and would likewise be of general benefit for OSM based maps and not specific to OSM-Carto or the OSMF deployment.

[matkoniecz]

real time coastline updates

how that would avoid problem of "someone broke coastline, Americas are now displayed as flooded" ?

[imagico]

how that would avoid problem of "someone broke coastline, Americas are now displayed as flooded" ?

The idea here would be - as mentioned - local, tiled processing of coastline data triggered by tile expiry just like rendering. This would not fully avoid the issue of broken coastlines affecting the processing but it would limit the radius of influence of such breaks. So a faulty coastline edit in New York would not put all of South America in peril as it would right now.

You could still think about different ways to handle such errors in mapping - either having the tile in question 'flooded' or not updating it as long as broken data is detected in the tile area. It would, however, definitely avoid the need for manual inspection of larger changes in the coastline by some central authority (which is not a good and sustainable approach on several levels).

[imagico]

Another thing the OSMF could provide is a mirror for the external dependencies this style uses. This are in particular:

• the preprocessed coastline and icesheet files (sourced from osmdata.openstreetmap.de - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/external-data.yml).
• the natural earth administrative boundaries for the lowest zoom levels (sourced from naturalearth.s3.amazonaws.com - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/external-data.yml).
• the font files obtained by get-fonts.sh (https://github.com/gravitystorm/openstreetmap-carto/blob/master/scripts/get-fonts.sh) from various sources.

These need to be obtained by all style users and historically there have occasionally been problems with the reliability of some of these (see #4249, #4864). Being able to supply a reliable alternative source for these files to style users would be good.

Secondarily: If the OSMF distributed the versions of those files that are also in use by the OSMF's deployment of OSM-Carto at that time, it could help with tracing down problems in rendering - like https://github.com/gravitystorm/openstreetmap-carto/issues/4152#issuecomment-1762082843.

This is not part of the core functions of the OSMF obviously (like distributing the planet files) but considering that installing OSM-Carto is part of high profile initiatives of popularizing OpenStreetMap (https://switch2osm.org/) this would quite definitely also be of value for the OSM-Community to have a more reliable deployment procedure for the style.

There is also precedent for the OSMF distributing external data for map rendering in the form of https://planet.openstreetmap.org/historical-shapefiles/