Vroeger werd bij een aantal fietsknooppuntennetwerken standaard een voorloopnul gebruikt bij eencijferige knooppunten. Er was dus geen fietsknooppunt 1 maar fietsknooppunt 01. De laatste tijd zie ik dit echter nergens meer.
Toch wordt in Openstreetmap op veel plekken een voorloopnul gebruikt in de rwn_ref en rcn_ref tag. Fietsknooppunt 1 wordt dus ingevoerd als rcn_ref=01.
Volgens mij is dit fout. Daarom heb ik het ook verbeterd bij fiets- en wandelknooppunten die ik tegen ben gekomen en in het echt geen voorloopnul gebruikten. Echter is er hier een knooppunt weer terug veranderd. Het nummer van dit knooppunt is echt 9 en geen 09.
Is er nog een diepere bedoeling om voorloopnullen te gebruiken, zelfs als deze in het echt niet bestaan?
De meeste knooppuntnummers hebben 2 cijfers en daarom vind ik het prettig om ook de laagste nummers met 2 cijfers aan te geven. Dan heb je geen ongelijkheid. 3 cijferige nummers komen in Nederland niet veel voor, in Belgisch Limburg wel veel.
Verder is er een sorteringsissue, een ééncijferig nummer wordt vaak verkeerd gesorteerd, dus als je lijstjes uit OSM gegenereerd, heb je kans dat de nummers 2 tussen 19 en 20 staan.
Ik was deze zomer met de fiets in de duinen tussen Haarlem en Zandvoort en daar werden volgens mij nog steeds voorloopnullen gebruikt bij de fietsknooppunten.
‘Vroeger’ was dus duidelijk niet het goede woord. En het is natuurlijk logisch om een voorloopnul te gebruiken, als deze ook in het echt voorkomt.
Maar het gaat me vooral om de netwerken waarin geen voorloopnullen in het echt worden gebruikt (in ieder geval diverse fiets- en wandelnetwerken in Zuid-Holland en Zuidoost-Brabant). Ik vind het sorteer-argument vergelijkbaar met tagging for the renderer. Je voert de de nummers namelijk op een andere manier in dan in de werkelijkheid om een technisch probleem (sorteren van nummers als string i.p.v. integer) op te lossen.
Ik heb ruim 30 jaar in de automatisering gewerkt, van 1981 tot 2012.
Ik heb geleerd en ook ervaren dat je met nummers altijd zeer voorzichtig moet omgaan en ze zeker niet te snel als integers, floats, whatsoever moet zien, alleen dan als je er mee moet rekenen.
Voor mij zijn de knooppuntnummers dan ook strings.
Verder zijn er ook knooppuntnummers met een letter in de aanduiding. Zuid Limburg kent een 33 en een 33A
En ook voor de centrumroutes gebruiken we teksten in het knooppuntnummer zoals “30-33 - Centrum Liempde”
Dus nee, voor mij is een voorloopnul geen taggen voor de renderer, alleen een middel om duidelijkheid te krijgen.
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.
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
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.
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.
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.
helaas valt de voorloopnul op de BTM weg: