[OSM-talk-nl] Fwd: Re: Semi automatisch BAG voorstel

Thu Nov 3 22:10:59 UTC 2011

Dat er naast codering ook een hoop documentatie nodig is klopt. Binnen dat domein wil ik mijn kennis en vaardigheden graag inzetten.

Ik zie een "testing and documenting " weekend wel zitten. Wellicht dat ik dáár wel een gelegenheid voor heb.
Dat onhandige zien dat wel tegen die tijd

Robert

Met vriendelijke groeten,
Robert Elsenaar 
(Verzonden vanaf Mobile)

Frank Steggink <steggink at steggink.org> schreef:

Hoi Robert,

On 11-11-03 10:21 PM, robert at elsenaar.info 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<steggink at steggink.org>:
>
>>  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
>>  Talk-nl at openstreetmap.org
>>  http://lists.openstreetmap.org/listinfo/talk-nl
>
>
>

_______________________________________________
Talk-nl mailing list
Talk-nl at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20111103/4d6f4a3a/attachment.htm>