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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl _______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl