<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body >Dat er naast codering ook een hoop documentatie nodig is klopt. Binnen dat domein wil ik mijn kennis en vaardigheden graag inzetten.<div><br></div><div>Ik zie een "testing and documenting " weekend wel zitten. Wellicht dat ik dáár wel een gelegenheid voor heb.</div><div>Dat onhandige zien dat wel tegen die tijd</div><div><br></div><div>Robert<br><br><font size="2">Met vriendelijke groeten,<br>Robert Elsenaar <br>(Verzonden vanaf Mobile)</font> </div><br><br><br>Frank Steggink <steggink@steggink.org> schreef:<br><br><br>Hoi Robert,<br><br>On 11-11-03 10:21 PM, robert@elsenaar.info wrote:<br>> Ik voel me allerminst opgejaagd wilt.<br>> Je 'alternatief' zie ik meer als een zinvolle aanvulling op mijn idee<br>> dan een discriminerend alternatief.<br>Mijn feedback is inderdaad bedoeld als aanvulling.<br>Ik kan me trouwens indenken dat je je niet opgejaagd voelt, aangezien<br>jacht op zondag(middag) (en tussen zonsondergang en -opgang) niet<br>toegestaan is.<br>><br>> Positieve punten:<br>> - Opdelen in anders soortige 'blokken' stuit bij mij op geen bezwaar,<br>> Ik gaf al aan dat die opdeling voor mijn idee niet relevant is. Voor<br>> de uiteindelijke uitwerking natuurlijk wel. en dat gaf je juist aan.<br>> - De een DUB opgedeeld wordt in drie bestanden (INS, CHG, DEL) is een<br>> uitstekende toevoeging. Leuk wellicht als je ook voor deze vormen kunt<br>> kiezen.<br>Uit de door jou gekozen benaming valt af te leiden dat je uit het 8.3<br>tijdperk stamt ;) Wat mij betreft is mijn alternatief geen keuze t.o.v.<br>jouw voorstel, vanwege de eerder genoemde redenen.<br>> - Hoe je de changeset laat corresponderen met de DUB's is mij gelijk.<br>> Mij leek een unieke ID, gegenereerd door de website zelf een beter<br>> idee. Dat dit uiteindelijk niet via de changeset, maar via een<br>> handmatige terugkoppeling, dat vind ik niet zo belangrijk. Het laatste<br>> zorgt er welvoor dat de gebruiker een verwerking kan uitvoeren door<br>> meer CS te up[loaden. Maar goed.<br>Een handmatige stap, tevens als controle, is een goede aanvulling in een<br>proces dat redelijk foutgevoelig is. Ook bij het handmatig verwerken van<br>mutaties kunnen fouten optreden.<br>Aan meerdere changesets per upload had ik nog niet eens gedacht. Dus<br>afvinkmogelijkheid erbij. Voor mutaties verwacht ik niet dat dit nodig<br>zal zijn, maar wel voor de initiële upload.<br>> - Je laat de basis van mijn idee volledig overeind: Ik vind het<br>> belangrijk als BAG data op eenvoudige manier beschikbaar komt voor de<br>> grote massa en in een vorm waarbij de verwerking niet meer<br>> vaardigheden vraagt dan bij het normale mappen voor gevorderden.<br>Het zinvol opdelen van dit werk is altijd een goed idee. Over de<br>invulling kan men twisten ;)<br>"Grote massa" vind ik hier overdreven, maar dat dit breder gedragen moet<br>worden dan door een driekoppig groen monster is een feit ;)<br>><br>> Ik hoop dat daadwerkelijk dat dit idee bij de groep wordt omarmt en<br>> gerealiseerd wordt. Helaas heb ik te weinig technische kennis om in<br>> die fase mijn bijdrage te leveren :-(<br>De uitwerking omvat meer dan het inrichten van de omgeving en het<br>schrijven van code. Testen en documentatie zijn minstens net zo<br>belangrijk, zeker om meer, maar tevens minder ervaren gebruikers erbij<br>te betrekken (alhoewel een bepaalde mate van vaardigheid met JOSM<br>vereist is). Dit proces is en blijft redelijk gecompliceerd. Het is niet<br>eenvoudiger te maken dan een bepaald niveau. Enige discipline blijft dus<br>nodig. Goede documentatie ondersteunt daarin. Ik wil jou dit werk niet<br>aansmeren, maar mensen ervan bewust maken dat het niet bij programmeren<br>alleen ophoudt.<br><br>Frank<br>><br>> groet<br>> Robert<br>><br>> Citeren Frank Steggink<steggink@steggink.org>:<br>><br>>> Hoi Robert,<br>>><br>>> Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is<br>>> geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild<br>>> aan.<br>>><br>>> On 11-11-03 08:59 PM, Robert Elsenaar wrote:<br>>>><br>>>> Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in<br>>>> gemeentegrenzen. Dit is niet relevant voor het idee.<br>>> Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige<br>>> onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer<br>>> ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje<br>>> Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in<br>>> gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten<br>>> voor een onderverdeling in 4-cijferige postcodegebieden. Dit is<br>>> behapbaar, omdat de spreiding in omvang veel minder divers is dan bij<br>>> gemeenten, laat staan een willekeurig grid. De postcodes zelf kunnen<br>>> weliswaar nog niet gebruikt worden, maar we kunnen de data wel zo<br>>> opknippen.<br>>><br>>>> Voor elk van deze 'blokken' kan de<br>>>> gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG<br>>>> data.<br>>>> Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag<br>>>> gedaan kan worden.<br>>>> - Het moeder systeem heeft alle updates van BAG opgesplitst in<br>>>> 'blok-updates'. Merk op<br>>>> dat voor ieder blok niet voor iedere maand een update is. Bij geen<br>>>> wijziging ontstaat er<br>>>> voor dat blok geen blok-update.<br>>>> Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft<br>>>> en dat deze alle BAG<br>>>> data uit dat blok bevat. BAG is in het begin immers nog niet op dat<br>>>> blok in OSM gebracht.<br>>>> Deze blok-update wordt de 'init-update' genoemd. Iedere volgende<br>>>> blok-update bevat alleen<br>>>> de wijzigingen uit een betreffende maand. Op een zeker moment<br>>>> kunnen er dus voor ieder<br>>>> blok verschillende hoeveelheden blok-updates aanwezig zijn.<br>>>><br>>>> Een "Delta Uitlevering BAG" (DUB) van een blok heeft de volgende<br>>>> kenmerken:<br>>>> - De uitlevering wordt gemaakt op het moment van aanvraag<br>>>> - De uitlevering bevat de geaggregeerde BAG gegevens vanaf "Laatste<br>>>> Update Datum" (LUD)<br>>>> (Voor de eerste uitlevering van ieder blok (init) is deze datum bv<br>>>> 01-01-2011)<br>>>> - Bestand heeft een unieke code.<br>>>> - Bestand is in .OSM formaat zodat deze direct in JOSM geladen kan<br>>>> worden.<br>>> Delta's (was-wordt) lijken leuk, maar zijn dat absoluut niet. Het werkt<br>>> alleen voor nieuwe toevoegingen, die niet in OSM zitten.<br>>> Met updates en verwijderingen moet gebruik worden gemaakt van de<br>>> bestaande way-/relation-ID's in OSM én het juiste versienummer.<br>>> Daarbij komt nog dat je in een OSM bestand (ik neem aan dat je dan<br>>> de JOSM smaak bedoelt) niet ziet wat er verwijderd is.<br>>><br>>> Ook houdt deze benadering geen rekening met wijzigingen die<br>>> gebruikers aan bestaande data hebben toegevoegd. Als het ID en<br>>> versienummer zou kloppen, dan moeten wijzigingen alle<br>>> gebruikers-tags toevoegen. Dit gaat in theorie alleen werken als het<br>>> proces dat de DUB-bestanden maakt gebruik maakt van up-to-date OSM<br>>> data én als de gebruiker zsm de wijzigingen gaat posten. Dit neemt<br>>> nog steeds niet het bezwaar weg dat dit semi-geautomatiseerd is.<br>>> Aangezien je werkzaam bent in de ICT, weet je ook dat software niet<br>>> altijd 100% klopt ;) Changesets kúnnen gerevert worden, maar dat<br>>> moet zeker geen gewoonte worden!<br>>>><br>>>> Activiteiten DUB site:<br>>>> De DUB site is een site waarin de ingelogde OSM gebruiker op de<br>>>> kaart van OSM 1 blok kan<br>>>> aangeven en vervolgens daarvan een DUB kan bestellen. De DUB site<br>>>> aggregeert alle<br>>>> blok-updates vanaf de LUD. De gebruikersnaam, de aanvraag datum en<br>>>> een unieke code worden<br>>>> in een database opgeslagen. De site controleert automatisch of de<br>>>> unieke code van een<br>>>> uitstaande DUB voorkomt in de omschrijving van de changesets. Komt<br>>>> deze voor dan wordt<br>>>> het record van de DUB verwijderd en krijgt het blok een LUD die<br>>>> gelijk is aan de uitgifte<br>>>> datum van de net verwijderde DUB.<br>>>> De geldigheid van een uitlevering kan gesteld worden op 1 maand.<br>>>> Heeft de aanvrager zijn<br>>>> aanvraag niet omgezet in een valide changeset, dan kan via een mail<br>>>> het systeem hem<br>>>> hiertoe aansporen dit alsnog te doen. (Eventueel kan voor<br>>>> voorkomende gevallen een<br>>>> mogelijkheid geschapen worden om de DUB zonder changeset vrij te<br>>>> geven zonder de<br>>>> aanpassingen door te hebben gevoerd in OSM. Het DUB record wordt<br>>>> wel verwijderd, maar de<br>>>> LUD niet aangepast.<br>>>> Wordt een aanvraag gedaan voor een blok waarvan reeds een DUB<br>>>> uitstaat, dan kan deze<br>>>> geweigerd worden en verwezen worden naar de betrokken gebruiker.<br>>>> Onderling kan een<br>>>> oplossing voor dit oponthoud gevonden worden. (Vrijgeven van het blok?)<br>>> Ik vind dit teveel klinken als een technische oplossing (unieke ID's,<br>>> locking, geldigheidsperiodes), i.p.v. een oplossing die gaat werken. De<br>>> DUB-site is een veel te "bazig" systeem. Ook in dit verhaal blijf ik<br>>> missen hoe je met gewijzigde en verwijderde features om denkt te gaan.<br>>>><br>>>> De gebruiker vergelijkt na ontvangst de DUB.OSM met de huidige OSM<br>>>> gegevens en brengt op<br>>>> deze laatste de wijzigingen aan. Is de gebruiker klaar dan upload<br>>>> hij de gegevens en<br>>>> vernoemd in de omschrijving van de changeset de unieke code uit de DUB.<br>>> Alternatief voor de DUB-site: de gebruiker selecteert een<br>>> (postcode)gebied, stelt de datum in wanneer voor het betreffende<br>>> gebied de laatste import heeft plaatsgevonden (= begindatum) en<br>>> stelt eventueel de einddatum in (default laatste update). Hij krijgt<br>>> 3 OSM-bestanden, te weten "nieuw", "gewijzigd" en "verwijderd". Het<br>>> Nieuw-bestand kan, na verificatie, zonder teveel problemen worden<br>>> geïmporteerd. V.w.b. de overige bestanden gaat hij zelf de features<br>>> vanuit OSM downloaden en in JOSM bijwerken aan de situatie op de<br>>> einddatum, danwel verwijderen. Hoe hij dat doet (vervangen geometrie<br>>> en tags overkopiëren, of overtrekken), mag hij zelf uitzoeken.<br>>><br>>> Idealiter zou de gebruiker op zijn fiets / in zijn auto moeten springen<br>>> of de wijzigingen kloppen. Steeksproefsgewijs zou je dit wel mogen<br>>> verwachten. Op deze manier blijft de lokale gebruiker "in control" en<br>>> is hij erop aan te spreken als hij een potje maakt.<br>>><br>>> Het zou leuk zijn als ergens wordt bijgehouden wat de status van de bag<br>>> import is. IMHO moet de actualiteitsdatum van de BAG-data minimaal uit<br>>> de changeset blijken. De DUB-site zou wel zo gemaakt kunnen worden dat<br>>> de gebruiker verplicht de changeset-ID moet gaan posten. Dan kan ook de<br>>> begindatum automatisch worden bijgehouden en dat scheelt werk voor de<br>>> gebruiker. Ook zou een registratiemechanisme toegevoegd kan worden,<br>>> waarbij iemand op een postcodegebied kan inschrijven (hoeft niet per se<br>>> 1 persoon te zijn) en dan automatisch een mail ontvangt wanneer in<br>>> "zijn" gebied(en) mutaties zijn gesignaleerd.<br>>><br>>>><br>>>> Voordelen:<br>>>> - BAG data inclusief updates kunnen gecontroleerd in OSM worden<br>>>> ingebracht.<br>>>> - Lokale gebruikers bepalen de update frequentie<br>>>> - Mappers worden optimaal geholpen in het beschikbaar krijgen van<br>>>> de meest relevante BAG<br>>>> gegevens voor een geografisch blok.<br>>>> - Mappers hebben niet meer technisch kennis nodig dan JOSM<br>>>> technieken/vaardigheden.<br>>>> - Er is een maximaal overzicht over de BAG status per geografisch blok.<br>>> Deze voordelen onderschrijf ik. Ze zijn ook van toepassing op mijn<br>>> alternatief.<br>>>><br>>>> Nadelen:<br>>>> - De initiële update is een arbeidsintensief werk. De updates<br>>>> zullen relatief eenvoudig<br>>>> zijn.<br>>>> - Niet ieder blok in OSM zal voorzien zijn met OSM data.<br>>> Het laatste nadeel is veel minder erg als een meer logische grens wordt<br>>> gebruikt, zoals postcodegebied.<br>>>><br>>>> Ik hoop met het bovenstaande duidelijk te hebben gemaakt hoe ik een<br>>>> mogelijkheid zie om<br>>>> de BAG data beschikbaar te stellen aan de mappers-crowd.<br>>>><br>>> Groeten,<br>>><br>>> Frank<br>>><br>>><br>>> _______________________________________________<br>>> Talk-nl mailing list<br>>> Talk-nl@openstreetmap.org<br>>> http://lists.openstreetmap.org/listinfo/talk-nl<br>><br>><br>><br><br><br>_______________________________________________<br>Talk-nl mailing list<br>Talk-nl@openstreetmap.org<br>http://lists.openstreetmap.org/listinfo/talk-nl<br><br></body>