[OSM-talk-nl] Semi automatisch BAG voorstel

[Frank Steggink]

Hoi Robert,

Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is 
geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild aan.

On 11-11-03 08:59 PM, Robert Elsenaar wrote:
>
> Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in 
> gemeentegrenzen. Dit is niet relevant voor het idee.
Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige 
onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer 
ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje 
Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in 
gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten voor 
een onderverdeling in 4-cijferige postcodegebieden. Dit is behapbaar, 
omdat de spreiding in omvang veel minder divers is dan bij gemeenten, 
laat staan een willekeurig grid. De postcodes zelf kunnen weliswaar nog 
niet gebruikt worden, maar we kunnen de data wel zo opknippen.

> Voor elk van deze 'blokken' kan de
> gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data.
> Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag 
> gedaan kan worden.
> - Het moeder systeem heeft alle updates van BAG opgesplitst in 
> 'blok-updates'. Merk op
> dat voor ieder blok niet voor iedere maand een update is. Bij geen 
> wijziging ontstaat er
> voor dat blok geen blok-update.
> Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en 
> dat deze alle BAG
> data uit dat blok bevat. BAG is in het begin immers nog niet op dat 
> blok in OSM gebracht.
> Deze blok-update wordt de 'init-update' genoemd. Iedere volgende 
> blok-update bevat alleen
> de wijzigingen uit een betreffende maand. Op een zeker moment kunnen 
> er dus voor ieder
> blok verschillende hoeveelheden blok-updates aanwezig zijn.
>
> Een "Delta Uitlevering BAG" (DUB) van een blok heeft de volgende 
> kenmerken:
> - De uitlevering wordt gemaakt op het moment van aanvraag
> - De uitlevering bevat de geaggregeerde BAG gegevens vanaf "Laatste 
> Update Datum" (LUD)
> (Voor de eerste uitlevering van ieder blok (init) is deze datum bv 
> 01-01-2011)
> - Bestand heeft een unieke code.
> - Bestand is in .OSM formaat zodat deze direct in JOSM geladen kan 
> worden.
Delta's (was-wordt) lijken leuk, maar zijn dat absoluut niet. Het werkt 
alleen voor nieuwe toevoegingen, die niet in OSM zitten.
Met updates en verwijderingen moet gebruik worden gemaakt van de 
bestaande way-/relation-ID's in OSM én het juiste versienummer. Daarbij 
komt nog dat je in een OSM bestand (ik neem aan dat je dan de JOSM smaak 
bedoelt) niet ziet wat er verwijderd is.

Ook houdt deze benadering geen rekening met wijzigingen die gebruikers 
aan bestaande data hebben toegevoegd. Als het ID en versienummer zou 
kloppen, dan moeten wijzigingen alle gebruikers-tags toevoegen. Dit gaat 
in theorie alleen werken als het proces dat de DUB-bestanden maakt 
gebruik maakt van up-to-date OSM data én als de gebruiker zsm de 
wijzigingen gaat posten. Dit neemt nog steeds niet het bezwaar weg dat 
dit semi-geautomatiseerd is. Aangezien je werkzaam bent in de ICT, weet 
je ook dat software niet altijd 100% klopt ;) Changesets kúnnen gerevert 
worden, maar dat moet zeker geen gewoonte worden!
>
> Activiteiten DUB site:
> De DUB site is een site waarin de ingelogde OSM gebruiker op de kaart 
> van OSM 1 blok kan
> aangeven en vervolgens daarvan een DUB kan bestellen. De DUB site 
> aggregeert alle
> blok-updates vanaf de LUD. De gebruikersnaam, de aanvraag datum en een 
> unieke code worden
> in een database opgeslagen. De site controleert automatisch of de 
> unieke code van een
> uitstaande DUB voorkomt in de omschrijving van de changesets. Komt 
> deze voor dan wordt
> het record van de DUB verwijderd en krijgt het blok een LUD die gelijk 
> is aan de uitgifte
> datum van de net verwijderde DUB.
> De geldigheid van een uitlevering kan gesteld worden op 1 maand. Heeft 
> de aanvrager zijn
> aanvraag niet omgezet in een valide changeset, dan kan via een mail 
> het systeem hem
> hiertoe aansporen dit alsnog te doen. (Eventueel kan voor voorkomende 
> gevallen een
> mogelijkheid geschapen worden om de DUB zonder changeset vrij te geven 
> zonder de
> aanpassingen door te hebben gevoerd in OSM. Het DUB record wordt wel 
> verwijderd, maar de
> LUD niet aangepast.
> Wordt een aanvraag gedaan voor een blok waarvan reeds een DUB 
> uitstaat, dan kan deze
> geweigerd worden en verwezen worden naar de betrokken gebruiker. 
> Onderling kan een
> oplossing voor dit oponthoud gevonden worden. (Vrijgeven van het blok?)
Ik vind dit teveel klinken als een technische oplossing (unieke ID's, 
locking, geldigheidsperiodes), i.p.v. een oplossing die gaat werken. De 
DUB-site is een veel te "bazig" systeem. Ook in dit verhaal blijf ik 
missen hoe je met gewijzigde en verwijderde features om denkt te gaan.
>
> De gebruiker vergelijkt na ontvangst de DUB.OSM met de huidige OSM 
> gegevens en brengt op
> deze laatste de wijzigingen aan. Is de gebruiker klaar dan upload hij 
> de gegevens en
> vernoemd in de omschrijving van de changeset de unieke code uit de DUB.
Alternatief voor de DUB-site: de gebruiker selecteert een 
(postcode)gebied, stelt de datum in wanneer voor het betreffende gebied 
de laatste import heeft plaatsgevonden (= begindatum) en stelt eventueel 
de einddatum in (default laatste update). Hij krijgt 3 OSM-bestanden, te 
weten "nieuw", "gewijzigd" en "verwijderd". Het Nieuw-bestand kan, na 
verificatie, zonder teveel problemen worden geïmporteerd. V.w.b. de 
overige bestanden gaat hij zelf de features vanuit OSM downloaden en in 
JOSM bijwerken aan de situatie op de einddatum, danwel verwijderen. Hoe 
hij dat doet (vervangen geometrie en tags overkopiëren, of overtrekken), 
mag hij zelf uitzoeken.

Idealiter zou de gebruiker op zijn fiets / in zijn auto moeten springen 
of de wijzigingen kloppen. Steeksproefsgewijs zou je dit wel mogen 
verwachten. Op deze manier blijft de lokale gebruiker "in control" en is 
hij erop aan te spreken als hij een potje maakt.

Het zou leuk zijn als ergens wordt bijgehouden wat de status van de bag 
import is. IMHO moet de actualiteitsdatum van de BAG-data minimaal uit 
de changeset blijken. De DUB-site zou wel zo gemaakt kunnen worden dat 
de gebruiker verplicht de changeset-ID moet gaan posten. Dan kan ook de 
begindatum automatisch worden bijgehouden en dat scheelt werk voor de 
gebruiker. Ook zou een registratiemechanisme toegevoegd kan worden, 
waarbij iemand op een postcodegebied kan inschrijven (hoeft niet per se 
1 persoon te zijn) en dan automatisch een mail ontvangt wanneer in 
"zijn" gebied(en) mutaties zijn gesignaleerd.

>
> Voordelen:
> - BAG data inclusief updates kunnen gecontroleerd in OSM worden 
> ingebracht.
> - Lokale gebruikers bepalen de update frequentie
> - Mappers worden optimaal geholpen in het beschikbaar krijgen van de 
> meest relevante BAG
> gegevens voor een geografisch blok.
> - Mappers hebben niet meer technisch kennis nodig dan JOSM 
> technieken/vaardigheden.
> - Er is een maximaal overzicht over de BAG status per geografisch blok.
Deze voordelen onderschrijf ik. Ze zijn ook van toepassing op mijn 
alternatief.
>
> Nadelen:
> - De initiële update is een arbeidsintensief werk. De updates zullen 
> relatief eenvoudig
> zijn.
> - Niet ieder blok in OSM zal voorzien zijn met OSM data.
Het laatste nadeel is veel minder erg als een meer logische grens wordt 
gebruikt, zoals postcodegebied.
>
> Ik hoop met het bovenstaande duidelijk te hebben gemaakt hoe ik een 
> mogelijkheid zie om
> de BAG data beschikbaar te stellen aan de mappers-crowd.
>
Groeten,

Frank