Idee om wat met BAG te gaan doen

Mijn beeld van DWG zal vast niet geheel accuraat zijn, ik heb een hoop van de historie gemist en zie alleen wat er heden ten dage op de mailingslists voorbij komt. Om een nieuwe lange flamewar over het importeren van BAG data te voorkomen zullen wij van de Franse les moeten leren. Want wij worden nu ook aangesproken op de dedicated import account requirement.

Ik zie het zelf niet zitten om met twee accounts te werken als ik een gebied aan het verbeteren ben. Dan moet ik eerst met mijn import account de gebouwen importeren, om daarna met mijn normale account de wegen te alignen, shop/amenity e.d. tags aan gebouwen toe te voegen etc. Dat betekend JOSM opnieuw opstarten en overnieuw beginnen. In de context van een massale import zoals de AND data destijds vind ik het geen probleem om daar een dedicated account voor te gebruiken, maar ik zie liever niet dat soort massale imports voor BAG data. Het huidige voorstel om de BAG data beschikbaar te stellen voor mapper die het kunnen gebruiken bij het mappen zie ik daarom wel zitten. Door deels handmatig te importeren zorg je direct voor een deel QA omdat je ziet waar je mee bezig bent. Een massale import gebeurt uit het zicht op de achter grond, en gaat hoogt waarschijnlijk op een hoger tempo dan je de changes kunt bij houden om te controleren.

Maar gezien bijna iedereen die met de BAG data bezig is geweest inmiddels een mail van pnorman heeft gekregen om een dedicated import account te gebruiken en de import op de ML te bespreken, hebben we wat het dedicated account betreft geen keus.

Wat steun van de lokale community betreft, daar is dit topic voor zou ik zeggen. Misschien moeten we nu gaan werken aan het opstellen van de import wiki, zodat we dit voorstel aan imports@ kunnen voorleggen voor hun goedkeuring wanneer wij als Nederlandse community daar tevreden over zijn.

Zelf wil ik niet te lang wachten om weer met de BAG data aan de slag te kunnen, ik heb nog een hoop adressen toe te voegen in de Gemeente Oldambt en de data die we nu hebben maakt dat een stuk eenvoudiger. Ik ben eerlijk gezegt bang dat er weer te weinig feedback komt op dit voorstel waardoor het proces stil komt te vallen.

To BAG or not to BAG …

Ik vraag me af of we niet op een nieuwe manier met gegevensbronnen om moeten gaan. Tot nu toe is het idee dat je die gegevens in de OSM database onderbrengt. Maar dat staat haaks op de ontwikkeling die je overal ziet, namelijk niet langer je eigen kopie willen hebben maar accepteren dat data zich verspreid over het internet bevindt. Tegelijk wordt meer en meer (overheids-) informatie openbaar gemaakt, onder een vorm van open source licentie.

Stel je bent al die gegevens aan het koppelen en beoordelen. Je brengt dan verwijzingen naar verschillende datasets samen, en laat op die verzameling een query los die de beoogde informatie laat zien. Maar nooit voeg je al die informatie samen in 1 grote dataset. Dat laatste gaat juist ten koste van informatie.

Bekijk dat eens vanuit OSM standpunt. Er is een OSM database, en er zijn andere databases zoals BAG, hoogtekaart etc. Soms als database toegankelijk, soms via een WMS server. Die informatie wordt extern up-to-date gehouden.
Ga je nu een extra kopie van al die info in de OSM database zetten, met als gevolg dat je zelf ook verantwoordelijk wordt voor het bijhouden van die data? Of ga je aan het werk om via bijvoorbeeld OpenLayers al die info samen te brengen in 1 presentatie. Als ik de OSM kaart zit te bekijken en ik wil graag de huisnummers zien is het net zo makkelijk gewoon een overlay aan te zetten waarin die informatie staat.

Zoals ergens hierboven al is opgemerkt: OSM heeft een leidende rol gespeeld bij het publiek beschikbaar stellen van informatie. Het zou veel meer in de oorspronkelijke opzet van OSM zijn, en in lijn met de ontwikkeling van het internet, om nu al die beschikbaar gekomen informatie samen te voegen in 1 interface voor de eindgebruiker, dan koste wat kost een ‘eigen’ kopie te gaan onderhouden.

noordfiets heeft wel een punt. Ik zie echter wel beren op de weg. Al zijn het misschien wasbeertjes.

Al is bv de BAG data Open Data, dat betekend nog niet dat het Open Source is zoals OSM. Wijkt de Geografische positionering af in de DB van BAG, dan kan het maar zo zijn dat de Layer projectie laat zien dat bv het gemeentehuis van Harderwijk midden op de A28 ligt. Toch wat slordig lijkt mij. OSM mapper hebben in een openstructuur al snoordfiets aangeeft niet de mogelijkheid om deze vermeende fout te corrigeren.

Is het succes van het projecteren van Open data in aparte layers binnen een OSM projectie daadwerkelijk afhankelijk van de koppeling in GEO projectie?
Kan dit practische problemen opleveren?

+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: