OpenStreetMap

Why the coastlines on Carto haven't been updated since January 2020 (update: fixed for now!)

Posted by JesseFW on 22 July 2020 in English (English)

Update!

As of July 25 – joto did the manual override! So the problem is resolved, at least for now. We still need to deal with the “but MY bay isn’t really a coastline” recurring problems, but now we can deal with them individually, rather than trying to address a six month backlog.


So, I accidentally wrote a wall of text yesterday in the IRC channel, and rory asked me to copy it here.

It was prompted by this question:

15:28 what is the rio plata thing about?

I responded:

johan_: So, the coastline rendering process used for openstreetmap.org is complex. and involves multiple semi-independent groups.

One group produces the planet.osm file, containing all the OSM data.

A different group (well, it seems to mainly just be joto), runs an independent server at https://osmdata.openstreetmap.de that processes the planet.osm data into a set of shapefiles defining the world coastlines.

Then a third group (back within osm.org) uses that data to render the map displayed by default on openstreetmap.org, known as Carto.

The osmdata script that does the processing includes an automatic cut-off that marks the produced shapefiles as invalid if the maganitude of changes since the last valid results is beyond a certain amount specifically, 0.0000015 (I’m not sure in what units, exactly). https://github.com/fossgis/osmdata/blob/master/scripts/coastline/compare-coastline-polygons.sh#L13

And the third group independently choses to obey this marking, and only apply shapefiles that have been blessed by this script.

There is an option to manually override the cutoff (by simply deleting the data it is comparing to), but joto, reasonably enough, will only do that with a clear, well-documented demonstration of a consensus among mappers that such a larger change is needed.

This mostly works.

Recently, specifically on January 10, 2020 – it didn’t.

A mapper noticed a large error in the coastline, and, reasonably enough, fixed it, all at once. This was too large for the automatic cutoff, so it halted updates. This would still have been OK if the large error had been totally uncontroversial and obvious – the mapper who fixed it could have reached out to joto, showed him the obvious correction, and he would have overriden the cutoff, and things would have continued to be fine. But, sadly, the error wasn’t so obvious and uncontroversial. It was, in fact, a subtle local political decision, that isn’t at all obvious or self-evident to a busy, uninvolved gis developer from far away. And the mapper who corrected it also didn’t realize they need to reach out to joto and get a manual override. So, instead, things just sat there. Blocked.

Over time, additional (small) corrections/updates to the coastline were made, by other mappers – some of whom noticed that their work didn’t seem to show up on openstreetmap.org, while lots of others didn’t even think to check. Eventually, someone tried reverting the large correction, in the hope that doing so would unlock the blockage and enable the other, uncontroversial updates to go thru. But it was too late – there were so many other tiny updates, all across the world, that their combined size alone hit the automatic cutoff. That’s where things stand today, to our collective embarassment.


There are two paths forward, that I see:

1) Revert enough of the changes since Jan 9 to bring us back under the cutoff, then slowly re-apply them, making sure to stay below the limit of changes per day.

2) Appeal to joto to do a manual override (with or without the large correction).

johan_: I would LOVE for you to try and work on whichever of those appeals to you more! What, you may ask, does any of this have to do with the Rio de la Plata?

Basically, nothing.

But the connection is that Plata is the name of the area where the large correction applied. That’s it.

Hope this wall of text was either interesting, or at least, not too frustrating to scroll past.

Comment from mmd on 22 July 2020 at 18:19

The following Github issue seems to have a bit more context and background information on that topic: https://github.com/fossgis/osmdata/issues/7

Comment from JesseFW on 23 July 2020 at 00:44

Yes, and I opened a more recent one, here: https://github.com/fossgis/osmdata/issues/12

I also requested that the osm.org operations team fix the problem themselves, but they said they wanted it fixed upstream: https://github.com/openstreetmap/chef/pull/326

Comment from imagico on 23 July 2020 at 07:55

Since this might be looked at by a wider audience now - useful further information can be found on:

https://lists.openstreetmap.org/pipermail/tagging/2020-January/thread.html#50252

See in particular my comments here:

https://lists.openstreetmap.org/pipermail/tagging/2020-January/050259.html

Other useful links:

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement https://www.openstreetmap.org/changeset/88211516

To actually achieve consensus here someone (that is someone speaking Spanish sufficiently well and being familiar with the subject - i.e. not me) has to break through the layer of political beliefs shaping the local tagging and have a discussion based on reason about the exact nature of the local physical geography and develop a tagging consensus based on that (which would probably be neither of the two versions proposed so far)

Since there are a few comments indicating displeasure with jotos hard stance on the matter - please remember that he does the work on maintaining a coastline extract free of larger errors. Everyone is free to take the code and create and make available their own extract - without or with different error checks. If such extracts would work well OSMF operations would probably gladly use them and joto would be happy to have less work.

What is being attempted now:

https://www.openstreetmap.org/way/194704675

is a questionable approach. The OSM coastline is meanwhile universally accurate enough that normal edits will not trigger the sanity check - with the exception of large iceberg calvings in the Antarctic that occur every few years. That means every edit triggering the sanity check when applied without piecemeal application trickery will be (or has been) one where someone is either scratching a personal or collective political itch or an actual mapping error. Avoiding the need for consensus building and defending your view of what the verifiable local geography is against broader scrutiny using such tricks is therefore problematic.

Comment from imagico on 23 July 2020 at 08:21

By the way there has been work on providing better feedback on coastline placement in OSM-Carto but it is stuck due to the lack of consensus among the maintainers:

https://github.com/gravitystorm/openstreetmap-carto/issues/3895

https://github.com/gravitystorm/openstreetmap-carto/pull/3930

https://github.com/gravitystorm/openstreetmap-carto/pull/4128

Comment from JesseFW on 23 July 2020 at 16:46

imagico – thank you so much for your comments and links; they are very helpful!

As of now, at least, the Plata issue is not contributing to the lack of updates, as it is not varying from the Jan 9, 2020 version. I agree that consensus still needs to be reached, but it is now (once again) separate from the lack-of-updates problem.

As of the July 23rd data file, the lack of updates is because, over six months, 36,491.37 sq km of changes have piled up, in tiny drips all across the world. These are not “someone is either scratching a personal or collective political itch or an actual mapping error”, these are “normal edits” that have merely piled up enough to hit the cutoff.

I’ve manually identified about 24,000 sq km of them, and will document them on the wiki so others can confirm they are valid (or revert them if they are in fact “political itches” or “actual mapping errors”).

I would be DELIGHTED to have support in doing that.

Comment from JesseFW on 25 July 2020 at 16:22

I just wrote up this suggested process for dealing with large coastline changes, here. Glad for comments.


  1. All changes over ~750 sq km within a day should be presumed incorrect. (This is already the case, as various people have said elsewhere)
  2. If such a change persists for more than one day (i.e. two failed updates in a row), an bunch of automated alerts should be sent, to everywhere from the mailing lists, to IRC, to wherever else we can think of, encouraging people to revert the changes.
  3. If a mapper believes such a large change to be valid (as in the Rio de la Plata case), the proper process (enforced by prompt reverts and blocking if necessary) is to create a wiki page (probably using the formal proposal process, or something similar), demonstrate consensus for the change (over at least a month, if not longer), get joto’s explicit acknowledgement that he recognizes that consensus, and only then apply the change (which joto will promptly manually release).

Comment from jimkats on 26 July 2020 at 14:14

Thank you for this post, I’m kinda new to OSM and didn’t knew about this issue, which solves the question I had for 2 months now of “why isn’t the coastline still not rendered and it’s shown misaligned with the administrative boundaries?”.

I’ve read all those links all of you mentioned above and joto said yesterday he “released” the coastline data. Does this means all of the changes of the last 6 months will being processed again and being rendered, but due to the size of the backlog it will take much longer time than the usual (as before) for them to start showing up at the end? Because I made changes in coastlines of two areas just 2-3 days ago.

Comment from JesseFW on 26 July 2020 at 16:22

Glad to help, jimkats!

The changes you made two or three days ago should now be visible, although they may not be visible at all zoom levels, as different zoom levels get re-rendered at different times.

If you are referring to this edit: https://www.openstreetmap.org/changeset/88481285 – it looks to me like it has updated now. Does it still look out of date to you?

Login to leave a comment