Ja, daar zit wat in.
Maar ik zie het zo, jij hebt de bulk zelf gedaan en net die paar kleine dingetjes, die met Potlach niet lukken, die heb ik even gedaan.
Dus naar mijn idee is de les voor jou, gewoon doorgaan. VMarc meldt wel als er dingen fout zijn. En dan pakt één van de mappers, die actief zijn met fkp dat wel op, ik ben niet de enige
Stel bijvoorbeeld dat jij buiten ziet dat een route gewijzigd is. Dan is het handig en goed als jij dat erin zet. Jij hebt dan het veldwerk gedaan, dus jij weet ook dat de route zo moet lopen. Dat dan de volgorde niet klopt of er nog iets anders fout zit, dat is dan maar even zo. Dat wordt gewoon hersteld.
Ik ben vaak niet erg van het communicatieve, dus elke keer commentaren in changesets zetten, is niet zo mijn ding. Dus repareer ik gewoon.
En voor mij is dit gewoon een sorteerfout.
Voor iemand die regelmatig mapt, is het een fluitje van een cent. Voor mij niet. Ik heb uitgebreid de relaties bekeken en dacht het foutloos te hebben gedaan. Als ik consequent fouten maak en het ligt aan mij, zal ik me moeten aanpassen. Of anders ermee stoppen.
Ook al ben je niet van het communicatieve, probeer wel duidelijk te zijn in je commentaar. Dat is leerzaam. Potlach schijnt minder geschikt te zijn voor relaties. Dan kan ik dat beter aan iemand anders overlaten. Zelf ben ik iemand die een ontbrekend pad op de OSM zet en dan is Potlach goed genoeg.
Een ontbrekend pad staat (standaard) niet in een relatie.
Een relatie is een verzameling nodes/ways/multipolygons die een cohesie vormen.
Als voorbeeld neem ik een willekeurige (wandelroute) relatie.
(maar er zijn bijvoorbeeld ook snelheidscamera’s die in een relatie kunnen staan)
Als je op de button “analyse on map” klikt zie je visueel hoe de route loopt.
In Knooppuntroutes werkt het systeem hetzelfde, maar de tool(VMarc) om fouten te ontdekken is een andere.
Zo zijn er veel hulpmiddelen beschikbaar die ons kunnen helpen OSM te verbeteren, op bijdragen die reeds geleverd zijn.
Hier zal het aangehaalde misverstand “arm chair mapper” vandaan kunnen komen.
Het is niet zo, dat mappers die gebruik maken van deze tools, armchairmappers zijn.
Helaas zijn er OSM editors die, zonder dat de mapper hier erg in heeft, die de data niet juist (kunnen) verwerken, waardoor problemen ontstaan in routerende afgeleide software. Een route is namelijk dynamisch, bijvoorbeeld als de weg onderbroken is, en geen verbinding heeft met de weg (omdat deze per ongeluk) een onderbreking heeft omdat de nodes niet meer vastgelijmd zitten, zal de routerings software een nieuwe route berekenen die wel doorgang heerft (met alle omwegen als gevolg)
In JOSM kun je deze fouten op de juiste manier corrigeren, die eerst met VMarc (of een andere tool) worden opgespoord.
Voorbeeld in JOSM:
De hoofdreden dat ik mensen verwijs naar JOSM, is puur gebaseerd op incompleetheid van andere editors.
Om terug te komen op de voorloopnullen: Ik zou de on the ground rule aanhouden. Dus als op het bordje staat ‘knooppunt 03’ dan wordt het rcn_ref=03 / rwn_ref=03 en als er staat ‘knooppunt 3’ dan wordt het rcn_ref=3 / rwn_ref=3. Geen voorloopnullen toegevoegd als die niet te zien zijn in het echt.
Het enige argument wat ik hiertegen heb gehoord is dat sommige sorteeralgoritmes dit verkeerd sorteren (9 na 10), maar dit is op te lossen door een natural sorting algoritme te gebruiken. In dat geval wordt 10 gewoon na 9 gesorteerd en is het niet nodig om 09 te schrijven.
zoveel hoofden, zoveel zinnen. (=iedereen heeft een eigen mening waarbij men moeilijk samen tot een oplossing kan komen)
Kunnen we concensus hierover bereiken of gaat iedereen volgens zijn eigen (goedbedoelde) mening knooppunten taggen en respecteren andere mappers dit door deze niet te gaan wijzigen?
Persoonlijk ben ik een groot voorstander van concensus maar wat ik soms wel een beetje mis is de vastlegging daarvan, of beter gezegd, de plek waar het is vastgelegd. Soms zou ik zweren dat ik ergens eens iets heb gelezen over hoe iets te taggen, maar kan ik niet meer terugvinden waar dat stond…
Nu kan dat natuurlijk ook iets zeggen over mijn zoekvaardigheid.
Een afspraak hierover lijkt me handig. Welke keuze er gemaakt wordt, maakt me niet zo veel uit, zolang er maar overeenstemming over is.
Mijn keuze zou zijn: geen voorloopnul op OSM wanneer die in het veld niet bestaat. (Wanneer de bordjes wel een voorloopnul tonen, dan natuurlijk ook op OSM met nul. Daarover lijkt me geen discussie.)
Is het misschien een goed idee om over twee weken “de stemmen te tellen” en te proberen tot een afspraak te komen. Dan hebben andere mappers nog twee weken om hun keuze en argumenten door te geven.
Wat mij betreft +1 voor bovenstaande optie (map het zoals het in het veld staat) op basis van de on the ground rule waarnaar A67-A67 al verwees.
En sowieso dank aan alle mappers die onvermoeibaar structureel de kwaliteit van de netwerken (en andere gegevens) in de gaten houden!
Ik probeer zo goed mogelijk te werken, maar toch slipt er soms iets tussendoor, JOSM-validatie pikt niet alles eruit.
Sommige online-validators doen een paar uur over verversen, waardoor je het pas de volgende dag ziet als je 's avonds mapt.
Vaak is onbedoelde schade blijkt dan al vroeg in de ochtend gerepareerd, voel me daar soms bijna schuldig over, dat ik mijn eigen rotzooi niet opruim…
Ik ben zelf sterk voor het mappen zoals het in het echt te zien is. Ik heb eigenlijk geen overtuigende reden gehoord om hiervan af te wijken.
Verkeersbord G7 ziet eruit als een plaatje van twee voetgangers. Er staat nergens G7 of G07 op het bord. Knooppunt 1 ziet eruit als het getal ‘1’ op een bordje in een bepaalde huisstijl.
Bij een knooppunt is er dus duidelijk sprake van een 1 of een 01. Bij een verkeersbord is dat verschil slechts iets dat je uit een bijlage van de wet zou kunnen halen.