Zie inline commentaar. On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote:
> 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. > Dit lijkt mij inderdaad een eenmalige klus. Zou jammer zijn van je energie om het uitgebreid te documenteren. > >>> 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. We zullen het in de praktijk zien. Zoveel verandert er volgens mij niet. Eén puntje wil ik wel in overweging geven: Als iemand netjes de officiële naam opgeeft in bijvoorbeeld nominatum, dan zou het wel zo prettig zijn als de bijbehorende plaats dan ook wordt gevonden. > >> 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%) Als ik het goed heb, zouden het er 2500 moeten zijn. (2505 woonplaatscodes als je de 'dubbelen' mee telt). > > >> 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. Als de rivier de officiële grens is, betwijfel ik of je grens en de rivier moet loskoppelen. > > 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. Als type=boundary de officiële standaard is, is dat in mijn ogen een bug in OSMI die binnenkort wel verleden tijd zal zijn. > > 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 >
_______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
