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 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. >> > > 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 belangrijkste is dat we een tag kiezen en deze consistent gebruiken zodat de tools er gebruik van kunnen maken. alt_name is lekker breed gedefinieerd en minder troebel dan de hoe official_name geïnterpreteerd moet worden. In de source van nominatim zie ik dat official_name een van de tags is waar het op zoekt, of dat dan een argument voor of tegen gebruik als BAG naam is vind ik lastig vast te stellen. Het is wel een beladen tag denk ik, die we daarom beter niet kunnen hergebruiken voor de naam zoals in de BAG. We zullen de woonplaatsnaam voornamelijk gebruiken om bij wijzigen van een woonplaatsgrens de nieuwe woonplaatsidentificatie (ref:woonplaatscode) en de daarbij behorende wijzigingen te kunnen vinden in de BAG. Er van uitgaande dat hierbij de woonplaats alleen een nieuwe identificatie heeft gekregen niet ook meteen een nieuwe naam. Ik ben er niet zeker van of dit uberhaupt mogelijk is/voor kan komen. In het Processenhandboek BAG [1] staat dit niet tussen de voorbeelden. Een woonplaats word benoemt en heeft een daarbij behorende woonplaatscode. Wanneer een woonplaats word hernoemt blijft de woonplaatscode ongewijzigd evenals de geometrie. Een ingetrokken woonplaats behoud zijn woonplaatscode ook. Alleen als een woonplaatsgrens word aangepast wanneer daarbij "panden, adresseerbare objecten of openbare ruimten betrokken zijn" krijgt de reeds bestaande woonplaats een nieuw identificatie nummer, en word er een nieuwe woonplaats toegevoegd met zijn eigen woonplaatscode, geometrie e.d. [1] http://www.kadaster.nl/web/artikel/download/BAG-processenhandboek-2012-1.htm Omdat het niet gespecificeerd is houd ik het voor mogelijk dan wanneer een woonplaats word ingetrokken dat men deze opnieuw kan benoemen maar dat de woonplaatscode afwijkt, of dat de woonplaatscode niet afwijkt maar voor een andere naam is gekozen. Maar het lijkt ook dat een gewijzigde woonplaatscode een indicatie is dat de geometrie is aangepast en er ook een nieuwe geometrie is bij gekomen. Een aangepaste geometrie is ook mogelijk wanneer de woonplaatscode niet is gewijzigd maar de begin datum wel, dat is de easy case. Ik ben wel benieuwt hoe de verschillende processen achter de schermen bij de gemeente ingevuld worden. >> 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. Zeker opvallend, ik vraag mij daarom af hoe dat zo gekomen is. Ze zijn als zodanig destijds de BAG ingevoerd. In het geval van Alteveer staat hij ook als zodanig in het woonplaatsbesluit [2], voor Urshem is dat niet zo [3], en voor Elst juist weer wel [4]. [2] http://mirror.openstreetmap.nl/woonplaatsbesluiten/Hoogeveen [3] http://mirror.openstreetmap.nl/woonplaatsbesluiten/Schermer/ [4] http://mirror.openstreetmap.nl/woonplaatsbesluiten/vrom/Rhenen.pdf Misschien zijn de betreffende gemeentes wel bereid om een nieuw woonplaatsbesluit uit te vaardigen zodat wooonplaatsen hernoemt kunnen worden. >>> 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! Huidige status: done: 2000, TODO: 484, Total: 2484 (complete: 80.5152979066023%) >> 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? Ik heb er in het begin een beetje mee gespeeld, maar het werkt niet helemaal lekker. Het is onduidelijk hoeveel data het op gaat halen en het is lastig de juiste selectie te maken op het op uit te voeren. De hele dataset is een beetje te veel van het goeie, die bevat alle grenzen in de provincie plus alles daaromheen. Ik gebruik daarvoor een aantal overpass queries om alle relaties (en alles wat daaronder hangt) getagged als boundary=* en land_area=administrative op te halen binnen de boundingbox van de betreffende provincie. Maar hiermee heb je niet de waterway=river wegen die vaak over grenzen getrokken zijn, en de verschillende highways, buildings e.d. Als je alle mogelijkheden wilt afvangen moet je alle data binnen de boundingbox ophalen en dat is al snel teveel voor een grote stad laat staan een hele gemeente of provincie. Voor alle nodes die onderdeel uitmaken van een way die member van een boundary relatie wil je de overige ways ook ophalen, maar dat is een (te) dure overpass query. Maar relatief goedkoop als je way_nodes tabel in de OSM tabel direct kunt raadplegen. Daar heb ik nu maar voor gekozen, maar ik ga toch eens kijken of ik dat zelfde niet kan realiseren met een betere selectie query in JOSM en de download parents functionaliteit. > Replace geometry kende ik niet, maar ga ik zeker onthouden. Ook voor de > BAG panden. Voor de BAG panden is hij ideaal, hoewel je maar 1 pand per keer kan upgraden kost het wel aanzienlijk minder tijd om de tags en geometrie te mergen. For the record, Replace Geometry (Ctrl+Shift+G) is onderdeel van utilsplugin2: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Replace_Geometry_.28Ctrl.2BShift.2BG.29 >>> 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 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. Het enige nadeel aan type=boundary is wat mij betreft dat hier standaard een warning voor getoond word in OSMI. Maar omdat deze super eenvoudig uitschakelen is, het dat redelijk een non-argument. Ik hou me voorlopig aan wat ik hier eerder over heb geschreven. Voor nu type=multipolygon blijven gebruiken zodat we alle woonplaatsgrenzen straks als zodanig tagged hebben. Daarna kunnen we beslissen of we niet toch naar type=boundary over willen. Voor consistentie met het voorgaande woonplaatsbesluiten project houd ik de daarvoor besloten tagging nog aan. >> 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. > > Viel mee. Het bleken allemaal plaatsen buiten Nederland te zijn die > binnen mijn boundingbox vielen. > > Vanavond heb ik de gemeentecodes gecontroleerd. Er bleken nog twee > gemeentes zonder gemeentecode te zijn. Hollands Kroon (laatste edit door > ondergetekende :-) en Bernheze (laatste edit door 'sebastic' ;-)). > Als het goed is zijn ze nu compleet. Ik zag het ja, my bad. Ze krijgen inderdaad nog niet genoeg aandacht van me. Tijdens het woonplaats werk maak ik eigenlijk alleen een multipolygon van de gemeente en ben ik te lui om de gemeentecode even op te zoeken. Het is maar 1 query, maar hij breekt wel met m'n workflow. Nog even en we hebben met de tools in ontwikkeling een helder overzicht wat we waar moeten aanpassen om het met de actualiteit gelijk te trekken. En misschien kunnen we dat zelfs mechaniseren, maar dat is ook een te gevoelig onderwerp om ons nu al druk over te maken. Eerst maar eens de changes inzichtelijk maken. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) _______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
