[OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Sebastiaan Couwenberg]

On 02/24/2013 02:56 PM, Gertjan Idema wrote:
> Dankzij veel werk van vooral 'Sebastic' en 'It's so Funny', staan alle
> officiële woonplaatsen nu in de OSM database. Dit zijn de boundaries met
> admin_level=10.

Naar aanleiding van een bericht van It's so funny had ik ook een mail
over deze aangelegenheid in de pijpleiding zitten, maar daarvoor wij ik
mijn grenzen rapportage compleet hebben. Je bent me weer eens te snel af. :)

> Zelf heb ik de ontbrekende woonplaatscodes toegevoegd en de
> woonplaatsnamen vergeleken met de BAG data van 8-1-2013. In twee
> situaties kan er een afwijking zijn t.o.v. de BAG:
> 
> 1. Dubbele woonplaatscodes in de BAG:
>  In overgangssituaties kan het voorkomen dat woonplaatsen in de BAG
> tijdelijk met oude en nieuwe woonplaatscodes voorkomen. Tijdelijk is
> hier een ruim begrip, want het kan meer dan een jaar zijn. In deze
> gevallen heb ik de nieuwste woonplaatscode in OSM gezet. 
> Het gaat hier om: Apeldoorn, Leimuiden, Oudkarspel, Putten en
> Rijpwetering.

Ik werk in principe nog op basis van de BAG van 08082012, maar ik heb
ook de meeste recente van 08012013 in een aparte PostGIS DB staan. Van
beide heb ik OSM files met de woonplaatsgrenzen met behulp van jouw
bag4osm osmosis plugin (nog wel

Putten had ik al gelijkgetrokken met de BAG van augustus vorig jaar,
vandaar de oude woonplaatscode 2007. Bij de borrel afgelopen donderdag
werd ik door Steven gewezen op de aangepaste grenzen per 1 januari 2013,
Putten & Nijkerk. Deze heb ik niet direct aangepast omdat ik ze als
testcase voor mijn script wilde gebruiken.

Het is niet handig dat de ref:woonplaatscode van Putten is aangepast
naar de code in de meest recente BAG zonder ook de geometrie aan te
passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het
record in bag:extract 9999WPL08082012, bij de aangepaste woonplaatscode
zit ook een nieuwe geometrie van de woonplaats in bag:extract
9999WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
aangepast met de versie uit bag:extract 9999WPL08012013.

> 2. 'Onlogische' woonplaatsnamen in de BAG:
> Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet
> aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de
> BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is
> denk ik wel te zien waarom. (de tweede naam is de BAG naam):
> "Alteveer"    "Alteveer gem Hoogeveen"
> "Botlek"    "Botlek Rotterdam"
> "De Hoef"    "de Hoef"
> "De Lutte"    "de Lutte"
> "Den Haag"    "'s-Gravenhage"
> "De Woude"    "de Woude"
> "Elst"    "Elst Ut"
> "Europoort"    "Europoort Rotterdam"
> "Hoogvliet"    "Hoogvliet Rotterdam"
> "Maasvlakte"    "Maasvlakte Rotterdam"
> "Pernis"    "Pernis Rotterdam"
> "'s-Hertogenbosch"    "Den Bosch"
> "Ursem"    "Ursem gem. S"
> "Vondelingenplaat"    "Vondelingenplaat Rotterdam"

Ik twijfelde welke tag hiervoor te gebruiken, official_name was
misschien ook een optie gezien de Woonplaats als zodanig in de officiele
bron staat. Maar alt_name is waarschijnlijk beter.

Zien de OSM relations voor woonplaatsgrenzen met behulp van de
ref:woonplaatscode en diens naam (name of alt_name) tag gekoppeld worden
aan de records in de BAG is het van belang dat een van de twee tags
(name of alt_name) overeen komen met de woonplaatsnaam in de BAG.

Alteveer is trouwens een leuke, daarvan bestaan woonplaatsgrenzen in
meerdere gemeentes, en in meerdere provincies. Gelukkig hebben we nu de
ref:woonplaatscode om de 4 verschillende Alteveers te kunnen onderscheiden.

> Zoals ik in het onderwerp al vermeldde, betekent dit nog niet dat alle
> woonplaatsgrenzen nu netjes op de zelfde plek liggen als in de BAG. Dat
> is nog wel even werk.

Alleen de provincies Zuid-Holland, Utrecht, Flevoland en Noord-Holland
moeten nog gelijkgetrokken worden met de BAG, de overige provincies heb
ik reeds voltooid. Wel moet ik alles nog eens met de meest recente BAG
vergeleken worden wanneer alle admin_level=10 grenzen in OSM op basis
van de BAG zijn. Deze vergelijking zal geautomatiseerd worden, het
gelijk trekken van de overige provincies is nog wat handwerk in JOSM.
Maar met de Replace Geometry functie is het minder tijdrovend dan het
volledig handmatig mergen van alle nodes wat ik voorheen deed.

Het nadeel is wel dat met het verschuiven van de nodes deze niet
losgekoppeld worden van eventueel daaraan verbonden niet-boundary wegen.
Hier heb ik nu ook een controle script voor die met behulp van een
lokale OSM DB een rapportage maakt van alle niet-boundary wegen die
verbonden zijn met een boundary. Het handmatig losknopen hiervan is ook
nog best wat handwerk.

De Replace Geometry functie in JOSM koppelt verbonden wegen automatisch
los, maar dat kan alleen als de OSM data ervan beschikbaar is. Op zich
niet zo'n probleem, want met wat Overpass Queries is deze data ook zo op
te halen, alleen kost het uitvoeren hiervan meer tijd dan ik op het
downloaden van alle grenzen binnen een provincie wil wachten.

Nu doe ik een controle achter af. Na het updaten van alle grenzen binnen
een gemeente check of er nog niet-boundary ways aan de aangepaste
boundary ways verbonden waren. En koppel deze los indien deze aanwezig
waren.

Dat heb ik niet voor alle boundaries even secuur gedaan, waardoor er nog
wat fouten in de voltooide provincies kunnen zitten. Deze zal ik ook
allemaal nog corrigeren.

> Andere klussen:
> Het gebruik van type=boundary/type=multipolygon nog niet consequent.
> Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de
> internationale site staat echter dat type=multipolygon verouderd is. Dat
> is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x

Een van de JOSM ontwikkelaars pushed de standaardisatie naar
type=boundary. En als je op basis van de wiki of taginfo beslist hoe te
taggen zal type=boundary altijd de voorkeur hebben.

Ik zou graag het best of both worlds behouden.

Voor simpele boundaries waar geen admin_centre en andere boundary
specifieke roles voor worden gebruikt voldoet type=multipoligon.

Zodra een andere role dan inner of outer gebruikt word is de keus voor
type=boundary beter.

Omdat de multipolygon voor alle grenzen in Nederland voldoet, behalve
provincie Limburg welke ook een admin_center role heeft, gebruik ik
momenteel ook overal nog type=multipolygon.

Maar ik verwacht dat we deze binnenkort allemaal naar type=boundary om
kunnen zetten wanneer we admin_centre er aan toevoegen.

> Het komt nog regelmatig (341x) voor dat de 'role' niet is ingevuld in de
> relaties. Hier ga ik binnenkort nog wat aan bijwerken.
> 
> Sebastiaan is bezig met scripting voor het vergelijken van geometrien
> van de grenzen.

Ik vermoed dat deze allemaal van relaties zijn in de provincies die ik
nog niet met de BAG gelijk heb getrokken, dus ik ben benieuwt of jij ze
eerder hebt aangepast dan ik.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)