Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 09:52 PM, Minko wrote: Ok, ik heb de situatie daar weer hersteld. Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Even nadat de database weer read/write was gemaakt heb ik mijn laatste changeset geupload met niet-boundary verbonden aan boundary fixes. Hiermee zou alle vreemde knikken veroorzaakt met het verplaatsen van boundaries weer in order gemaakt moeten zijn. Later dit weekend moet ik mijn rappotage script nog eens draaien over een verse OSM extract voor Nederland ter controle van alles wat ik eventueel gemist heb en de nieuw geïntroduceerde verbindingen. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ 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)
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 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. 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): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat 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
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 06:04 PM, Gertjan Idema wrote: 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. Op het moment word zelfs zonder het gebruik van de official_name tag voor beide namen vrijwel dezelfde resultaten getoont. Dus daar hoeven we het niet voor te doen. On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: 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). Klopt. Ik was Flevoland vergeten in het overzicht. Zuid Holland heb ik vandaag afgemaakt, en daarmee is de huidige status: done: 2152, TODO: 349, Total: 2501 (complete: 86.0455817672931%) On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: 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. Valt wat voor te zeggen. Maar het maakt het editten van boundaries buiten de volledige dataset om wel nodeloos meer werk. Idealiter leven de boundaries in hun eigen layer, omdat ze niet interacteren met de andere data. Ze hoeven niet gekoppeld te zijn voor routing of iets dergelijks. Hekken en degelijke barriers kunnen overlap hebben met boundaries en zouden van dezelfde ways en/of nodes gebruik kunnen maken als een hekwerk is geplaatst om de grens op locatie aan te duiden. Maar kunnen net zo goed los van elkaar staan. In mijn ogen is een administratieve grens een virtuele feature die per definitie losstaat van de features die op de grond kunnen bestaan. Zodoende dient de logische scheiding tussen de features behouden te worden door diens nodes en ways niet te combineren. Wanneer een rivier of andere niet-virtuele feature gebruikt word ter bepaling van een grens dient de logisch scheiding gerespecteerd te worden. Zo kunnen de ways over elkaar getekend worden maar geen nodes te sharen, of mijn voorkeur, teken de waterway en boundary vlak naast elkaar. On 03/03/2013 06:04 PM, Gertjan Idema wrote: 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: 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. Dat zou mooi zijn, maar ik weet het nog niet zo zeker. Het belangrijkste is dat wij documenteren welk type we gebruiken en waarom, en hoe dat afwijkt van bepaalde documentatie, QA tools, e.d. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ 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)
Bas, Bij het editten van de grenzen heb je hier een aantal (fiets)paden mede verplaatst: http://www.openstreetmap.org/?lat=52.06349lon=6.07858zoom=17layers=M Die zaten kennelijk aan de grenzen vastgeklikt? ___ 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)
On 03/03/2013 07:47 PM, Minko wrote: Bas, Bij het editten van de grenzen heb je hier een aantal (fiets)paden mede verplaatst: http://www.openstreetmap.org/?lat=52.06349lon=6.07858zoom=17layers=M Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ 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)
Ok, ik heb de situatie daar weer hersteld. Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Mvg, Bas ___ 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)
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): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat 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 verouderd is. Dat is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x Een van de JOSM ontwikkelaars pushed de standaardisatie naar
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
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. http://tools.geofabrik.de/osmi/?view=multipolygonlon=8.83540lat=51.64408zoom=8overlays=type_is_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)
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): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat 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
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
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 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. 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): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat 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
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 02/24/2013 05:09 PM, Sebastiaan Couwenberg wrote: 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. Hint voor alle JOSM gebruikers: Maak een filter voor boundary=administrative. Zet Enable filter aan en Hide filter uit. Dan kun je tijdens het bewerken van de data de grenzen wel zien, maar is de kans dat je ze per ongeluk kapot maakt en stuk kleiner. -- --- 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)
Date: Sun, 24 Feb 2013 20:44:24 +0100 From: carti...@xs4all.nl To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat) Hint voor alle JOSM gebruikers: Maak een filter voor boundary=administrative. Zet Enable filter aan en Hide filter uit. Dan kun je tijdens het bewerken van de data de grenzen wel zien, maar is de kans dat je ze per ongeluk kapot maakt en stuk kleiner. -- --- m.v.g., Cartinus Beste Cartinus,Das mooi voor JOSM gebruikers, maar wat te doen voor P2 gebruikers, mogen die het zonder tooltje doen en gewoon door werken ?Trouwens wat moet je als niet programmeur, onafhankelijk van het programma JOSM en P2, met deze kennis ?Greetz Hendrik ___ 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)
On 02/24/2013 10:56 PM, St Niklaas wrote: Beste Cartinus,Das mooi voor JOSM gebruikers, maar wat te doen voor P2 gebruikers, Die moeten gewoon goed opletten wat ze doen. -- --- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
