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

[Frank Steggink]

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.
>
> 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.

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