Idee om wat met BAG te gaan doen

Prima, ik mail je vast een woonplaatsbestand van Leusden om een indruk te krijgen.

Gertjan

Hallo,
omdat er maar niets gebeurde heb ik geprobeerd of ik zelf BAG kon gebruiken.

Met “BAG Exctract Conversie” heb ik een bag van nederland ingelezen en 1 gemeente omgezet naar een shape bestand.
De output is niet direct compatible is met JOSM.
Dit shape bestand heb met QGIS ingelezen en daarna opgeslagen met de juiste CRS.
Deze heb ik ingelezen met de opendata plugin in JOSM.
Na opslaan had ik een osm (xml) bestand met de gebouwen van de gemeente.
Met ‘find en replace’ heb ik de tags in het xml bestand geconverteerd.

Het werkt ook voor de huisnummers. De Postgis database bleek voor de conversie niet nodig.

Voor het mergen heb ik in JOSM ‘Simplify area’ uitgevooerd in verband met ronde gebouwen. (Let op be gebruik: De standaard angle-treshold is te grof)

Het probleem waar ik tegenaan liep is dat de BAG erg veel fouten bevat. (De validatie in JOSM vond ongeveer 1 fout per 3 gebouwen)
Veel gebouwen bevatten niet bestaande verspringingen in de muren.
Veel gebouwen overlappen elkaar.
Er staan meerdere nodes op 1 positie.
Veel gebouwen staan er dubbel in, vaak verschoven in locatie.

Deze fouten moeten natuurlijk niet in OSM terecht komen.
Sommige van deze fouten kunnen generiek worden verholpen. Dat scheelt veel handmatig werk.

Vervolgens ontving ik het volgende bericht:

Mijn vraag is: hoe consulteer ik de local community en de imports@ mailing list.
Kan iemand mij verder helpen?
Groet, Mark

Gertjan, ik en nog een paar anderen zijn nu e.e.a. aan het testen. Ik stel voor dat je daar bij aanhaakt zodat we met 1 strategy de data OSM in krijgen. Onze opzet is om de lokale mapper van data en handleiding te voorzien zodat met lokale kennis huidige OSM gebouwen verwijderd kunnen worden en nieuwe BAG data toegevoegd kan worden. En dat dan ook zo veel mogelijk met behoud van tags op huidige gebouwen. Ons plan is nog niet rijp genoeg om het al breeduit op een forum te bediscussieren of in een wiki te beschrijven. Ik stuur je een PB.

Ben nu bezig met de Vinex wijk Vathorst. Meeste tijd kost het om de associated street relaties te koppelen aan de straten op OSM (zie ander topic).
Ik vraag me af wat het nut hiervan is, kost erg veel tijd. Is het wel noodzakelijk om een dedicated account te gebruiken voor deze imports?
Ik zie tijdens het importeren ook veel fouten op OSM die ik meteen meeneem (wegen die niet goed liggen, classificaties die niet kloppen, straatnamen die onjuist zijn of ontbreken).
Dat soort zaken valt niet onder de BAG import.

Als je alleen de BAG data knipt & plakt, denk ik dat de DWG jongens je in het zelfde schuitje als de Franse Kadaster importers plaatsen. Daarover is laatst op talk@ flink over geflamed. Wat wij met de BAG doen lijkt aardig op de Franse Kadaster workflow, dus is het geen geheel verkeerde interpretatie.

Als je de BAG data gebruikt om deze te intergren, dus meer dan alleen cut&paste, vind ik niet dat dit onder importeren valt en daarvoor een apart account nodig is. Ik teken voor alle gebouwen die ik importeer ook de opritten, en andere toegangswegen. Dit kost een hoop meer tijd dan simpel importeren en zorgt voor een hogere kwaliteit, waardoor de DWG jongens ook wat minder snel zullen zeuren. Als je dit per wijk upload blijven je uploads ook binnen de perken waardoor de sysadmins niet gaan stressen voor de hoge load die grote imports/uploads veroorzaken.

Als je daarna de wijken die je hebt voorzien van BAG data in de gaten houd via OSMI en andere Quality Assurance tools hou je de DWG jongens helemaal tevreden. Ze zijn voornamelijk erg anti blind importen heb ik het idee. Voor mijn werk met de BAG data hebben ze me nog niet aangesproken. En dat terwijl ik het had gepresteerd een gat in de NL/DE grens te maken bij het aanpassen van woonplaats grenzen in Groningen. Dit heb ik meteen gefixed toen ik de errors in OSMI voor mijn werkgebieden zag, alleen op de JOSM validator vertrouwen is niet genoeg.

In een maand tijd of zo, heeft ruudblanken Gorinchem van de BAG data voorzien, dat is inmiddels dacht ik al een jaar geleden gebeurt, en het ziet er goed uit.
Geen idee hoe hij dat gedaan heeft, misschien dat hij meer licht op deze zaak kan werpen.

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

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 :slight_smile: 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. :wink:

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.