Idee om wat met BAG te gaan doen

+1 Noordfiets

We bevinden ons in een overgangssituatie. Ik ben geneigd in mijn regio alleen nog de nieuwbouw van na plm 2005 (ontbreekt vrijwel geheel op OSM) toe te gaan voegen en daarna verder zien of het nog wel zin heeft de rest te vervangen/bij te houden. Afgelopen weekend heb ik de Vinex wijk Vathorst geïmporteerd en daarbij tot de conclusie gekomen dat heel Amersfoort laat staan Nederland vrijwel onbegonnen werk is (voor mij althans, misschien dat een IT-er hier anders over denkt).

Ik denk dat dat ligt aan de AND wegen die verkeerd gepositioneerd zijn. Eigenlijk moeten die ook allemaal vervangen worden door de wegen uit het NWB bestand. Is die laatste dataset openbaar en zo ja waar te vinden? Op https://data.overheid.nl/data/dataset/nationaal-wegen-bestand-wegen-rijkswaterstaat vind ik alleen doodlopende links.

Ik zie wel duidelijk meerwaarde om BAG e.d. open data bronnen in OSM te integreren. De OSM database is een bron voor one-stop shopping voor geo data, het integreren van de verschillende data bronnen is als data consumer al voor je gedaan, je hoeft maar met 1 formaat rekening te houden. Tevens is rondom die database een heel ecosysteem van tools beschikbaar om met die data te werken.

Professionele kaarten tokos integreren de data uit de BAG, NWB e.d. ook in hun eigen map. Het recente Apple Maps fiasco is een voorbeeld van het niet goed integeren van de verschillende datasources. Waarom zouden we elke gebruiker van Geo data dat zelfde pad op forceren, als we het leven voor elkaar makkelijk kunnen maken door de data te integreren tot een handzaam formaat?

Het toekomst beeld wat geschetst word van het via Openlayers en dergelijke tools combineren van data sets vind ik een erg mooie. Iedere provider stelt zijn data beschikbaar en met open standaarden knopen we alles aan elkaar. Dan hebben we Google niet meer nodig om de informatie van de wereld beschikbaar te maken, dat doen de data providers dan zelf al. Ik verwacht dit echter niet op de korte termijn, daar gaan nog wel een tiental jaar overheen voor we daar zijn vermoed ik. In het nu hebben we behoefte aan adressen uit de BAG, straatnamen en ligging uit de NWB e.d. en kunnen dat eindelijk in OSM integreren nu de licentie perikelen uit de weg zijn.

Het een hoeft het ander natuurlijk niet uit te sluiten. Degenen die nut zien in het integreren van open data in OSM kunnen dat nu doen, terwijl anderen hun tijd besteden aan het ontwikkelen van tools om open data eenvoudig te combineren. QGIS ziet er op dat gebied veel belovend uit, maar is wel een andere tak van sport dan OpenLayers of mkgmap.

Wat de NWB betreft, hier zijn diverse feeds van te vinden via het Nationaal Georegister: http://www.nationaalgeoregister.nl/

Ik kan me helemaal vinden in de woorden van Sebastic. Ik zou daar nog aan toe willen voegen dat we OSM vooral als internationaal project moeten zien. Ik zou het nog steeds vreemd vinden als we anderen van deze open data onthouden (via OSM) maar ze verwijzen naar een vrij beschikbare database voor NL die met de nodige conversiesllagen te integreren is met OSM. Als een android applicatie als Osmand voor ieder land op een dergelijke wijze te werk zou moeten gaan betekent dit dat het practisch niet meer werkbaar is om te kunnen navigeren naar de exacte locatie van een adres. Op een verantwoorde wijze deze vrije data OSM in krijgen is mi momenteel de beste optie.

Ik denk dat het relatief eenvoudig moet zijn voor een locale mapper om BAG data verantwoord OSM in te krijgen. Ik ben in Leusden vorig weekend bezig geweest en dat ging relatief eenvoudig. Met wat extra scripts/plugins en wat ervaring is het mi redelijk snel te doen. Als we ook nog een snellere methode krijgen om informatie van het oude 3dShapes pand op het BAG pand te krijgen dan schiet het best op. Vele handen maken licht werk. Maar goed dat zien we tzt nog wel.

Laten we eerst maar eens kijken of het uberhaupt goed mogelijk is de BAG data verantwoord OSM in te kunnen krijgen met de steun van een substantieel deel van de OSM gemeenschap.

Alleen is het maken van die wereldwijde overlay een (zo goed als) onmogelijke taak als die huisnummers verspreid zijn over een honderdtal databases met elk hun eigen formaat. Dus tot openmetamap[1] gerealiseerd is (ik mag het geloof ik geen vapourware noemen) blijven er imports.

Vergeet bovendien niet de mogelijkheid de data te verrijken na een import. In de BAG zitten adressen gekoppeld aan een 2D representatie van gebouwen. In OSM zijn er tags voor 3D modellen van gebouwen [2]. Wil je dat invoeren, dan zul je toch echt met 2D moeten beginnen.

[1]http://www.google.nl/#hl=nl&output=search&q=openmetamap
[2]http://wiki.openstreetmap.org/wiki/Category:3D

Hier lijkt de DWG toch wat flexibeler in te zijn als ik de recente post van Frederik Ramm op talk@ lees.

Wat laat maar toch nog even een reactie hierop. De data van OpenKVK kan naar mijn mening zeker zeer waardevol zijn (ook voor OSM). Dat je iets zou willen doen door deze data te combineren met BAG kan ik ook goed begrijpen. Sterker nog… dat heb ik al eens gedaan. Ik ben geen doorgewinterde ICT-er dus het koste me nogal wat moeite om met MS access wat data aan elkaar te knopen maar het resultaat is er dan ook naar :wink: . Destijds had OpenKVK nog geen geo info en dus heb ik obv postcode/huisnummer wat gematched met BAG. Het resultaat daarvan heb ik op een kaartje geplot met als doel om dit aan mappers te verspreiden om OSM in te krijgen. Probleem daarbij is dat er in OSM nog geen BAG data zat dus… waar moesten ze die shop=* tag dan aan hangen. Op het 3dShapes pand of misschien beter een losse node? Lastig . Dit was 1 van de redenen voor mij om eerst maar eens te kijken of we met BAG wat zouden kunnen doen.

Een probleem waar ik tegenaan liep is dat de data van (Open)KVK zeer onbetrouwbaar is. Bedrijven /zelfstandigen kunnen op de vragenlijst van KVK haast invullen wat ze willen en het gaat zo rucksichtlos de database van KVK en dus OpenKVK in. Gevolg: je ziet soms op een huisadres de KVK gegevens van een hotel dat ergens anders gevestigd is. Ws woont daar dan de directeur oid maar het klopt in ieder geval niet. Als je dus iets wil met de KVK data moet er nog een kwaliteitsslag overheen. Dat leek mij een prima klus voor de locale mapper. Daar waar de informatie klopt kan ie snel de data OSM in krijgen en daar waar het niet klopt weet de locale mapper ms wel waar het hotel gevestigd is.

Het is dus technisch geen probleem om BAG met OpenKVK te koppelen (het is mij immers ook gelukt :wink: ) maar wat is de waarde van de informatie die je overhoudt?

Ik vraag me dus af of het uberhaupt mogelijk is OpenKVK data te matchen met andere data en in een database te krijgen (OSM of een ander) zonder dat er een kwaliteitsslag overheen gehaald wordt.

Is het dus niet beter om alleen de betrouwbare OpenKVK data OSM in te krijgen en de onbetrouwbare er zo uit te filteren? Of zijn er betere ideeen?

Zo’n wereldwijde overlay is niet zo’n punt eigenlijk. Je hebt daar een verwijzende database voor nodig en kunt dan aan de hand van de geografische positie een lijst van beschikbare overlays tonen voor die regio.

Vapourware … dat is een goede vraag. Zoals Ligfietser al opmerkt zitten we in een overgangsfase. Niet speciaal binnen OSM maar op alle fronten. Ontwikkelingen als cloudcomputing en -opslag(*) en zaken als Google+ , Office365 gaan een kant op waar niet langer het fysiek bezit telt maar het internet de bron voor zowel software als data is. Dat vergt ook een omschakeling in denken.
Of we uiteindelijk echt die stap maken is afhankelijk van de acceptie. Nu al zie je hoe het ene bedrijf enthousiast al zijn data in die cloud gooit, terwijl het andere bedrijf nog maar eens een paar extra NAS’sen aanschaft omdat de juridische afdeling stond te steigeren.

Hoe dan ook is het een vraag of over 10 jaar zelfs de PC nog wel bestaat. Of dat een PC vervangen wordt door een terminal-achtig apparaat wat toegang geeft tot internet, maar dataopslag en rekenkracht uit dat internet haalt.

Dus of de damp neerslaat of verwaait? Ik durf het niet te zeggen. Maar we kunnen in elk geval niet blind zijn voor die ontwikkeling.
(En voor de duidelijkheid: ik ben niet tegen een BAG import.)

(*) De term cloud is een beetje gekaapt door grote software bedrijven. Wat nu cloud heet is dat eigenlijk niet in strikte zin. In feite is het nu een aan het internet gekoppelde centrale opslag. Het oorspronkelijk idee om data redundant te verspreiden over een groot aantal servers/pc’s is een beetje ondergesneeuwd.

KvK data moet volgens mij alleen worden gezien als bewijs dat op dit of dat adres een Kvk-inschrijving van een rechtspersoon is. In die zin is het KvK-register m.i. betrouwbaar.

Als je vervolgens zelf conclusies gaat trekken op basis van KvK-data (bijv. dat op een adres de hotel-BV is ingeschreven, en dat dus ook het hotel zelf daar gevestigd is), voeg je onbetrouwbaarheid toe. Dat is dan een eigen conclusie, dat ligt niet aan het KvK-register.
Volgens mij moet per geval worden beoordeeld, of op het adres van de KvK-inschrijving van de rechtspersoon (stichting, vereniging, BV, NV, eenmanszaak), zich ook de activiteiten van die rechtspersoon afspelen. Dat is wel vaak zo, maar het hoeft helemaal niet.

Jan … helemaal mee eens. We delen gelukkig wel de conclusie dat je niet zomaar “POI” achtige info uit (open)KVK kunt gebruiken om te concluderen dat daar ook die activiteit plaats vindt.

Dedicated import account

Ik ben begonnen met een tweede -dedicated import- account waarmee ik nu de BAG gebouwen importeer én de bestaande gebouwen opschoon:
http://www.openstreetmap.org/user/ligfietser_BAG/edits

In praktijk valt deze werkwijze reuze mee, je moet alleen in de gaten houden met welk account je de boel upload, maar afsluiten van JOSM hoeft helemaal niet. Onder hetzelfde account en in dezelfde changeset met het uploaden schoon ik de oude gebouwen meteen op (muv de gebouwen met extra tags). Zodoende kan de oude situatie hersteld worden mocht er iets misgaan.

Het toevoegen van extra tags op zo’n BAG pand (bijv amenity=school) doe ik nadat ik de zaak heb geupload. Vóór het uploaden van deze wijzigingen even in JOSM bij de instellingen de gebruikersnaam veranderen van user_BAG naar user (het is dan makkelijker om hetzelfde wachtwoord te houden dan hoef je die niet telkens opnieuw te typen, maar dat moet iedereen voor zich bepalen).

Voordeel van twee accounts is dat ik hiermee tegemoet kom aan de richtlijnen van de DWG en dat men bij latere updates snel terug kan vinden welke panden onbewerkt afkomstig zijn uit het BAG (met de user=username_BAG) en welke evt zijn bewerkt (user=username).

Om het proces een beetje uniform te laten verlopen is mijn voorstel om bij imports van BAG data dit te doen onder de naam username_BAG.

Op talk heb ik de parameter -Djosm.home= ter sprake gebracht. Als je twee shortcuts maakt om JOSM op te starten, kun je makkelijk wisselen. Je loopt kans dat je nl. vergeet om de settings aan te passen.
Uiteraard vond iemand het niet handig, omdat je dan de rest van de preferences moet synchroniseren. Dat hangt natuurlijk af hoeveel je ze gebruikt. Je kunt ook beginnen met de prefs dir naar de 2e lokatie te kopieren. Dan valt dat wel mee.

Ligfietser: het aanpassen van de tags na de import is inderdaad iets dat je beter met je eigen account kunt doen en niet met je BAG-account. Op die manier kun je de import en integratie beter scheiden.

V.w.b. je conventie: dat wijkt af van mijn eigen conventie _! :open_mouth: Jeeminee, wat nu? Discussieren op tagging? Dan loop je zelfs nog kans dat mensen daar serieus op ingaan :stuck_out_tongue:

Eens, jullie hebben hierin gelijk.

Prima voorstel. Zou je dat account eigenlijk ook niet moeten gebruiken om de vnl 3dShapes panden te verwijderen? Ik denk dat als je de import van BAG wilt terugdraaien (om wat voor reden dan ook) je ook het verwijderen van de 3dShapes data wilt terugdraaien.

De Geo-freaks hebben ook hier een oplossing voor :smiley: Anders komen objecten wel uit in de buurt van Parijs (oorsprong RD stelsel, de “false origin” noemen ze dit), of in de bocht bij Afrika (0,0 lat/lon). Je kunt niet zomaar verschillende kaartlagen over elkaar leggen zonder ze te herprojecteren. Veel software doet dit automatisch, als je de instellingen goed hebt staan. Ook kun je herprojecteren in veel databases (PostGIS, Oracle).

@Peewee het wissen doe ik ook onder de import naam omdat die twee handelingen onlosmakelijk aan elkaar verbonden zijn.
@Frank: sorry hoor maar in jouw tekst lees ik iets van xxx_import en ook sebas had het in een prive mail over username_BAG dus vandaar die naam; _ kan ik nergens vinden, waar haal je die vandaan?

Maar het is toch juist handig om de term BAG in de accountnaam te hebben omdat er meerdere mensen met BAG bezig zijn. Die zijn dan makkelijk te herkennen. En als je straks klaar bent met de import van BAG dan neem je gewoon een nieuwe accountnaam voor de volgende database die je in OSM importeert :wink:

Ok. Dan blijft bij het invoeren van de BAG data alleen nog het overzetten van tags van het oude (3dShapes) naar het nieuwe (BAG) pand over. Je kunt je afvragen of je dat ook niet onder de BAG account moet doen. Het is immers geen data die jij ooit in OSM hebt ingevoerd (al zullen die er ms ook wel bij zitten). Als later iemand je aanspreekt waarom je een pand een bepaald tag hebt gegeven kun je in ieder geval zien dat het met de BAG import te maken had. Als we het hier over eens zouden worden dan hoeven we sec voor de BAG import alleen maar het BAG account te gebruiken en niet je eigen account. Wel zo makkelijk lijkt me.

Daar ben ik het niet mee eens. Er van uitgaande dat een mapper in zijn eigen gebiedje importeert, neem ik aan dat als jij een bepaalde tag van het 3dshapes pand verplaatst naar het BAG pand, je dat ook doet met lokale kennis.
Dan heeft die tag dus niets met de oorspronkelijke BAG data te maken (het komt ook niet uit die database) en dient dus ook niet met die dedicated account te gebeuren.

Laat ik een voorbeeld geven van wat ik gedaan heb. Ik heb in een aantal wijken in Leusden oude panden door BAG vervangen. Daarbij oude tags overgezet op nieuwe BAG panden. Daar zaten bv een aantal scholen bij (building=school, name=*). Ik weet wel dat dat een school is maar wat precies de naam is…? Die tags heb ik gewoon overgezet zonder te verifieren of die school ook echt zo heet of niet, dus inclusief evt spelfouten… Het is mi ondoenlijk om een wijk of stad aan te pakken als je echt alles moet gaan controleren dat anderen hebben toegevoegd. Ik vergelijk de situatie voor en nadat ik een wijk heb aangepakt. Daar is qua tagging niets veranderd behalve dat het ene pand vervangen is door het andere. Dat lijkt mij juist de bedoeling van de actie om 3dShapes panden te vervangen door BAG. Niet meer en niet minder. Als die mapper ook nog eens de boel wil opschonen (graag zelfs want je ziet soms wel rare dingen) dan kan dat toch gewoon daarna onder zijn eigen account?

Ik heb ook eens in bv Amsterdam wat bekeken maar daar zie je bv tags als alt_name:es=* Ik ben benieuwd hoeveel lokale mappers weten of dat juist is.
Kunnen we het lokale mappers die bereid zijn oude panden te vervangen door BAG wel aandoen om deze extra controle van alle tags uit te gaan voeren? Ik ben bang dat het dan wel heel lang gaat duren voordat we klaar zijn.

edit: misschien moet de dedicated account niet alleen het woord BAG bevatten maar meer : replace_old_building_with_BAG_data_without_deleting_info… (Ok is wat lang maar de bedoeling is duidelijk :wink: ) . Op huidige 3dShapes panden zie ik ook allerlei tags die later zijn toegevoegd maar de source is nog steeds 3dShapes.