Kunnen we dan nu op basis van consensus besluiten “weg ermee!”?
Is er een tagging voor blijvende afstandspaaltjes langs een sportcircuit? Je ziet ze veel en ik vond het -toen ik nog hardliep- altijd prettig om ze te zien.
En kijk je dan tijdens het rennen steeds op je smartphone om ze op OSM te zien?
Nee, dan vertelt de navigatie mij in mijn oortje dat ik het x Km-punt nader.
Veel dingen op OSM (en op straat) zie ik weinig nut in, maar het staat er, verifieerbaar, dus als iemand het wil mappen…
Ik vind ook wel dat lcn_ref nodes zonder verdere aanduiding beter niet op de fietskaart zouden kunnen staan. Zelf zou ik in zo’n geval liever eerst met de makers van de toepassing overleggen alvorens het door te voeren. (Ja, door schade en schande wijzer geworden…)
Vanuit deze argumentatie kunnen we dan ook de hm-paaltjes langs alle wegen gaan taggen.
Ik zie nog steeds niet dat het een lcn_ref is.
Ik pleit er niet voor om het te doen, maar áls iemand paaltjes langs een sportcircuit wil taggen die er ook werkelijk staan, dan ga ik ook niet zeggen dat het niet mag.
Als je niet wil niet dat lcn_ref ervoor gebruikt wordt omdat dat tot misverstanden en onprettige rendering leidt, dan is het handig om er een aparte tagging voor te hebben.
Los van dit geval en of iemand het zo wil doen, zou het goed zijn dat toepassingen niet (meer) uit **n_ref konkluderen dat het als een knooppunt gerenderd moet worden. network:type=node_network zou daarvoor een vereiste zijn.
En degene die XXn_ref tags invoert voor iets anders dan knooppunten, kan zich best realiseren dat dat mogelijk tot ongewenste effekten leidt die beter vooraf uitgezocht en afgestemd kunnen worden. Dan zou je bv een invoerdatum kunnen afspreken die voor iedereen haalbaar is. De data user / renderer kan dan besluiten of en hoe de punten dan wél weergegeven moeten worden, mede afhankelijk van de XX in XXn_ref.
Dan is de tag highway=milestone (zie de wiki en de daar gelinkte discussiepagina over het plaatsen van de node op of naast de highway) de meest aangewezene en dus niet een *cn_ref
Dat was mijn vraag, bedankt!
Als de nummers Kms zijn dan gaan ze dus in distance=*
Er is wel een puntje: het gaat niet om 1 weg maar om een route van tig wegen. Je zou wel ergens moeten kunnen aangeven waar de distance betrekking op heeft. Op een snelweg krijgen de afstandspalen de ref van de weg, begrijp ik. Dan zou je hier de ref van de route moeten gebruiken, dus de route moet zelf een ref hebben die ergens aangegeven staat. Denk ik.
Nogmaals… een node is en punt en niet per definitie een knooppunt met keuze opties. Dat en knooppunt een punt is duidelijk maar niet iedere node is een knooppunt. M.i. is een lcn_ref een punt (node) die een referentie is binnen de lcn.
Als jij vindt dat een lcn_ref alleen voor KNOOPpunten gebruikt mag worden dan zou het je sieren als je de mappers die hier en hier bezig zijn geweest even vertelt dat ze het niet begrijpen. Ga jij dat doen?
Vindt jij ook dat een rcn_ref altijd een KNOOPpunt is? Zo ja dan is het wellicht goed dat je Peter Elderson even vertelt dat hij bezig is met needles tagging want alle rcn_ref in NL hebben inmiddels ook een networkt:type=node_network om aan te geven dat het een KNOOPpunt netwerk is. En daarnaast hebben ook alle rcn netwerken die knooppunt netwerken zijn deze tag gekregen.
En even voor de duidelijkheid. Ik vind het heel goed hoor dat Peter actie heeft ondernomen om KNOOP punt netwerken en hun xxn_ref te onderscheiden van de andere.
En ik begrijp best dat we in NL snel aan knooppunt netwerken denk hoor maar er zijn elders ook andere netwerken. Toen we met de BTM begonnen dacht ik dat iedere rcn een knooppunt route was. Dat zie je nu nog steeds op die kaart want achter RCN staat tussen haakjes “knooppuntroute” maar in het buitenland denken ze daar heel anders over.
Wat is dit nu voor een suggestie? Dat is niet erg constructief Martin. Nu je weet wat er hier gemapt is kun je meedenken over HOE dat het best gemapt moet worden. Dat hoeft niet hoor maar voorstellen om het gewoon even te verwijderen is niet verstandig en het siert je niet.
Kijk… gelukkig een constructieve gedachte. Daar komen we verder mee dan allen maar opmerkingen dat we het helemaal niet moeten mappen of dat het fout gemapt is.
Toen er kritiek kwam op lcn_ref heb ik in post 94 aangegeven dat als lcn_ref echt heel onlogisch is dat ik daarvoor best ref wilde gebruiken. Daarop kwam de terechte kritiek van multimodaal in post nr 95. En in post 101 legt hij duidelijk uit dat niet iedere xxn_ref per definitie een knooppunt hoeft te zijn. Dit sterkte mij in de gedachte dat een lcn_ref eigenlijk een prima tag is. Het is immers een referentie in een lcn. Daarnaast hebben we dus de tag network:type=node_network om aan te geven dat het een echt knooppunt is. Als alle xxn_ref knooppunten zouden zijn dan zou de tag network:type=node_network overbodig zijn maar dat is ie niet.
En nogmaalst vwb de rendering. De oorzaak hiervan is het feit dat de ref meer dan 3 posities heeft. Die kan/wil men niet renderen. Dat men ergens een grens trekt is niet onlogisch want anders krijgen we straks een niet meer te lezen kaart. Kijk maar eens naar het plaatje in dit voorstel. Dat wordt er niet leesbaarder op.
En het is goed te realiseren dat er verschillend typen lcn_ref zijn. Dat zagen we o.a. aan het fietstrondje in York. Als we hier kijken naar de lcn_ref dan zien we om reden van meer dan 3 posities nergens letters of cijfers staan. En het merendeel van deze lcn_ref is overigens helemaal geen knooppunt/keuzepunt zoals wij die in NL kennen van bv de fiets/wandel knooppunt routes. Het zijn lcn_ref van het type information=guidepost. Zijn die dan onterecht gemapt als lcn_ref? (hier een overpass turbo om die lcn_ref op te halen). De km paaltjes in de mtb van sleenerzand zouden naast de lcn_ref ook bv information=distance (of verzin iets beters) kunnen krijgen om specifieker aan te duiden wat voor een lcn_ref het is.
We zijn nu 7 maanden en 168 posts verder na de vraag van Mika en nu weet hij nog steeds niet hoe hij die referenties van de MTB route moet/mag/kan invoeren. Mijn voorstel om ze te mappen als lcn_ref en die punten op te nemen in de relatie is vooralsnog het enige concrete wat we te bieden hebben al is ook daar niet iedereen het mee eens.
Ik (en naar mijn verwachting Mika ook) sta open voor betere opties. Laat maar weten.
Misschien een beetje laat, maar hoe gaan onze zuiderburen, de uitvinders van de knooppunten routes hiermee om ?
Of is het een idee om met de toegenomen digitalisering, de punten helemaal niet meer op de “basiskaart” weer te geven. Wie verplaatst zich nu nog zonder digitale gegevens van A naar B, of voor wie brengen we ze dan wel in beeld ?
Digitale gegevens
Uhm… wij zorgen toch juist voor de digitale gegevens? Ik gebruik de Knooppuntnet Planner https://knooppuntnet.nl/nl/map/hiking nu standaard voor plannen van (rond)wandelingen in een gebied.
Van A naar B?
(Knooppunt-)routes voer je niet in om van A naar B te komen, maar om tussen A en B een specifieke serie wegen af te leggen. Rekreatieve kriteria: % onverhard; afwisselende landschappen; punten die je nou eenmaal gezien moet hebben; totale afstand; parkeerplaats/OV; pauzegelegenheid bij horeca; hoogteverschillen. Let op: hier ontbreken: snelste route / kortste afstand, de typische routerkriteria.
En dat alles resulteert na planning in a. Een lijstje nummers; b. Een gpx voor stemnavigatie.
In post 127 kom je met 4 opties: https://forum.openstreetmap.org/viewtopic.php?pid=812297#p812297
Ik zie vooral de handen op elkaar gaan voor optie 3a en 3b desnoods als de paaltjes nodig zijn voor routering.
Waarom ga je dan toch anders mappen?
Daar heb je zeker een punt. Ik heb zelf een voorkeur voor methode 3 omdat dat consistent is met andere xxn_ref die voor zover ik weet op de weg gemapt zijn en niet ernaast. Gezien je opmerking neem ik aan dat dit is wat jij ook liever zou zien. Ik vind het geen probleem dat aan te passen al kost dat wel ff tijd vrees ik. Ik vind het ook best lastig een keuze te maken als de meningen zo uiteenlopen en het aantal meningen ook nog eens beperkt is. Als er niet te veel commentaar op komt zal ik het binnenkort aanpassen
Niet zomaar op de weg, maar op intersecties van routes, zodat de routes via dat punt aan elkaar gekoppeld zijn. Dat gebeurt omdat de intersecties in een consistent netwerkschema nodig zijn voor planning en aanmaken van een enkele keten van wegen: de geplande en te volgen route.
Vandaar mijn voorkeur: alleen als de punten niet voor routeren/plannen dienen, dan wegpunten nemen.
PS Verduidelijking voorkeur: Alleen wegpunten nemen als ze voor routering/plannen dienen.
Mijn plan is om al die ref te plaatsen op de weg. Het is inconsequent om van een route de ene wel op de weg en de andere naast de weg te plaatsen. Daar waar de ref een knooppunt van routes/ routeverkortingen is zal ik het exact op de intersectie doen. Hier een voorbeeld waar ik dan DTH31 op de intersectie van de MTB routes plaatsen. Dat is ook echt een keuze punt omdat je daar komend vanaf de blauwe route 2 opties hebt en komend vanaf de rode route ook 2 opties. Als MTB routes niet 1 richting zouden zijn dan waren het beide zelfs 3 opties. Niet ieder keuzepunt in MTB routes in NL zal een eigen ref hebben maar als ze die wel hebben dan kunnen we die ref op de intersectie mappen.
Groot voordeel is dat ze dan direct onderdeel zijn van de routerelatie, hoeven ze niet nog een keer apart toegevoegd te worden.
De punten in de MTB route Sleen zijn nu getagged als lcn_ref. Foutje? Je wilde ze toch als ref taggen?
https://www.openstreetmap.org/node/8277272667/history
Verder heb je nu alleen een ref aan een node hangen, zonder fysieke eigenschap. Dat is wel gebruikelijk bij een node netwerk, maar aangezien daarvan hier geen sprake is, snap ik je bedoeling niet.
Mijn quote stond direct onder dit stukje tekst en dat ging over lcn_ref.
Toegegeven… het zou nog duidelijker zijn geweest als ik ipv ref de tekst lcn_ref zou hebben gebruikt maar de actie was volgens mij wel duidelijk. lcn_ref verplaatsen van naast naar op de weg. Op de MTB route Sleen had ik de punten al getagd als lcn_ref maar naast de weg. O.a. nav jouw opmerking heb ik ze OP de weg getagd. In feite heb ik optie 3 gebruikt onderaan in deze post waar jij al eerder naar verwees.
Ik denk dat deze zin zonder de redenering ervóór niet duidelijk was!
Ik bedoelde:
- Als de genummerde punten voor routeren/plannen dienen, dan punten op de weg gebruiken.
- Als de genummerde punten niet voor routeren/plannen dienen, dan zijn het objecten op zich, dus naast de weg plaatsen.
Ik denk dat Peter het hier goed omschrijft: https://forum.openstreetmap.org/viewtopic.php?pid=812303#p812303
ref= voor emergency access points
lcn_ref= voor route variant (en niet voor hectometerpaaltjes)
Even voor het geval MTB Sleen, dit zijn kilometer bordjes. Noodzaak om te mappen ontbreekt m.i. en past zeker niet binnen de lijnen van de discussie over emergency access points.