In de laatste OFM (full) is nu ook het zoeken naar huisnummers mogelijk (vooralsnog alleen via de POI search): http://www.openfietsmap.nl/news/14-10-2012
Mark,
Ik weet niet hoe je de BAG extraheert. Waar je in ieder geval voor moet waken is om direct uit de BAG XML files te gaan extraheren.
De data daarin bevat alles wat ooit in BAG is ingevoerd, inclusief fouten en dubbelingen.
Binnen NLExtract http://nlextract.nl is dit een van de zaken die we oplossen, namelijk door inlezen in PostGIS tabellen
en de actuele (zonder eindtijd) en bestaande (status) objecten middels PostgreSQL VIEWs uit te filteren.
Vandaar de PostGIS stap.
Ook zitten er andere “gotcha’s” in de BAG zoals bijv. “gerelateerdewoonplaats” zowel bij “nummeraanduiding” als bij “openbareruimte”.
Als de eerste aanwezig is gebruik je die, anders die van openbareruimte. Dit soort zaken wordt meegenomen in NLExtract DB-scripts die ACN-achtige
adressen extraheren. Daarnaast nog verrijking met gemeenten/provincies en in te toekomst wijken/buurten.
groeten,
Just van den Broecke (developer NLExtract :))
Ik ben de laatste tijd wat huisnummers aan het toevoegen in de regio Eindhoven.
Dit is voor mij heel makkelijk aangezien ik als postbode werk. Heeft dit nog nut of is het beter/makkelijker met de BAG-data?
Vraagje aan Peewee en Gertjan: hoe gaan jullie om met updates? Dus nieuwbouw, verbouwingen en sloop.
Vanwege het feit dat zowel BAG als OSM open data zijn, zie ik weinig reden om BAG in OSM te importeren, waardoor OSM een “schaduwbestand” wordt voor de BAG. Je kunt beide datasets makkelijk (met de juiste skills) combineren door in je eigen toepassingen de OSM-gebouwen buiten scope te laten en de BAG hiervoor te gebruiken. De BAG is actueel (als je een recent extract hebt), maar bij OSM ben je afhankelijk van degenen die de data ooit geïmporteerd hebben. In OSM heb je ook te maken met verschillen in actualiteit. Ook zie je, nu er meerdere BAG-imports zijn (Nijmegen, Gorinchem, Vathorst, Tiel) dat er ook verschillend wordt omgegaan met tagging en het wel of niet koppelen van huisnummers aan gebouwvlakken.
Dit is in ieder geval voor mij een belangrijke reden dat ik me nooit aan de BAG gewaagd heb. Een andere reden is dat het ontiegelijk veel werk is om alles perfect te importeren en te onderhouden. Verder moet je rekening houden met data die aan bestaande gebouwen hangt. Dit moet je ook overhangen, alhoewel je je ook hier weer kunt afvragen in hoeverre alles nog actueel is.
Denk a.u.b. hier eerst over na en zorg dat je voor deze issues een goed plan hebt! De techniek is het laatste onderdeel in het proces en het makkelijkst te realiseren.
Sebastic, ik denk dat je een enigszins verkeerd beeld van de Data Working Group hebt.
De DWG is er met een reden, nl. om issues met de data te voorkomen en te verhelpen. Dit gaat over o.a. vandalisme, auteursrecht, edit wars, e.d. Ze zijn er niet voor om zomaar mensen af te fakkelen of wat dan ook. De meeste reageerders op het Franse Kadaster-topic hebben niets met de DWG van doen, maar voelen zich niet door hun gebrek aan kennis geremd om hun mening te geven.
Mijns inziens valt alles onder import wat je niet zelf op de grond surveyt, vanuit je eigen kennis toevoegt, of via luchtfoto’s tracet. Je neemt ergens bestaande data vandaan en zorgt dat dat in OSM komt. Je zegt zelf “Ik teken voor alle gebouwen die ik importeer ook …” Het is overdreven om voor elke toevoeging een account te maken, maar waarom zou je het niet doen als je alle gebouwen van je stad, dorp of wijk importeert? Zoveel moeite is het niet. Het is een “best practice” en absoluut geen gezeur! Mocht er een issue zijn m.b.t. de herkomst van de data, of hoe de import zelf is verlopen, dan is het veel makkelijker om alle data van gebruiker xxx_import te verwijderen, dan alle changesets van gebruiker xxx door te lopen om te kijken wat wel goed is en wat niet. Het integreren kun je alsnog met je eigen account doen. Dat heb ik zelf ook bij diverse imports (o.a. 3dShapes) gedaan.
Nogmaals, de DWG is niet per definitie anti-import. Binnen de gehele OSM-community leven her en der wel anti-importsentimenten. Je moet wel bedenken dat degenen die het ergens niet mee eens zijn, het eerst, vaakst en luidst hun mening zullen verkondigen. Wat de DWG en de OSM-community wel verlangt, is dat de import met zorg gebeurt. Er moet hier wel over nagedacht worden, bijv. onderhoud, juiste tagging (niet te weinig, maar ook geen tags importeren die OSM niet kan onderhouden) en uiteraard steun van de lokale community.
Ruud heeft FME van Safe Software gebruikt. Dit is een ETL-tool, wat staat voor Extract, Transform en Load. Het laden heeft hij overigens met JOSM gedaan. Gezien zijn kennis van de BAG (hij komt er praktisch dagelijks mee in aanraking) zou het misschien goed zijn als hij eens zijn licht op de voorgestelde tagging laat schijnen. Maar zoals ik in een eerder bericht aangeef, zijn er nog genoeg andere vragen te beantwoorden. De tagging is m.i. de een na laatste stap, voor de techniek.
Tja, lastige vraag. Toen vorig jaar vast kwam te staan dat BAG open data zou worden en dat er geen voorwaarden aan hergebruik werden gesteld (toendertijd m.u.v. postcodes), ben ik gestopt met het verzamelen van huisnummers. In de Watervogelbuurt in Utrecht heb ik daarom zelfs een deel van de huisnummers niet ingevoerd.
Later heb ik nog wel langs een deel van de Oudegracht huisnummers verzamelen, maar dat had meer als doel om winkels en bedrijven te karteren, maar vooral om van het mooie weer te genieten 
Ook hiervoor geldt dat ik tegenwoordig meer heil zie in het koppelen van de BAG met OpenKVK.
Maar goed, dat is mijn mening. Als je het gewoon leuk vindt, of je vindt dat je het wel moet doen, moet je daar vooral mee doorgaan.
Ik heb nog niet op al je vragen een antwoord maar laat ik maar van wal steken.
Wat ik en nog een paar anderen aan het doen zijn moet je maar zien als een testcase. We zijn nu e.e.a. aan het invoeren en gebruiken die ervaring om te kijken wat het meest pragmatische weg is om de data verantwoord OSM in te krijgen. Het is dus vooralsnog veel trial & error. Voordeel is wel dat OSM er niet op achteruit gaat als de oude 3dShapes vervangen wordt door BAG data maar uiteraard is het verstandiger op een dusdanige manier de data in te voeren dat er tzt ook nog e.e.a. aan onderhoud en controle gedaan kan worden.
Hoe er precies omgegaan gaat worden met updates etc is mij nog niet bekend maar het is dus de bedoeling de data zo in te voeren dat daar mogelijkheden voor blijven (juise ID’s). Ik kan me echter niet voorstellen dat het technisch een groot probleem moet zijn om verschillen tussen BAG en OSM data op te sporen als beide data te matchen zijn met ID’s. Als er een keer een verbouwing is aan een huis (verandering van vorm oid) dan lijkt me dat niet een erg groot probleem als dat niet meteen wordt gefixt. De juiste adressering vind ik wel een groot pluspunt van het invoeren van BAG data.
Ik geloof graag dat het technisch mogelijk is om BAG data en OSM los van elkaar te houden en samen te voegen voor eigen applicatiedoeleinden maar ook dat heeft wel een aantal nadelen. Hoe moet een Duitser die iets met NL OSM data wil doen weten dat hij voor juiste adressen maar een BAG extract moet converteren en samenvoegen met OSM data? Het is toch juist de bedoeling van OSM om 1 dataset te hebben waar alles bij elkaar komt. Straks worden er nog wegen uit OSM gehaald omdat er ergens een extract te krijgen is van alle nederlandse wegen en we niet op 2 plaatsen onderhoud willen. Misschien wat gechargeerd maar als straks alle data vrij is dan zou er geen centrales OSM database meer zijn. Iedereen combineert maar wat ie zelf wel. Lijkt me geen goed streven.
Een voordeel van invoeren van BAG data is ook dat je nogal eens fouten tegenkomt. Wegen die niet goed zijn gepositioneerd en opeens dwars door een gebouw heen lopen bv.
Verschil in tagging lijkt me ook technisch goed op te lossen mits er wel het zelfde BAG id gebruikt wordt. Als er bij een update besloten wordt om bv toch de addr:city tag of addr:country op te nemen terwijl die nu ontbreekt dan moet dat te doen zijn lijkt mij.
Tot op heden is inderdaad gebleken dat het overzetten van tags het meeste werk is. Dat bied overigens ook weer de kans om de boel op te schonen en dat is mooi meegenomen. Oude panden verwijderen en nieuwe BAG toevoegen gaat relatief snel. Desondanks is het wel heel veel werk maar … vele hande maken licht werk.
Ik denk dat we er best goed over nadenken maar we zullen ongetwijfeld e.e.a. vergeten zijn of bij moeten stellen. Het plan is om over een tijdje met een voorstel te komen. Dan mag er naar hartlust op geschoten worden.
Laat ik eerst voorop stellen dat ik niet anti-BAG-import ben, maar vanuit mijn betrokkenheid bij eerdere imports en vanwege het feit dat ik werkzaam ben in het geo-veld heb ik wel de nodige bedenkingen.
Dat hoeft ook niet, maar neem vooral de tijd daarvoor
Het is wel duidelijk dat jullie nog in de ontwikkel-/testfase zitten, maar ik mis nog een aantal fasen die ervoor plaats zouden moeten vinden. Ik ben zelf ook een techneut, dus ik weet als geen ander hoe verleidelijk het is om in de techniek te springen, maar je moet wel leren wat het goede moment daarvoor is. De BAG roept zoveel issues op dat hier goed over moet worden nagedacht. eker aangezien het ontwikkelproces uit trial & error bestaat. Dat levert ongetwijfeld situaties op die later opgeschoond moet worden. Je noemt zelf ook “onderhoud en controle”. Dit zijn zaken die je integraal moet benaderen, niet uitstellen tot t.z.t. Van uitstel komt afstel.
Stel een wiki-pagina op, maak een plan(ning), organiseer een meeting, nodig mensen uit om mee te denken (mits constructief), etc. Natuurlijk is dat niet zo leuk dan wat testjes importeren, maar om een BAG-import in OSM geaccepteerd te krijgen, is dat wel nodig. Een import moet goed worden gedocumenteerd, goed doordacht zijn en steun hebben van de Nederlandse community. Anders krijg je bijv. de DWG + iedereen die vindt dat hij er iets van moet vinden over je heen.
Bij de AND-import en bij andere imports is vaak besloten om de ID’s te houden, om er “later nog wat mee te kunnen doen”. Dat gebeurt hoogst zelden. ID’s zijn gewoon tags in OSM, dus die kunnen geëdit worden. In Nederland zijn bijv. veel wegen die aan elkaar geplakte ID tags hebben, bijv. 123;456;789, omdat de oorspronkelijke ways aan elkaar geplakt zijn. Aanvullende controles zijn nodig. Dat kan bijv. door periodiek OSM-data in een database te laden en (ruimtelijke) queries uit te voeren om het met een recent BAG-extract te vergelijken.
Als een Duitser iets serieus met Nederlandse data wil doen, dan zal hij daar vroeg of laat zelf wel achter komen dat er iets als de BAG bestaat. Ik weet niet exact hoe het zit met Europese regelgeving, zoals Inspire, maar ik geloof dat BAG en andere basisregistraties mede in het kader hiervan onderhouden worden. De scope van OSM is wel vrij breed (zeker meer dan een wegenkaart), maar het lijkt mij niet realistisch te verwachten dat OSM maar alle publieke datasets moet souperen. Daarvoor is de community te divers en de kern van degenen die dit tot stand zouden kunnen brengen en onderhouden te klein (long tail effect).
V.w.b. de zinnen “Als straks alle data vrij is, dan zou er geen centrale OSM database meer zijn. Iedereen combineert maar wat ie zelf wel. Lijkt me geen goed streven.”: dat is het ultieme doel van open data! Niet dat OSM dan geen nut zal hebben. Sterker, ik denk dat er altijd behoefte is aan een crowd sourced geodataset (OSM is op een aantal terreinen en in een aantal gebieden de meest complete dataset), maar het is mede dankzij OSM dat open data tegenwoordig zo hoog op de agenda staat! Als veel datasets open zijn, dan kun je juist meer uit de datasets halen door ze op allerlei mogelijke manieren te combineren. Het geheel is groter dan de som der delen. En ja, dat geldt ook door verschillende databronnen in OSM te importeren, mits je de consequenties even buiten beschouwing laat.
Dat kan ook door bijv. een WMS-server met BAG-data in JOSM onder de OSM data te hangen. Daar zijn allerlei manieren voor.
Dat vereist een grote update-actie. Als je dat voor alle 7 miljoen BAG-panden in Nederland wil doen (of hoeveel het er ook zijn), dan worden de sys-admins en anderen hier heel zenuwachtig van! Ik word het ook als ik dat voor een paar duizend objecten zou moeten doen. Technisch is heel veel te doen, maar de vraag is of je dat zou moeten willen.
Het opschonen-argument hebben we ook voor 3dShapes gebruikt, dus ik kan zeggen dat dat wel werkt Toch heeft ook dat meer voeten in de aarde, zoals wij door schade en schande achterkwamen. Zie bijv. de discussie over toponiemen op talk-nl afgelopen maart. Verder hebben we de fout gemaakt door de namen van waterwegen in 1e instantie over te nemen op alle 3dShapes vlakken die daar onderdeel van uitmaakten. We wilden immers geen informatie verloren laten gaan. Toen we achterkwamen dat dat niet handig was, hebben we of aparte ways gebruikt (waterway = stream/river/canal, als centerline), of de resterende lineaire AND water ways intact gelaten. Zie o.a. hier een relatief vroeg voorbeeld. Weliswaar een extreem voorbeeld, maar geeft wel duidelijk het probleem aan. Er zijn veel gebieden die ik niet heb opgeschoond. Niet omdat ik het niet wil, maar omdat ik dat niet meer kan opbrengen. Die 3dShapes import heeft mij behoorlijk afgebrand, dat wil je niet weten… Het had ook geen changeset langer moeten duren! Dat gevoel heb ik nog steeds 1 1/2 jaar na afloop.
V.w.b. het verwijderen van bestaande data: voordat je dit doet, probeer zoveel mogelijk in contact te komen met lokale users die redelijk wat bijgedragen hebben. Dat is en blijft een heikel punt, omdat sommigen er niet van gediend zijn dat je in hun achtertuin gaat wroeten. Het is lastig aan te geven wat een goede grens is. Soms denk je dat je wel de instemming hebt van de meeste mensen in een gebied, maar blijkt iemand die jaren geleden een paar wijzigingen in OSM heeft gemaakt en sindsdien niet meer actief is, opeens in de pen te klimmen om zijn ongenoegen te uiten.
Onderschat het hele gebeuren niet! Niemand verplicht je om volgende week al OSM met de BAG te “vullen”!
Er valt wel wat voor te zeggen zo’n extra import account. Zo kunnen we nu al makkelijk de user=3dShapes gebouwen eruit filteren, want hier zitten -neem ik aan- alleen de ‘basis’ tags op. Pas als user=mapper x aan dit gebouw getagd zit wordt het interessant, want dan zijn er soms tags aan toegevoegd.
Zo kan dat straks ook met de updates van BAG data import, gebruiker “user_import” heeft niets extra’s toegevoegd, dus die data kan zondermeer worden vervangen door versere, maar heeft gebruiker “user” eraan gesleuteld dan moet er extra gekeken worden naar die tags.
Het onderstaande schreef ik voor de ik laaste reacties van fsteggink en ligfietser had gezien, maar voor zover ik kan zien verstoor ik de lijn van het verhaal niet door het nu te posten.
Ik sluit mij aan bij het verhaal van Peewee, en wil wat verder gaan op de mogelijkheden voor updates.
De .osm bestanden waarmee we nu aan het testen zijn, worden gegenereerd door een Osmosis plug-in die ik geschreven heb. De bestanden bevatten de BAG objecten van een woonplaats of gemeente. Voor grotere plaatsen zou een postcodegebied praktischer zijn, maar voor zover ik weet zij er geen grenzen van postcodegebieden beschikbaar onder een licentie die in OSM gebruikt zou kunnen worden.
Deze plug-inhaalt de data uit een postgis database opgebouwd door bag-extract (zie nlextract.nl). De actuele en bestaande objecten worden er uit gefilterd en omgezet in OSM objecten.
Alle OSM objecten krijgen 3 tags, waarmee deze herleid kunnen worden naar het bijbehorende BAG record:
ref:bagid
bag:begindatum (De begindatumtijdvakgeldigheid waarde van het BAG record)
bag:extract (De BAG extract zipfile waaruit het record afkomstig is)
Met behulp van deze tags kan een nieuwere BAG extract vergeleken worden met een OSM planet dump.
Hiermee kunnen bestanden met wijzigingen voor een bepaald gebied gegenereerd worden. Daarmee kan een mapper vervolgens weer aan de slag.
Een (of meerdere) Josm plug-ins zouden de mapper kunnen ondersteunen bij het verwerken van deze wijzigingen
en het voorkomen van vergissingen als weggooien van bestaande tags.
Het hele proces is nog experimenteel en niet veel anders dan wat eerder al in dit forum en op talk.nl besproken is. Het enig verschil is dat we testdata beschikbaar hebben in een handzaam formaat.
Alle (opbouwende) kritiek is welkom.
Gertjan
Hoi Frank
Bedankt voor je positieve feedback. Helemaal top. Ik heb niet de ervaring die jij hebt dus daar wil ik graag van leren. Ik nodig je dan ook van harte uit te reageren op het voorstel dat in de maak is. Ik vrees dat het nog wel even kan duren maar dat geeft mi ook niet. Beter laat dan nooit denk ik dan maar. Ik heb op zich geen haast om BAG OSM in te krijgen maar er helemaal niets mee doen ging me wat ver vandaar dat ik deze post heb geplaatst. Ik wil in ieder geval onderzoeken wat de mogelijkheden zijn.
Dat je op de 3dShapes bijna bent afgebrand verbaasd me niets. Lijkt me een enorme klus, zeker als je een groot deel (of was het alles?) zelf hebt gedaan. Mijn idee met de BAG invoer is om zo veel mogelijk mappers van data en een goede handleiding te voorzien zodat ze zelf kunnen bepalen of ze er iets mee willen doen. Gertjan heeft al e.e.a. toegelicht over updates en controles en dat is uiteraard ook erg belangrijk. Ik denk dat een eventuele landelijke invoer van BAG data mbv vele mappers er toe kan leiden dat de “gewone mapper” en de techneuten meer kunnen samenwerken. De techneuten houden zich dan meer bezig met data-conversie , scripts, en hoe de data te onderhouden/controleren is. De mappers zorgen er voor hun gebied voor dat de data er in komt en kunnen naderhand met bv wijzigingsbestanden de boel weer actueel houden. Of dat allemaal haalbaar is zullen we wel zien als de reacties op het voortstel binnen gaan komen.
Voor wat betreft de open data en het ultieme doel hiervan ben ik er nog niet helemaal uit. Ja aan de ene kant ik begrijp dat niet alle open data OSM in gedumpt moet worden. Maar als we helemaal geen opendata OSM in stoppen kan het ook betekenen dat OSM alleen een feestje wordt van de techneuten die precies begrijpen hoe je data kunt combineren en er dan pas iets leuks mee gaan doen. Ik denk dat er voor gebouwen wel een uitzondering gemaakt kan worden omdat je deze in steeds meer landen ziet verschijnen in OSM. Als het al geen gebouwen zijn dan zien we wel steeds meer adressen en dan kan het toch niet zo zijn dat we in NL deze niet opnemen terwijl de data helemaal vrij is. Maar goed de meningen over het wel of niet invoeren van vrije data in OSM zullen altijd wel verdeeld blijven vrees ik.
Het kan overigens best dat ik de boel onderschat hoor… dat zal de toekomst wel uitwijzen. Als ik in ieder geval maar een poging heb gedaan om er uit te halen wat er in zit ben ik al tevreden. 
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