[OSM-talk-nl] BAG data en de Import Guidelines

Pander pander at opentaal.org
Sun Oct 21 16:01:17 BST 2012


On 2012-10-21 16:50, Frank Steggink wrote:
> On 21-10-2012 16:04, Sebastiaan Couwenberg wrote:
>> Nu de discussies over het importeren van BAG data goed op gang komen
>> heb ik eens gekeken hoe hiervoor rekening te houden met de Import
>> Guidelines [1]. We zijn al een heel eind op weg wat dat betreft, maar
>> nog niet aan alle details is al invulling gegeven.
>>
>> [1] http://wiki.openstreetmap.org/wiki/Import/Guidelines
>>
>> De checklist noemt acht punten om rekening mee te houden.
>>
>> "1.  Gain familiarity with the basics of OpenStreetMap, including
>> editing, such as adding details of your neighbourhood. Consider
>> following the beginners' guide."
>>
>> Ieder van ons voldoet aan dit criterium. Het is inderdaad niet
>> verstandig als nieuwe mappers direct aan de slag gaan met BAG data
>> voordat we hier een beginners vriendelijke handleiding voor hebben
>> opgesteld.
>>
>> "2.  Contact the relevant local OSM community to make sure you're not
>> heading down a path someone else has tried and to get a sense of how
>> receptive the community is to imports. Check for local user groups,
>> local chapters, and country-specific mailing lists."
>>
>> De discussies met de lokale community zijn gestart op de mailinglist
>> [2] en forum [3], en de reacties tot nu zijn nog niet echt negatief.
>> Ik verwacht geen bezwaar van de NL community tegen de BAG imports
>> zolang de uitvoering hiervan geen problemen gaat verzorgen. Zolang de
>> BAG panden maar geen custom edits verwijderen, en BAG woonplaats
>> grenzen de bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg
>> vrij. Maar het is ook nog wat vroeg om over duidelijke consensus te
>> spreken. Nog niet veel verschillende mensen hebben zich in de
>> discussies gemengd. Veel meer mensen verwacht eerlijk gezegd ook niet
>> echt, er zijn niet erg veel NL mappers die zich ook nog eens met de
>> community communicatie bezig houden lijkt het.
>>
>> [2]
>> http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html
>> [3] http://forum.openstreetmap.org/viewtopic.php?id=18311
>>
>> "3.  Check the license of the data. If the license of the data is not
>> compatible with the OpenStreetMap license, you can not use the data."
>>
>> De open data portal van de Nederlandse overheid [4] is heel expliet in
>> de vrije licensering van de BAG data. Licentie: Publiek Domein.
>>
>> [4]
>> https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag-
>>
>>
>> Op de home page van de open data portal staat dit wat uitgebreider:
>> http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
>> "Wat is open data?
>>
>>  *  De data is openbaar;
>>  *  Er berust geen auteursrecht of andere rechten van derden op;
>>  *  De data zijn bekostigd uit publieke middelen, beschikbaar gesteld
>>     voor de uitvoering van die taak;
>>  *  De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières
>>     voor het gebruik door ICT-gebruikers of door ICT-aanbieders);
>>  *  Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines
>>     informatie in documenten kunnen vinden."
>>
>> De situatie rond de postcode is mogelijk nog wel een struikelblok.
>> Ondank dat de overheid de data vrij geeft, procederen PostNL en
>> Cendris nog steeds tegen het vrij geven van de postcode database. Zie
>> de dreigbrief tegen postcodeatlas.nl:
>>
>> http://www.postcodeatlas.nl/pages/postcodebestand.html
>>
>> In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes
>> die de overheid van PostNL krijgt niet uit het postcodebestand van
>> PostNL noch de postcodetabel van Cendris komen, en de databaserechten
>> die beide partijen hebben niet van toepassing zijn op de postcodes in
>> de BAG. Dat na de privatisering van de PTT het toewijzen van postcodes
>> niet meer door een overheidsinstantie gedaan word maakt het tot een
>> vreemde situatie. Alle drie partijen stellen nu hun eigen database op
>> met de gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger
>> als staatsbedrijf onder een dak deden. De BAG database van de overheid
>> word duidelijk als losstaand werk gezien, wat geen afgeleide is van de
>> postcode databases van PostNL en Cendris.
>>
>> Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6].
>>
>> [5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147
>> [6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf
>>
>> Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis
>> geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de
>> BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal
>> gaan betalen voor het gebruik van de postcodes. Wat OSM betreft zullen
>> we de postcodes dan mogelijk achterwege moeten laten bij het
>> importeren indien de postcodes uit de BAG niet vrijelijk gebruikt
>> mogen worden. Ik kan alleen geen informatie vinden over het beroep wat
>> PostNL tegen het vonnis zou hebben aangetekend.
>>
>> Heeft iemand meer informatie over de huidige stand van zake in deze zaak?
>>
>> "4.  Find out what data layers the organization offers. This might be
>> street centerlines, building outlines, waterways, addresses, etc."
>>
>> Gebouwen, adressen en administratieve grenzen. Binnen de BAG bekend
>> als de PND, NUM en WPL data sets. De stand- en ligplaatsen zijn ook
>> nog beschikbaar, maar de kadastrale percelen zijn een bekend bezwaar
>> punt qua importeren.
>>
>> "5.  Discuss with the community the suitability of each layer for
>> importing. Some data can be readily imported without much difficulty,
>> while others are far more difficult (e.g. street centerlines). Also
>> some are broadly accepted for import, while others haven't had much
>> consensus (e.g. parcel boundaries)."
>>
>> We beperken ons tot dusver tot de panden, adressen en woonplaats
>> grenzen. Deze kunnen we nog apart ter discussie stellen, die gaat nu
>> voornamelijk over de panden die allen qua adres en preciezere
>> geometrie meerwaarde hebben ten opzichte van de 3dShapes gebouwen die
>> we al hebben.
>>
>> Bezwaar tegen het integreren van de woonplaats grenzen verwacht ik
>> niet. Zeker niet in de plaatsen waar deze nog niet of niet meer
>> aanwezig zijn. In de provincie Groningen ontbreken er bijvoorbeeld een
>> hoop, en als ze er wel zijn zijn het vaak nog geen multipolygons maar
>> boundary relations.
>>
>> Een deel van de grenzen is destijds uit de AND data geimporteerd, een
>> deel is uit dataportal.nl overgenomen (een eerdere poging van open
>> data vanuit de overheid), en een deel is (in het Noorden iig) door
>> enkele mappers overgetekend van overheids data.
>>
>> We hebben nu toegang tot de meest authoratieve bron voor deze grenzen,
>> waardoor ik geen bezwaar verwacht tegen het gebruik hiervan. Maar
>> natuurlijk onder voorwaarde dat dit zorgvuldig gebeurt. Het is erg
>> makkelijk om aangrenzende boundaries incompleet te maken bij het
>> splitsen van gemeente grenzen ten behoeve van de woonplaats grenzen
>> daarin.
>>
>> Voor het opnemen van de grenzen moeten we denk ik ook een "officiele"
>> procedure ontwikkelen al dan niet geautomatiseerd. Ik meen dat de
>> Deense community een bot heeft draaien die de grenzen daar automatisch
>> corrigeert met de meest recente overheids data, zoiets wil ik voor
>> Nederland ook. Maar tools die het makkelijk maken om de grenzen in OSM
>> op te nemen zonder andere boundaries te slopen vind ik ook wel een
>> goed idee. Ik denk dat de woonplaats export de ways vast moet splitsen
>> op de punten waar grenzen bij elkaar komen om het eenvoudiger in OSM
>> op te nemen. Dit kan in de osmosis plugin, of ik kan daar een script
>> voor schrijven om mee te beginnen.
>>
>> "6.  Develop with the community a process to convert the data to the
>> OSM XML format. This will include defining how to translate data
>> attributes to OSM tags, and how to properly convert the geometry,
>> including any cleanup and simplification that might be necessary."
>>
>> Met dit punt zijn we nu ook op weg, dus moeten we even kijken waar de
>> discussies tot leiden.
>>
>> "7.  Develop with the community a process to conflate the converted
>> data with OSM. This might include breaking the data into manageable
>> chunks, and using the wiki or some other method for assigning chunks
>> to users."
>>
>> Die is nog een redelijke open issue, waarvan we de details nog moeten
>> uitwerken. Ik denk dat de mappers voor een groot deel dit punt
>> invulling moeten geven.
>>
>> "8.  Develop with the community a quality assurance process."
>>
>> Dit is denk ik het belangrijkste punt. Hoe zorgen we ervoor dat de BAG
>> data in OSM komt zonder problemen te veroorzaken. Ik zou graag wat
>> checks als OSMI doet op de aangepaste data willen doen voordat ik het
>> upload, zo hoef ik geen week te wachten tot de view is geupdate om te
>> zien of ik grenzen heb gesloopt of niet. Ik ben daar heel zorgvuldig
>> in, maar de praktijk heeft aangetoond dat ik het niet altijd
>> zorgvuldig genoeg deed.
>>
>> Een pre-upload hook in JOSM indien mogelijk lijkt mij een idee, maar
>> ik heb geen idee wat de mogelijkheden daarvan zijn. Daar zal ik in
>> moeten duiken, waarbij ik wel de disclaimer moet plaatsen dat ik geen
>> Java programmeur ben, ik heb hier alleen 10 jaar terug op de hoge
>> school een semester wat mee gedaan en daar is het bij gebleven. Heel
>> vlot zal de ontwikkeling dus niet gaan vrees ik.
>>
>> Dan blijven er nog de nieuwe regels over die buiten de checklist
>> vallen. Wanneer we de details verder uitgewerkt hebben wat we gaan
>> doen en hoe, kunnen de we wiki pagina gaan schrijven en dit in de
>> discussie op imports@ te gebruiken. Als de user account switcher in
>> JOSM waar over gesproken word in de nieuwe draad op talk@ over de
>> Franse Cadastre import [7], daadwerkelijk ontwikkeld word maakt dat
>> het leven voor ons ook makkelijker. Ook iets om mee te nemen in de
>> discussie op imports@ denk ik. In die discussie moeten we
>> waarschijnlijk ook een deel van details uitwerken simpelweg om met de
>> wensen van de DWG en de sysadmins rekening te houden.
>>
>> [7]
>> http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
>>
>> Ik ben erg benieuwt naar de ideeën die men heeft over de praktische
>> invulling van de Import Guidelines wat de BAG data betreft. Vooral wat
>> betreft de QA.

Misschien kan de lijst die ik aan Gertjan ga geven hier een bijdrage aan
leveren. Daar kunnen bepaalde coderings- en typefouten mee gevonden
worden. Ook al zullen de bestaande fouten gecorrigeerd worden is het
raadzaam er in de toekomst op te blijven controleren.

>> Mvg,
>>
>> Bas
>>
> Dag Bas,
> 
> Goede punten en goed dat je dit tegen de imports guidelines aanhoudt.
> 
> V.w.b. de postcodes: Stefan kan je daar ongetwijfeld van alles over
> vertellen.

https://nl.wikipedia.org/wiki/Postcode#Postcodes_in_Nederland
https://nl.wikipedia.org/wiki/Lijst_van_postcodes_in_Nederland

> V.w.b. betrekken van de imports-mailinglist: zodra de plannen concreter
> worden moeten we hen inlichten. Ik denk niet dat we de hele import daar
> moeten bespreken, maar dat op talk-nl en het forum moeten blijven doen.
> We moeten i.i.g. de zorg wegnemen die bij anderen leeft m.b.t. imports.
> Dus met een goed en helder plan komen. Ook moeten we hier melden wat we
> met de 3dShapes-gebouwen gaan doen, voordat we worden beticht van
> grootschalig vandalisme.
> 
> Ik denk dat het nog te vroeg is om de imports-lijst nu al op de hoogte
> te stellen. Eerst moeten we het update-proces helder hebben. We gaan
> daar vast vragen over krijgen, dus het lijkt me beter om goed beslagen
> ten ijs te komen (en anders ben ik niet te beroerd om op Imports die
> vraag te stellen ;) ). Een ander punt van discussie is koppeling van
> adressen aan gebouwen. Adressen toevoegen aan de vbo's/panden of los
> laten? Hoe omgaan met adressen van flatgebouwen?
> 
> V.w.b. de documentatie van het proces: dit wordt niet in de 8 punten
> genoemd, maar dit moeten we uiteraard wel doen. De meest geschikte
> plaats hiervoor is de wiki. Er is al een BAG-pagina [1], die we moeten
> herinrichten. Voor de internationale community zouden we een vertaling
> met de hoofdpunten kunnen maken. Hierop worden dus de zaken die besloten
> zijn vastgelegd, openstaande punten, evt. planning, etc. Discussies
> horen hier niet thuis. (Het kan wel op de talk-page, maar we hebben al
> talk-nl en het forum...)
> 
> Punten voor de wiki:
> * Uitleg wat de BAG is (+ licentie, etc.).
> * Importproces.
> * Omgaan met bestaande data (3dShapes, tags).
> * Updateproces.
> * Betrokkenen, rol.
> 
> Groeten,
> 
> Frank
> 
> [1] http://wiki.openstreetmap.org/wiki/BAG
> 
> 
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl




More information about the Talk-nl mailing list