De argumentatie van DWG-lid Frederik Ramm dat het opnemen van een ref-tag met een bron-id (zoals het BAG-ID) nog nooit tastbare resultaten heeft opgeleverd is zwak; niet behaalde resultaten uit het verleden zijn geen reden voor niet-slagen in de toekomst. Zo kom je nooit een stap verder. Juist de wettelijke verankering van de BAG maakt dat het BAG-ID een prima kans is om uit te proberen hoe je zo’n regelmatige update vorm kunt geven.
Dat zou trouwens voor “adressen” en “gebouwen” best een verschillende werkwijze kunnen opleveren.
Onder de vlag van de EU Inspire richtlijn (publiceren én EU-breed harmoniseren van geodatasets) in combinatie met de PSI directive (richtlijn hergebruik overheidsdata) zal er de komende jaren in de EU-lidstaten een "tsunami aan EU-breed geharmoniseerde open geodata beschikbaar komen. Het is onzinnig om die potentiële bronnen te negeren, nog sterker: je moet daar als OSM-Foundation wat van vinden.
*Nb. De complete lijst met Inspire thema’s en de daarvoor in NL te gebruiken bronregistratie is te vinden op http://www.gismagazine.nl/blog/laatste-nieuws/compleet-overzicht-nederlandse-dataproviders-inspire. De BAG is bron voor 2 thema’s: “adressen” en “gebouwen”.
Overigens is ook geconstateerd dat de aanduiding “gebruiksdoel” zoals die in de BAG is geregistreerd niet voldoet voor de Inspire-eis om een functie-aanduiding van een gebouw op te nemen. Hier wordt voor NL nog naar een oplossing gezocht (bijv. koppeling met de WOZ). Om die reden is het goed om bij de OSM-BAG-import gebruiksdoel te negeren.
*
Na het lezen van de blogpost van DWG-lid Serge Wroclawski (http://blog.emacsen.net/blog/2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/) proef ik bij de (of in ieder geval bij de DWG-leden Serge en Frederik) weerstand tegen het fenomeen import. Het “echte mappen” is voor hen het er zelf met GPS in het terrein op uitgaan, en dat zou ook het sociale aspect van OSM zijn.
Ik merk daarentegen dat juist de BAG-import een enorm sociaal effect heeft op de OSM-NL community: het heeft tot een reeks druk bezochte bijeenkomsten (Utrecht, Hilversum, Duivendrecht) geleid die de hechtheid van community ten goede zijn gekomen.
(Of vind de OSM-DWG dat we in Nederland een stelletje luilakken zijn, die in plaats van er zelf op uit te gaan om “warm” te mappen vanachter onze PC alleen maar wat imports uitvoeren. En dat bovendien ook nog eens ongeorganiseerd
T.a.v. “source:date” nog een gedachte: je zou in theorie onderscheid kunnen maken tussen achtereenvolgens
de datum van geldigheid (moment waarop adres is ontstaan, moment waarop gebouw is gebouwd)
de datum van het brondocument (bouwvergunning, sloopvergunning) waarop de informatie in de BAG gebaseerd is.
Daarbij zou je 1) aan de changeset kunnen hangen, en 2) of 3) aan de nodes en ways. maar goed, dit wordt allemaal erg complex…
Tenslotte: zoals Johan ook al aangaf: het is mij onduidelijk waar de leden van de DWG op persoonlijke titel spreken, en waar ze dat als DWG doen. Beste lastig, als je niet weet wie er tegen je praat ;-). Gezien de goede discussie op dit forum mag Johan in zijn beraadslagingen met de OSM-DWG van mij aangeven dat hij namens de gezamenlijke BAG-importeurs spreekt.
Er ligt bij ons inderdaad een mooie uitdaging om het update proces uit te voeren. Gertjan (de GJ zonder streepje) is bezig met het doorontwikkelen van de plugin zodat er een update faciliteit in komt. Wat we daarnaast denk ik ook nodig hebben is een slippy map van Nederland waarbij je kunt zien welke adressen wel in de BAG staan maar niet in OSM. Dat gecombineerd met zoveel mogelijk lokale mappers (ongeveer 40 mappers hebben momenteel ervaring met de plugin, liefst zie ik nog meer mappers die de plugin kunnen hanteren) kan bijdragen in het actueel houden van adressen én panden. Tezamen met ground thruth mapping. Zo heb ik al een paar keer het Binnenhof bezocht en de nodige adressen toegevoegd die er wel in het echt zijn maar niet uit mijn BAG import van het centrum van Den Haag kwamen.
Vraag: is een van jullie in staat om een slippy map te maken waaruit blijkt welke adressen wel in de BAG staan maar niet in OSM?
De blog van Serge is interessant. Serge doet het goed in zijn artikel door aan te geven dat hij op persoonlijke titel spreekt. Ook legt hij niet dwingend zaken op die anderen maar uit te voeren hebben op straffe van blokkering/revert. Serge is trouwens ook een van de mensen achter de import van de gebouwen en adressen in New York city.
Ik heb eerder wat contacten gehad met wat mensen binnen de Future Group over adres- en gebouwimports. Uit die discussie kwam vooral naar voren dat het probleem vooral in de tools zit. Naarmate de data density toeneemt in OSM wordt het zeker voor beginners lastiger om te werken. Hoe mix je een hoge data density met toegankelijkheid? Een hoge data density an sich is niet het probleem. Het vermijden van een adresimport (de Fransen doen dat momenteel) lijkt op het werken met lagen zoals professionele pakketten werken. Maar ook lagen hebben een groot nadeel: met het model van OSM krijg je dubbelingen. De oplossing die uit de discussie met de mensen binnen de Future Group kwam: niet proberen om een hoge data density te voorkomen, maar samen met allerlei soorten gebruikers gaan werken aan slimmere tools.
Een volstrekt ander punt: ik maak mij zorgen over de governance in OSM. Frederik Ramm is in staat om in zijn eentje te besluiten om geheel Nederland (of Duitsland, of…) volledig van de kaart te vegen zonder dat hij daarover verantwoording hoeft af te leggen en zonder dat de getroffen personen/community in staat zijn zich te verdedigen. Die machtspositie gaat goed zolang je integer en delicaat daarmee omgaat. Zo hebben ook de sysadmins een grote machtspositie, en ik heb geen enkel signaal dat zij hun positie misbruiken. Maar de machtspositie van Frederik, die duidelijk wordt uit de wijze waarop hij afgelopen vrijdag communiceerde, roept bij mij een onbehagelijk gevoel op. Zo van ‘als we hem nu gewoon zijn zin geven en niet tegen zijn opvattingen ingaan, dan is er in ieder geval geen risico voor onze import.’. Die wijze van ‘appeasement’ moet ik bij mijzelf continu onderdrukken. Want ja, ik voel een grote verantwoordelijkheid voor de import en ik wil niet dat die bedreigd wordt. Anderzijds: als je een machtig iemand nooit tegenspreekt… Ik wil even niet aan die gevolgen denken. Dan krijgen we een dictatoriaal regime binnen OSM.
Concrete vragen t.a.v. governance: 1) wat is het mandaat van de DWG 2) Wat is het mandaat van een DWG lid 3) Wie ziet toe op het functioneren van de DWG 4) wie ziet toe op het functioneren van een DWG lid 5) op welke wijze legt de DWG verantwoording af 6) op welke wijze legt een DWG lid verantwoording af 7) welke afspraken zijn er voor een DWG lid om kenbaar te maken in welke hoedanigheid hij/zij functioneert 8) als de DWG of een DWG lid besluiten heeft genomen namens de DWG, in hoeverre is er dan een mogelijkheid voor diegenen die getroffen worden door het besluit om bezwaar aan te tekenen bij een onafhankelijk orgaan binnen OSM
Spreek me gerust tegen als jullie hier een andere opvatting over hebben.
Cheers, Johan
ps ik post de eerder door mij aangekondige concept reactie op Frederik (op proces, nog niet inhoudelijk) vanavond, eerst ff genieten van het lekkere weer
helemaal mee eens. Ik heb zelf een redelijk groot deel van Brabant geïmporteerd en de meeste tijd is gaan zitten in het verbeteren van de al aanwezige data, handwerk dus. Als al deze tijd voor niks blijkt te zijn geweest denk ik niet dat ik ooit nog zin heb om ook maar één node te editen.
Inhoudelijk:
ik ben het er mee eens dat de overdaad aan speciale tags zaken erg complex kan doen lijken voor een beginnende mapper. Een jaar geleden vond ik het AND en 3D-Shapes tag schema nog erg verwarrend. Nadat ik had uitgevonden hoe het met die imports zat waren deze tags nog steeds niet duidelijk maar maakte ze het wel makkelijk om te zien waar de data vandaan kwam en dus ook hoe vrij ik me kon voelen om de data te wijzigen.
Het lijkt mij dan ook belangrijk om de herkomst van geïmporteerde data herkenbaar te houden. Dit, in combinatie met goede documentatie gaat het voor beginnende mappers juist makkelijker maken om te beoordelen hoe voorzichtig/vrij ze moeten/mogen zijn met de data.
Echter de “ref:bag” tag impliceert “source=BAG” dus die laatste mag wat mij betreft verdwijnen. Hoewel andersom misschien logischer en semantischer is: “source=BAG:id123456789”. Op deze wijze heb je de ref tag niet meer nodig en is je bron een stuk preciezer. (Als je naar een boek van 1.000.000en pagina’s verwijst is het best handig om het pagina nummer er bij te zetten…) Bonus: deze aanpak haalt het “zet de source-tag maar op de changeset” argument onderuit.
Bij het nut van de “source:date” tag heb ik ook mijn twijfels. ik vraag mij af hoe nuttig deze gaat zijn bij een update (zeker aangezien deze datum ook op de changeset staat). Het toevoegen van een datum waarop het pand voor het laatst in BAG gewijzigd is lijkt mij nuttiger. Om hier achter te komen zullen we moeten nadenken over en experimenteren met de updates. Ik kan mij ook goed vinden in de opmerking van Sander:
We kunnen een boel zeggen over Fredrik en zijn wat ongenuanceerde uitspraken. Het is hem wel met 1 opmerking gelukt om ons weer een beetje wakker te schudden en de dicussie te starten over hoe we de geimporteerde BAG gegevens gaan onderhouden.
De source, source:date en ref:bag tags zijn immers vooral bedoeld om het mogelijk te maken om oude en nieuwe BAG gegevens te kunnen vergelijken.
Zelf heb ik al wel wat ideeen hier over en ik ben bezig om functionaliteit hiervoor aan de plug-in toe te voegen. Maar ik zou het erg prettig vinden om met een clubje van een paar man hier in te duiken en een goede procedure uit te werken.
Zoals ik het nu zie, hebben we daar 2 zaken voor nodig:
Een server gedeelte die (bijvoorbeeld 1x per maand) uitzoekt wat er veranderd is de resultaten aan bied aan de mapper.
De uitgebreide plug-in, waarmee de mapper de wijzigingen kan controleren en verwerken.
Wie heeft er zin en tijd om hier over mee te denken?
Wat de tags betreft, kom ik mede naar aanleiding van deze discussie en de opmerkingen van ‘de vries’ tot de conclusie dat we ze volgens mij niet allemaal nodig hebben.
Voor gebouwen wordt source=BAG geïmpliceerd door de aanwezigheid van de ref:bag tag en is de source tag dus in feite overbodig. Voor adres-nodes wordt het wat lastiger, maar zou je kunnen stellen dat het adres uit de BAG komt, als het valt binnen een BAG gebouw.
Nu de nieuwe BAG WFS dagelijkse updates geeft, zal de datum in source:date in de praktijk gelijk zijn aan de datum waarop de osm node of way het laatst gewijzigd is. De source:date tag woordt daarmee voor nieuwe imports overbodig. Voor eerder geïmporteerde adressen en gebouwen zou de update procedure eenmalig moeten controleren of er iets is gewijzigd tussen source:date en de datum waarop het OSM gebouw of adres is aangemaakt.
Uiteindelijk zouden we dus kunnen volstaan met de ref:bag tag.
Als er op zijn minst een plan voor verder onderhoud van de gegevens is (en als die ook nog te lezen is voor de niet-Nederlandstaligen), lijkt het me minder bezwaarlijk om die BAG-refs te hanteren.
Ik heb ik dag per week die ik aan Debian en OSM kan weiden, dus ik heb tijd maar ook zin om te denken over de BAG infrastructuur.
We moeten wel oppassen met aannames als over de source:date, de externe services zijn variabel en niet onder je controle. Ook worden BAG paden nu al nabewerkt, en komt de laatste wijziging van een pand al niet meer overeen met diens import datum.
Ad.1 Ik zou zeggen laat source=BAG weg bij de gebouwen, maar laat ze staan bij de adres-nodes. Dat maakt het duidelijker als je aan het editen bent.
Ad.2 Hier (en ik heb het ook in eerdere discussies over updaten geproefd) gaat één impliciete aanname mis. De BAG data is goed en compleet, maar heeft een veel beperkter doel dan OSM. Er zullen dus meer dan genoeg objecten zijn die worden bewerkt voor het toevoegen van andere data. Denk aan: Winkel-/bedrijfsnamen, fatsoenlijke integratie met andere OSM data als landuse en wegen, 3D gebouwen, etc …
Ik vindt dat verhaal van Serge Wroclawski maar tegenstrijdig. Zeker als ik het combineer met m’n eigen ervaring.
Ja veel data is lastiger te onderhouden, maar dat geld ook voor Duitsland waar ze “alles” met de hand hebben verzameld. Die tags met externe ID’s en de source maken dat niet lastiger. Ze maken het juist duidelijker waar iets vandaan komt. Die gegevens wegmoffelen in de changeset is met de huidige editors helemaal geen optie. Volgens mij kun je daar met de iD-editor helemaal niet bijkomen en in JOSM vereist het te veel handelingen om dat voor elk object dat je bewerkt te bekijken. De tags op een object zie je echter al met één klik.
Misschien ben ik wat naief maar ik kan me niet voorstellen dat Frederik Ramm/Woodpeck zonder enig overleg met de NL community de boel gaat terugdraaien. In de import is inmiddels duizenden uren werk gaan zitten en dat was zoals anderen al aangeven niet alleen een verbetering tav panden en adressen maar heel OSM NL heeft een kwaliteitsslag ondergaan. Zoals anderen al aangaven kan, als hij zijn zin wil doordrukken, een beter alternatief bedacht worden dan het terugdraaien van alles. Ik ben benieuwd naar de reactie van Johan maar hoop dat we over een tijdje kunnen concluderen dat het een storm in een glas water bleek te zijn.
… kantoorgebouwen van niet-commerciële entiteiten, ondergrondse gebouwen, ligplaatsen, …
M.a.w. er blijft meer dan genoeg over voor gebruikers met lokale kennis.
Kunst is om men erbij te betrekken.
En eerlijk gezegd, ik ben wel gevoelig voor de stelling dat OSM het moet hebben van mensen die naar buiten gaan en mappen wat er is met specifieke kennis van de situatie. Ik heb ook genoeg fout zien gaan met “remote mapping” met onze fietsroutes.
Ik zeg hiermee niet dat ik tegen imports ben. Ik sta achter de BAG-imports en was ook een voorstander van 3DShapes. Het stelt ons in staat om de kaart completer te maken dan dat we dat ooit anders hadden kunnen doen.
Misschien moeten we “ze” ook duidelijk maken dat we dat ook zien en met deze activiteiten de community in Nederland daadwerkelijk stimuleren.
Er is een vaak herhaalde aanname dat imports de ontwikkeling van een lokale OSM-gemeenschap afremt. De AND-import wordt hierbij expliciet genoemd als een reden dat er niet zo veel Nederlandse mappers actief zijn.
Ik denk zelf dat het helemaal niet bewezen is hoe dit werkt binnen OSM (of daarbuiten met het ontwikkelen van online communities of practice).
Wat opvalt op dit moment is dat er meer discussie plaatsvindt hier dan op talk-nl. Zouden we niet iemand van Delft onderzoek hiernaar laten doen?
dat “uitzoekt wat er veranderd is” mag je nog even toelichten.
Het BAG processenhandboek http://www.kadaster.nl/web/artikel/download/BAG-processenhandboek-2013-1.htm is daarbij een fijne hulp. Laat je niet afschrikken door de 256 pagina’s, eigenlijk blader je er zo doorheen. Het gaat voor ons vooral om hoofdstukken 2 en 3, bij elkaar slechts 100 pagina’s. Het geeft voorbeelden van wat er gebeurt in de BAG-registratie als een pand wordt gesloopt of in vlammen op gaat, er een schuurtje wordt aangebouwd etc. In de kern: het ID blijft hetzelfde, echter het veld status wordt aangepast, en -afhankelijk van de aard van de wijziging- enkele andere velden
Wat scenario’s:
Bij sloop is het simpel, alles wat er door een mapper na de import aan gewijzigd is kan gelijk met het pand de prullenbak in.
Een rottige is misschien de BAG-statuswijziging van “in gebruik, niet ingemeten” naar “in gebruik, ingemeten” (par. 2.4.2). Daarbij wordt de ruw bepaalde geometrie (pandcontour) vervangen door een contour die heel nauwkeurig door de dienstdoende landmeter is ingemeten. Dat wordt wat vervelend als in de tussentijd een mapper de contour zélf al heeft verfijnd.
Verder zijn aanbouwen wat lastig; het is even puzzelen met wat een uitbreiding van een bestaand pand is, en wat een zelfstandig nieuw pand is.
Hierbij mijn voorstel voor een posting als procesantwoord op Frederik, zoals ik dat morgen- of dinsdagavond wil versturen. Zoals eerder door mij aangegeven volgt een inhoudelijk antwoord op zijn verzoek later. Mijn reactie is bewust in de eerste persoonsvorm enkelvoud geschreven omdat hij in eerste aanleg mij aanvalt op het proces. Tevens stel ik zeer bewust enkele vragen, dat werkt vaak beter dan op elkaar inhakken met stellingen (zoals “I note that this discussion has not been completed”)
Graag jullie reactie.
__
@ Frederik I’m not quite sure I understand you. The posts you are quoting are not the last ones about this import. Could you clarify your request?
Another part of my uncertainty about understanding you is that it’s not clear in what role you are requesting this: as an individual import list member like myself, or is it a clarification you ask on behalf of the DWG?
A third point is that I feel your last sentence to be a sort of threat. You could know that I always answer to questions, in contrast to several other community members. Your message would have been clear without the last sentence. It makes me even more unsure, since it makes me aware that you are in a powerful role which enables you to both set rules and to enforce these rules. Instead of a level communication amongst OSM’ers, there is an unequality now. What was your reason to use that sentence?
Furthermore you should know that I have taken back your request to the Dutch community. Since around 40 people are involved in importing I find it important that everyone of them has the chance to speak out. Since it’s a habit in the Dutch community to allow members ample time to respond to topics it will take a few days before a response to your request is finished. Your answer to my three questions will also be important for that response. I’m looking forward to your answers.
@ DWG members I’m interested in hearing your opinion on this matter
Mmh. Nee. Dat hangt helemaal af van wat men er mee gedaan heeft.
Voordat we het werk van mensen schrappen op basis van een geautomatiseerde (en per definitie onvolmaakte) externe systeem is het op zijn minst nodig om de mapper te informeren (als die nog actief is). Kan hij/zij nog even langs om te verifiëren dat het klopt.
Allereerst: De opmerkingen van Frederik cs zijn niet besproken in het bestuur van de OSMF. Daarnaast heeft het bestuur ook nooit een positie ingenomen over hoe om te gaan met imports.
Wanneer we het over imports hebben en het gebruik van tags, dan is (naar mijn mening) de belangrijkste vraag: heeft een tag nut. Er zijn in het verleden wel eens imports gedaan zonder erbij na te denken of de informatie (of specifieke tags) eigenlijk wel interessant genoeg was. Dit kan als gevolg hebben dat OSM wordt gezien als een dumpplaats voor allerlei soorten van (open) geodata. Dat is uiteraard niet de bedoeling.
Hiermee wil ik niet impliceren dat dit het geval is bij de huidige BAG import; integendeel.
Terecht snijdt Johan het onderwerp van governance aan (en GeeJee [met streepje] in zoveel woorden ook). Wat de DWG doet staat beschreven op http://wiki.osmfoundation.org/wiki/Data_Working_Group. Echter, daarmee beantwoord je nog niet alle vragen die Johan stelt. Op veel van die vragen is op dit moment ook geen eenduidig antwoord te geven (als je kijkt naar wat het standpunt is van de OSMF). Pogingen om hierin helderheid te krijgen verzanden vaak in opmerkingen als “dan wordt het veel te bureaucratisch”; “het is vrijwilligerswerk, dus het moet wel leuk blijven”; “het is iets voor de community, niet de OSMF”; etc etc.
Neem daarbij het fenomeen dat sommige mensen zo overtuigd zijn van hun eigen gelijk, dat het moeilijk is om die discussie verder te brengen.
Hoe dan ook, ik zou graag met jullie verder willen denken over dit soort zaken (governance dus). Ik heb daar wat gedachten bij, maar dat gaat te ver om die hier nu “even” neer te leggen.
Aangezien het mooier weer begint te worden, een idee om hier eens een keer een terrasje ergens centraal in NL te pakken?
Hallo Johan,
Allereerst bedankt voor je actie.
Het lijkt mij echter ook belangrijk om te benadrukken dat de import niet slechts een import is, maar ook een kwaliteits verbetering. Iets in de trand van:
Nuttig om dat ook te melden, maar als hij hiermee zegt dat hij liever geen --of niet al te veel-- gebouwen ziet in OSM, begrijp ik dat (vanuit zijn optiek als dataverwerker) maar accepteer ik het niet (als OSM-mapper EN als afnemer van kaarten op basis van OSM).
Om maar één voorbeeld te noemen: Gebouwen en landcover zijn als je loopt (of, iets minder, als je fietst) van belang voor oriëntatie en ter bevestiging dat je inderdaad loopt waar je denkt dat je loopt. Op langeafstandpaden is het mislopen een regelrechte ramp en zijn routebeschrijvingen niet altijd accuraat of begrijpelijk (en markering soms ontbreekt).
Een technisch probleem (te veel data) zal een technische oplossing moeten vinden, niet een beperking in functionaliteit.
(Ik zeg niet dat je dit nu moet oprakelen, anders had ik een Engelse tekst erbij verzonnen.)
Die eerste extra paragraaf van hvdwolf is wel een aardige toevoeging. Die tweede zou ik nu nog niet gebruiken, die is al te veel inhoudelijk en niet procedureel.
