Hoi Robert,
On 11-11-03 10:21 PM, [email protected] wrote:
Ik voel me allerminst opgejaagd wilt.
Je 'alternatief' zie ik meer als een zinvolle aanvulling op mijn idee
dan een discriminerend alternatief.
Mijn feedback is inderdaad bedoeld als aanvulling.
Ik kan me trouwens indenken dat je je niet opgejaagd voelt, aangezien
jacht op zondag(middag) (en tussen zonsondergang en -opgang) niet
toegestaan is.
Positieve punten:
- Opdelen in anders soortige 'blokken' stuit bij mij op geen bezwaar,
Ik gaf al aan dat die opdeling voor mijn idee niet relevant is. Voor
de uiteindelijke uitwerking natuurlijk wel. en dat gaf je juist aan.
- De een DUB opgedeeld wordt in drie bestanden (INS, CHG, DEL) is een
uitstekende toevoeging. Leuk wellicht als je ook voor deze vormen kunt
kiezen.
Uit de door jou gekozen benaming valt af te leiden dat je uit het 8.3
tijdperk stamt ;) Wat mij betreft is mijn alternatief geen keuze t.o.v.
jouw voorstel, vanwege de eerder genoemde redenen.
- Hoe je de changeset laat corresponderen met de DUB's is mij gelijk.
Mij leek een unieke ID, gegenereerd door de website zelf een beter
idee. Dat dit uiteindelijk niet via de changeset, maar via een
handmatige terugkoppeling, dat vind ik niet zo belangrijk. Het laatste
zorgt er welvoor dat de gebruiker een verwerking kan uitvoeren door
meer CS te up[loaden. Maar goed.
Een handmatige stap, tevens als controle, is een goede aanvulling in een
proces dat redelijk foutgevoelig is. Ook bij het handmatig verwerken van
mutaties kunnen fouten optreden.
Aan meerdere changesets per upload had ik nog niet eens gedacht. Dus
afvinkmogelijkheid erbij. Voor mutaties verwacht ik niet dat dit nodig
zal zijn, maar wel voor de initiële upload.
- Je laat de basis van mijn idee volledig overeind: Ik vind het
belangrijk als BAG data op eenvoudige manier beschikbaar komt voor de
grote massa en in een vorm waarbij de verwerking niet meer
vaardigheden vraagt dan bij het normale mappen voor gevorderden.
Het zinvol opdelen van dit werk is altijd een goed idee. Over de
invulling kan men twisten ;)
"Grote massa" vind ik hier overdreven, maar dat dit breder gedragen moet
worden dan door een driekoppig groen monster is een feit ;)
Ik hoop dat daadwerkelijk dat dit idee bij de groep wordt omarmt en
gerealiseerd wordt. Helaas heb ik te weinig technische kennis om in
die fase mijn bijdrage te leveren :-(
De uitwerking omvat meer dan het inrichten van de omgeving en het
schrijven van code. Testen en documentatie zijn minstens net zo
belangrijk, zeker om meer, maar tevens minder ervaren gebruikers erbij
te betrekken (alhoewel een bepaalde mate van vaardigheid met JOSM
vereist is). Dit proces is en blijft redelijk gecompliceerd. Het is niet
eenvoudiger te maken dan een bepaald niveau. Enige discipline blijft dus
nodig. Goede documentatie ondersteunt daarin. Ik wil jou dit werk niet
aansmeren, maar mensen ervan bewust maken dat het niet bij programmeren
alleen ophoudt.
Frank
groet
Robert
Citeren Frank Steggink<[email protected]>:
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
_______________________________________________
Talk-nl mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-nl
