[OSM-talk-nl] BAG data en de Import Guidelines
Sebastiaan Couwenberg
sebastic at xs4all.nl
Sun Oct 21 14:04:55 UTC 2012
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
More information about the Talk-nl
mailing list