Voorloopnullen bij knooppuntennetwerken

Bij de vernieuwing van het netwerk Veluwe wordt standaard een voorloopnul gebruikt.

Dick, ik zie dat je nu ook bezig bent met het frn Veluwe, ik krijg continu conflicten in Josm en weet niet hoe daarmee om te gaan. Ik laat het toevoegen van de nieuwe routes aan dat netwerk dus maar even zitten.

Ik kreeg ook conflicten. Ik ben nu weg.
Morgenochtend doe ik zowiezo een foutenrondje, dan kan ik ze meenemen.
Ik denk dat je de netwerkrelatie een keer moet vernieuwen voor je routes en/of knooppunten toevoegt en direct daarna saven.
Ik heb nog een hele boel werk, dus ja, ik zal nog wel even bezig zijn de komende dagen.

Nijkerk is nu up to date, alleen ontbraken er onderweg nog wat borden. Misschien nog niet af of vergeten te plaatsen?

Mijn voorstel is, om over de Veluwe hier verder te praten.

Ik was vergeten te vermelden dat het om knooppunt 09 ging :wink: helaas valt de voorloopnul op de BTM weg:
http://mijndev.openstreetmap.nl/~ligfietser/fiets/?map=route&zoom=19&lat=52.23248&lon=5.47899&layers=B000000FFTFFFFFFFFFFFF

Ik heb dit met belangstelling gelezen maar mijn vraag is:
Wat is nu de afspraak. Wel of geen voorloopnul?

Dit is ook fout. In 2011 heb ik van diverse knooppunten in Groningen foto’s gemaakt. Daar is echt sprake van 1 t/m 9 en niet 01 t/m 09. Op de OSM staat 01 t/m 09. OSM is niet meer mappen wat de mapper ziet. Het is nu mappen wat het door de mapper ontwikkelde computerprogramma aangeeft.

Afgelopen week heb ik een andere dagelijkse fietsroute gefietst. Volgens de OFM lag de relatie tussen twee knooppunten op mijn route op de tertiaire weg en niet op het fietspad. Een mapper had een deel van de weg afgesloten voor fietsers door bicycle=no te taggen. Het fietspad is 5 jaar oud en vijf jaar lang heeft de relatie daar verkeerd gelegen. Dit is geen enkele armchair mapper opgevallen, want zijn/haar computerprogramma geeft dat niet aan. Twee dagen geleden had ik de tag bicycle=no verwijderd zodat de relatie over de tertiaire weg doorliep. Dat was niet geheel correct en gisteren heb ik de relatie over het fietspad laten lopen zoals het hoort. Mijn werk is om 14.44 uur opgeslagen. Maar het computerprogramma van een armchair mapper sloeg waarschijnlijk op tilt. Om 17.08 uur is er iemand bezig geweest en het knooppunt verplaatst wegens SORTEERPROBLEMEN.

Sorteren is het
• indelen in groepen
• eventueel rangschikken van groepen
• volgens een vooraf bepaald criterium

https://nl.wikipedia.org/wiki/Sorteren

Het knooppunt ligt nu gunstiger op de kaart. Het maken van een route in Mapsource of Basecamp gaat nu eenvoudiger. Vijf jaar lang valt het probleem niet op en als een armchair mapper aangeeft dat het knooppunt nu handiger ligt zodat het beter routeert, dan begrijp ik dat, maar sorteerproblemen …

Er is wel degelijk begrip op te brengen voor deze sortering.

Maar voordat me in deze discussie meng, wil ik graag laten weten dat we in Nederland blij moeten zijn met een detaillering waar menig commerciële kaart jaloers op is.

Dit wordt door vrijwilligers gerealiseerd, op consensus voorwaarden. Het wordt anders dat er bronnen gebruikt worden waar rechten op zitten. Hiermee wil ik zeggen dat er (in het verleden) best veel over gesproken is dat op relatie niveau het (bijna) noodzakelijk is om een structuur aan te brengen. Een sortering is een van deze voorwaarden om een goede relatie te maken. Het gaat in dit geval namelijk niet om de individuele node met een bepaalde tag die “1” of “01” als waarde heeft.
Persoonlijk ga ik er vanuit dat dit dan consensus heeft gevormd.
Natuurlijk mogen er vragen over gesteld worden. Maar om persoonlijk te worden lijkt me wat ver gaan.
Hopelijk heb ik een argument gegeven om begrip op te brengen.

Laten we blij zijn dat (zoals jij het zegt) van dit soort arm chair mappers zijn die veel werk steken in het onderhouden van deze relaties. Het gevaar dat iemand in het nauw gedreven zou worden en er uiteindelijk mee stopt is zeer ernstig. Tevens zul je dan zien dat de waardevolle OSM data (kaart) in rap tempo achteruit gaat.

Het gaat uiteindelijk om het plezier dat iemand er in heeft, met de middelen die hiervoor beschikbaar zijn.

Laten we (in dit draadje) voorkomen dat het persoonlijk gaat worden, het begint hier namelijk behoorlijk te lijken dat er een soort mapping war gestart wordt.

Laten we elkaar respecteren.

Heel bewust heb ik geen namen genoemd. De armchair mapper die dit heeft gedaan, levert goed werk. Het knooppunt staat nu beter op de kaart dan zoals ik hem heb laten staan.

Maar het schrikt mensen zoals ik die uitsluitend mappen op basis van plaatselijke kennis enorm af. Ik heb niets tegen kwaliteitscontrole. De wijziging was nu een verbetering. Dat heb ik wel eens anders meegemaakt.

Laten we dan maar even stellen dat het ook geen arm chair mapper was, die dat gedaan heeft. Goed mijn bureaustoel heeft armleuningen, maar die gebruik ik niet veel.
De armchair mapper, die dat gedaan heeft, fietst de afgelopen de jaren zo ongeveer 12.000 km per jaar om wegen te bekijken, nieuwe wegen te tracken, foto’s te maken, etc. Ik sta dus wel degelijk met mijn poten in de klei. En ik heb dus een ervaring van hier tot Tokio als het gaat om mappen. Maart 2009 begonnen bij de Fietsersbond en sinds maart 2015 ook bij OSM. Mijn devies is “veldwerk rules!”

Ik weet dat jij met jouw attitude een bloedhekel hebt aan het overzicht van VMarc. Dat is in je posten wel duidelijk geworden.
Maar dankzij VMarc hebben we in OSM voor het fkp een kwaliteit kunnen bereiken, die klinkt als een klok.

Dan nog even het punt sorteerprobleem.
VMarc meldde gisteren dat een route een foute sortering had en daar heb ik naar gekeken.
Routes binnen OSM, niet alleen fkp, moeten altijd in de volgorde van de wegen worden gesorteerd. Er is een consensus dat de fkp routes gesorteerd worden van het laagste knooppunt naar het hoogste knooppunt.
Jij hebt aan de bewuste route een stukje toegevoegd over het knooppunt heen. Echter je werkt met Potlach en die tool heeft de makke, net als ID, dat het toevoegingen altijd achteraan de route toe voegt. En ja dat was nu net fout in dit geval. Hij had bovenaan de route moeten staan. Dus voor mij is dat een sorteerprobleem.

En ja het fkp ligt hier en daar nog op de weg ipv het fietspad. Als ik dat tegen kom, dan pas ik het aan.
Maar als er geen problemen worden gemeld door VMarc, zie ik dat fkp ook niet en fysiek kom ik niet meer zo vaak in Drenthe. Dat is erg jammer, maar soms moet je dingen accepteren en slikken.

Even een paar opmerkingen.

Het programma, waar jij bedoeld, is zeer waarschijnlijk het overzicht van VMarc. Dat is voor iedereen bereikbaar en is dus niet van een armchair mapper. En dat slaat niet op tilt, maar meldt gewoon dat er fouten in het fkp zitten.
Wat voorloopnullen betreft, VMarc sloopt de voorloopnullen er gewoon weer af. Dus nee, VMarc dicteert niets.

En het verschilt gewoon per netwerkbeheerder of er voorloopnullen worden gebruikt.
De Veluwe hanteert sinds de laatste reorganisatie van dit jaar, consequent een voorloopnul

Als ik een fout maak en jij corrigeert die, is dat een prima zaak. Dat zou ik zelf ook hebben gedaan. De bedoeling is dat de kaart weergeeft zoals de situatie is en goed werkt. Als door een fout van mij de kaart niet goed werkt, valt me dat kwalijk te nemen.

Maar uit je commentaar was dat niet duidelijk, althans niet voor mij. Ik heb geprobeerd de relatie goed te verleggen. Als je als commentaar had gegeven dat er een fout inzit, is het duidelijk voor me. De les voor mij zou dan zijn: vraag iemand die deskundiger is dan ik, om de situatie aan te passen.

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.