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

2012-10-21 Berichten over hetzelfde onderwerp 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 

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

2012-10-21 Berichten over hetzelfde onderwerp Cartinus
On 10/21/2012 04:04 PM, 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

snip


 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.

De gebouwen kunnen goed in kleine hapjes worden geïmporteerd. Voor de
woonplaatsgrenzen is dat denk ik echter vragen om problemen, die zijn
veel te veel verweven met elkaar.

 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.

Waarom het wiel opnieuw uitvinden? ogr2osm is voor zover ik weet
speciaal ontwikkeld voor het importeren (als multipolygonen) van
aansluitende vlakken.

- - - - - - - -

De rest van het verhaal klinkt goed.


-- 
---
m.v.g.,
Cartinus

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl