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

[Sebastiaan Couwenberg]

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

-- 
GnuPG: 0x77A975AD