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

[Gertjan Idema]

On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote:


> 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 WPL08082012, bij de aangepaste woonplaatscode
> zit ook een nieuwe geometrie van de woonplaats in bag:extract
> WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
> aangepast met de versie uit bag:extract WPL08012013.
> 

Ik was me er niet van bewust dat je al zo ver was met de BAG
woonplaatsgrenzen. 

> > 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.

Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has
been created for country names'. Er staat dus niet bij dat het niet voor
andere namen gebruikt mag worden. Ik neig er nu toch meer naar om
'official_name' te gaan gebruiken. Zodra we het er over eens zijn,
kunnen we dit vermelden in de Nederlandse wiki.

> 
> 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.

Inderdaad. En er zijn ook nog genoeg namen die 3 of twee keer voorkomen.
Daarom vond ik 'Elst Ut', 'Ursem gem. S' en 'Alteveer gem Hoogeveen' ook
opvallende uitzonderingen.

> > 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.
> 

Goed werk! 

> 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.

Is 'Download parent ways/relations' Ctrl+Alt-D hiervoor een optie, of
ook te traag?
Replace geometry kende ik niet, maar ga ik zeker onthouden. Ook voor de
BAG panden. 

> 
> 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 verouder

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

[Cartinus]

On 02/27/2013 09:34 PM, Gertjan Idema wrote:
> Ik kan op zich leven met 'type=boundary' als dit overal behalve in Nederland
> en Duitsland de standaard is. Dan is het wel zaak om de Nederlandse 
> documentatie
> hier op aan te passen. Eerst maar eens uitzoeken wat destijds de argumenten 
> voor 
> type=multipolygon waren.

In de tijd dat die discussie speelde waren de roles admin_centre, label
en subarea nog niet uitgevonden of nauwelijks in gebruik. Er was dus
effectief geen verschil tussen de twee typen relaties.

Inmiddels is men ook in Duitsland op heel veel plaatsen weer terug bij
type=boundary.



-- 
---
m.v.g.,
Cartinus

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

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

[Sebastiaan Couwenberg]

On 02/27/2013 09:34 PM, Gertjan Idema wrote:
> On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote:
> 
>> 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 WPL08082012, bij de aangepaste woonplaatscode
>> zit ook een nieuwe geometrie van de woonplaats in bag:extract
>> WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
>> aangepast met de versie uit bag:extract WPL08012013.
>>
> 
> Ik was me er niet van bewust dat je al zo ver was met de BAG
> woonplaatsgrenzen. 

Dat is ook deels mijn schuld, ik heb er geen openbare progress report
oid van bijgehouden zoals voor het Woonplaatsbesluiten project is gedaan.

http://wiki.openstreetmap.org/wiki/Bestaande_geodata_hergebruiken_woonplaatsbesluiten

Het is mijn bedoeling om een dergelijk overzicht te genereren met
bijbehorende interactieve kaart voor de grenzen die in OSM geupdate
kunnen worden met de meeste recente versie in de BAG.

Hier wil ik pas echt goed voor gaan zitten als ik klaar ben met alle
woonplaatsgrenzen gelijk trekken met de inmiddels wat oude BAG, maar
gezien de woonplaatsen niet zoveel aan verandering onderhevig zijn als
de panden vind ik dat niet zo'n probleem. Voordat de grenzen met BAG
data geupdate werden was er tijden weinig tot niets aangepast, we zijn
er dus op vooruit gegaan qua actualiteit, maar nog niet helemaal
volledig up-to-date.

In eerste instantie had ik mij ook voorgenomen om de procedure die ik
volg bij het toevoegen en updaten van grenzen aan de BAGimport wiki
pagina toe te voegen, maar ik twijfelde over het nut ervan. Het
toevoegen van grenzen is een redelijk eenmalig proces, daarna zullen de
bestaande grenzen aangepast worden. Tenzij er nog nieuwe woonplaatsen in
het leven geroepen worden zal al het werk het updaten van bestaande
grenzen omvatten. Het is leek mij nuttiger om dat proces te gaan
documenteren wanneer alle ontbrekende grenzen waren toegevoegd. Daar is
het nu dus wel tijd voor aan het worden, maar ik zal hoogst
waarschijnlijk nog even procastinaten. Want ik wil mijn tijd nu nog even
in de laatste 484 woonplaatsen steken.

>>> 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.
> 
> Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has
> been created for country names'. Er staat dus niet bij dat het niet voor
> andere namen gebruikt mag worden. Ik neig er nu toch meer naar om
> 'official_name' te gaan gebruiken. Zodra we het er over eens zijn,
> kunnen we dit vermelden in de Nederlandse wiki.

Tsja, interpretatie van tags blijft een lastig issue.

Wat is de officiële naam van een woonplaats? Dat lijkt mij de naam die
op officiële documenten gebruikt word, ik denk niet dat gemeente of
provincie hints in de woonplaats naam onderdeel zijn van de officiële
naam zoals op briefpapier van het stadsbestuur word gebruikt, op de
plaatsnaamborden staat, en wat men in het postadres zou gebruiken. Het
lijkt mij deze deze in het verleden zijn toegevoegd zodat om unique
contraints in een database gewerkt kon worden, of om simpelweg in de
oude kaartenbakken op basis van de naam het onderscheid te kunnen zien.

Het hergebruiken van bestaande tags maar deze anders interpreteren voor
een nieuw project zorgt voor nodeloze verwarring bij diegenen die bekent
zijn met de originele insteek. Om dit te voorkomen kunnen we misschien
beter onze eigen tag introduceren zodat we vrij zijn deze te definiëren.
Zodoende voel ik er ook wel wat voor om bag:name of bag:woonplaatsnaam
te gebruiken voor de naam zoals het in de BAG staat. Deze namespace is
vrij voor ons om invulling te geven, en zullen minder snel aangepast
worden als de name tag. Ik zie ook liever "Alteveer" op de kaart dan
"Alteveer gem Hoogeveen", de toevoeging tbv de uniekheid heeft geen
meerwaarde ter rendering op de kaart.

Ik wil hier niet al te veel tijd aan spenderen. Het be