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