Occasionally, I (like other people I’m sure) have noticed that things “disappear” from maps they should appear on. In the case of “national parks” and “areas of outstanding natural beauty” in the UK, they’re mapped as multipolygons. This might be simple, like Nidderdale or more complicated, like Ynys Môn. What usually happens is that someone accidentally “breaks” the multipolygon, for example by creating a gap in an outer edge, so that rendering software sees it as invalid and ignores it.
What I’ve typically done in the past is, whenever I’ve noticed a problem tried to find the problem using something like the OSM Relation Analyzer or JOSM’s validator. The “area” view at Geofabrik’s OSM Inspector is also useful.
That works, but “happening to notice a problem” as a first step is not ideal. This map does show national parks / AONBs and not a lot else at zoom 7, but those tiles only typically get updated every 4 days, so it can lag behind problems.
I have a rendering database that covers GB and Ireland, and in there “SELECT distinct name FROM planet_osm_polygon WHERE (boundary = ‘national_park’);” will list all those items that are currently being rendered. As an aside, that query is on “boundary=national_park” because the data is processed by this lua style file as it is loaded, and that consolidates the tagging into something that makes the rendering code less complicated.
Next, the challenge is to get the same list from OSM. Thanks to this answer on the help site, I was able to do that. There’s a bit of manual work comparing the two, because:
Once I’ve done that, I have two lists that I can compare.
Chiltern Hills AONB Dorset AONB High Weald AONB Kent Downs AONB Llŷn AHNE Shropshire Hills AONB South Devon AONB Sperrins AONB Suffolk Coast & Heaths AONB Ynys Mon AHNE
The process is the same manual process as before - download the relation as an object in JOSM, validate, and look for errors in the multipolygon. In some cases (for example “unconnected coastline”) you might need to load a bit more data to avoid seeing unrelated errors. Generally speaking you can ignore the warnings, as most of these are unrelated to multipolygon validity and some are completely invalid.
Usually what’s happened is that someone’s redrawn some feature that formed part of an AONB boundary and neglected to add the new part back into the AONB relation. To take Dorset AONB as an example, it looks like previously one of the railway lines formed the boundary, but that had been edited to leave a gap, so I redrew that as a new way slightly to the south in these changesets.
Shropshire Hills AONB was the most difficult to diagnose and fix. JOSM didn’t actually find an error there so I had to go through the warnings. It may have been this change that finally fixed it (zoom in on the green line east of Craven Arms to see the red line and deleted nodes).
Next - what’s the easiest way to detect breakages as they occur? I don’t want to have to manually compare with Overpass every time, but the good news is that I don’t have to - I can just compare with the list that was in the database yesterday, and look for things disappearing from the list.
# ------------------------------------------------------------------------------ # Count national parks, and see if there are more or fewer that when we last # looked. # ------------------------------------------------------------------------------ mv /home/renderaccount/data/nationalparks.justnow /home/renderaccount/data/nationalparks.previously psql -d gis -c "SELECT distinct name FROM planet_osm_polygon WHERE (boundary = 'national_park');" > /home/renderaccount/data/nationalparks.justnow diff /home/renderaccount/data/nationalparks.justnow /home/renderaccount/data/nationalparks.previously #
That now runs as a cron job on map.atownsend.org.uk every morning, and if there are any changes, I’ll get emailed the results.
Comment from mmd on 29 December 2020 at 14:04
For a sorted, duplicate free (aka “DISTINCT”) list of national park names for the UK you need to use something like https://overpass-turbo.eu/s/11In
Comment from SomeoneElse on 29 December 2020 at 20:54
@mmd - thanks for that. Is there any documentation on what that actually means? For example I can see references to “make stat” at https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Making_a_Table_of_Object_Versions but not much about why it’s needed.
Comment from mmd on 30 December 2020 at 10:55
Apologies, i didn’t mean to throw a random piece of overpass gibberish over the fence… :)
https://dev.overpass-api.de/blog/loop_and_group.html#for has some more details about how the “for” statement works. In the example above this boils down to “for” calculating a number of groups based on the “name” tag, and then iterate over those groups.
Comment from SK53 on 3 January 2021 at 10:35
OSM Ireland used to have a very useful list of polygons which had changed size over a certain percentage, IIRC via Nominatim. Unfortunately it was one of the things which didn’t get restored when servers where switched over (or at least I havent seen it in a while).
Comment from DaveF on 5 January 2021 at 14:57
I believe the best way to detect future problems is to help prevent them occurring. When I imported Cotswolds AONB from Natural England I didn’t reattached to existing ways (especially roads). I believe boundaries rarely run down a road’s centreline, and the data bears that out. Some editors don’t clearly define ways with an attached relation but no tags & contributors occasionally, unwittingly, delete them; so I add note tags like this, to clarify: note=Part of Cotswolds AONB relation.
Note “ISO3166-1”=”GB” returns UK wide data, so includes Northern Island.
Comment from SomeoneElse on 6 January 2021 at 20:26
@DaveF agreed - when I fixed one of the southern English ones I drew a new line in deliberately rather than re-use a bit of railway. Didn’t put a note on it though - that would have been a good idea.
