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.
Zo had ik het ook begrepen hoor Peter gezien je eerdere reactie maar het leek mij niet netjes om in een quote van een ander aanpassingen te maken. Dat ik geen voorstander ben om de lcn_ref wel en de andere niet op de weg te plaatsen was al eerder opgemerkt.
Het staat je vrij om zaken die je niet noodzakelijk vind ook niet te mappen. In de discussie over de emergency access points ging het om de punten die zowel lcn_ref als emergency access points zijn. De vraag was waar we dan de lcn_ref moesten plaatsen. Op of naast de weg. Jij gaf aan dat de meesten een voorkeur hadden voor op de weg en daar was ik het wel mee eens. Vandaar dat ik ze verplaatst heb van naast naar op de weg.
Ik (en ook anderen) gaven er de voorkeur aan om helemaal geen lcn_ref moet gebruiken, maar alleen ref.
Optie 3a
Waarom plaats je lcn_ref als je eerst zegt ref te gaan gebruiken?
Optie 3a gaat niet over referenties van een lcn maar over de noodpaaltjes. In deze post waarin ik de opties noem is het onderwerp de combinatie van een referentie van een lcn en een emergency_access_point. De lcn_ref is een punt getagd met lcn_ref= * en het noodpaaltje is een punt getagd met highway=emergency_access_point SAMEN met ref=*.
Deze 2 elementen kun je op 1 node in osm opnemen. Dat kan met optie 1 (op de weg) en optie 2 (naast de weg). Je kunt ze ook als 2 losse nodes opnemen. Dat heb ik uitgedrukt met 3a voor de highway=emergeny_access_point samen met ref=* en met 3b voor de lcn_ref=*
Dus 3a voor zo’n noodpaaltje en 3b voor de lcn_ref.
Voor de MTB route van Den Treek Henschoten heb ik dat zo ook doorgevoerd.
Hier de lcn_ref DTH31 (3b op de weg)
En hier een voorbeeld van noodpaaltje DTH31 (3a naast de weg)
Met de context van hierboven verwijs ik graag naar mijn reactie in dit draadje waarin ik al gereageerd heb op deze vraag in de hoop dat het nu wat duidelijker is.
Nee, ik haak af. Net zoals Mika en vele anderen al gedaan hebben.
Ik vind het jammer dat je zo reageert omdat ik niet weet wat ik hier mee moet. Het klinkt alsof je flink in mij teleurgesteld bent maar waar dat dan in zit is mij niet helder. Is het dat je vindt dat ik een redeneerfout maak of de manier waarop ik e.e.a. verwoord? Dat is gissen voor mij. Ik kan je vertellen dat ik oprecht probeer om er een logisch geheel van te maken rekening houdend met anderen. Mocht je feedback voor mij hebben dan hou ik me aanbevolen. Wellicht is dat het best via een PM.
H’m…
Misschien de startveronderstelling dat de nummers op de MTB-routerpaaltjes er zouden kunnen zijn voor de routering en 112-meldingen.
Daar is uitgebreid over gediscussieerd en tot de conclusie gekomen dat het zeker geen lcn-relatie-routepunt was.
Dan wederom terugkomen met een lcn_ref voorstel roept wellicht wat gevoelens van onmacht op en de vraag of er redelijkerwijs naar argumenten geluisterd wordt.
Dat dan deelnemers met de beste bedoelingen de discussie niet meer voortzetten kan ik me voorstellen.
Beschouw het vooral niet persoonlijk op de man gericht, maar een om-en-om plaatsing in het topic van divergerende meningen eindigt niet tot een compromis. Iemand zal uiteindelijk water bij de wijn moeten doen; herhalen van zetten doet mensen afhaken of erger.
Just my thoughts…
Martin
Dank Martin voor je constructieve reactie.
Ja dat hielp niet echt mee maar ik moet zeggen dat ik het wel begrijpelijk vind dat het zo gelopen is. Bij mij (en ik vermoed aan aantal anderen ook) begon het later pas te dagen dat zolang er geen “bel 112” o.i.d. bij staat het wellicht helemaal geen emergency_access_point is.
Ik denk dat je gelijk hebt dat de meeste weerstand zit in het taggen van de lcn_ref. De discussie over de paaltjes waar de “bel 112” op staat is denk ik een veel minder heikel punt. Daarvan was de consensus ze naast de weg te plaatsen met de tags highway=emergency_access_point samen met ref=*.
Voor de paaltjes met nummering die bij een MTB route horen maar zonder “bel 112” is het m.i. zaak om tot een goede tagging te komen. Dat was het uitgangspunt van de start van het draadje. Of die paaltjes gebruikt worden voor de meldkamer of helpen bij routering is m.i. niet erg relevant. Iemand wil ze in OSM opnemen en dat mag. De vraag is dan alleen nog hoe. Dat er een verband is met de MTB route begrijpt denk ik ook wel iedereen. Ik neem ze dan ook op in de relatie van de lcn.
Als je bedoelt dat het zeker geen lcn_ref is dan deel ik deze conclusie niet. De weerstand tegen lcn_ref zit/zat em inderdaad in de veronderstelling bij een aantal dat lcn_ref alleen gebruikt mag worden bij echte knooppunten. Zowel ik , Multimodaal als Peter Elderson hebben aangegeven dat dit een begrijpelijke maar verkeerde veronderstelling is, zelfs met een aantal voorbeelden in OSM. Daarop kwam geen reactie in de trend van “dat zien jullie verkeerd” . Vervolgens ontstond de vraag of deze lcn_ref dan op of naast de weg geplaatst zou moeten worden. De meeste wilden dat op de weg en dat heb ik bij een aantal routes dan ook aangepast.
Ik heb ook een aantal keren gevraagd om een beter voorstel maar daarop kwam geen reactie afgezien van de wens van Peter Elderson om de lcn_ref de ene keer op en de andere keer naast de weg te plaatsen.
Ik sta nog steeds open voor andere/betere voorstellen maar afgezien van de suggestie ze maar helemaal niet te mappen zijn die er niet gekomen. Uiteraard mag een ieder vinden dat deze niet gemapt hoeven te worden maar niemand kan verbieden dat deze toch gemapt worden. De vraag blijft hoe.
Sorry dat ik hier wellicht weer te veel aan het herhalen ben maar zonder op de inhoud in te gaan vrees ik dat we niet verder komen.
Nee, dat klopt niet. Ik zou ze zelf uitsluitend mappen als ze nodig zijn voor het routeren, en in dat geval als wegpunten, intersecties waar je een keuze moet maken. En dat zou ik dan op de weg willen zien, doordat de bordjes aanwijzen naar welk punt je gaat als je het pijltje volgt.
Voor kilometerpaaltjes, of volgnummertjes waar je vanzelf langskomt als je een keuzevrije route volgt, zie ik zelf bij de huidige stand van de toepassingen geen meerwaarde om te mappen. Maar als iemand anders dat wel ziet, dan is het wel OSM dat-ie het mag mappen. Tenslotte zijn het verifieerbare objecten.
Als je dan de objecten zelf mapt, dan ook op de exacte plaats waar ze zich bevinden.
Ik vind dan wel dat er een objecttype op zou moeten, een tag die een object aangeeft. Een node met alleen een of ander refnummer is vreemd. (Dat geldt natuurlijk evengoed voor knooppuntpaaltjes, maar die boot is allang weggezeild: daar is gekozen om voor het routeerbare netwerk logische intersecties te gebruiken die zelf helemaal geen object zijn).
En áls er dan een objecttype is, dan kun je volstaan met de ref tag. Bijvoorbeeld marker=post, ref=10. Oftewel, dit is een paaltje met nummer 10 erop.
Maar, stel dat je besluit toch lcn_ref te gebruiken, dan denk ik wel dat je rekening moet houden met hoe dat in het verleden gebruikt is. Dan moet je MI bouwers van toepassingen de gelegenheid geven om te kijken wat het gaat betekenen, en eventueel hun filters of stijlen aan te passen.
Dus eerst dokumenteren, gevolgen inventariseren, wat ruimer aankondigen, feedback verwerken, en werken met een ingangsdatum. Een proeflokatie mag wel, vind ik, want velen hebben een voorbeeld nodig om te snappen waar het over gaat.
Dat is niet erg leuk werk, maar het zorgt wel voor bekendheid en draagvlak.
Je hebt gelijk Peter. Sorry. Bottomline is dat je niet altijd maar soms wel een lcn_ref zou mappen en dan op de weg/intersectie waar je een keuze kunt maken. Lastig punt is dan nog wel wat de definitie is van “nodig zijn voor routeren”. Ik vrees dat hier vele interpretaties van kunnen zijn en dan helpt een goede definitie.
Ik had ze initieel ook gemapt op de exacte locatie als lcn_ref maar nadat bleek dat de meesten ze op de weg wilden heb ik ze verplaatst. Wat jij aangeeft lijkt op wat er in Lubeck is gebeurd met de guidepost naast de weg. Ook gemapt als lcn_ref maar aanvullend met o.a. information=guidepost. Het toevoegen van de tag marker=post spreekt mij wel aan want maakt het duidelijker. Dit analoog aan de information=guidepost in Lubeck.
Ik snap je voorstel en had waarschijnlijk ook best gekund maar wijkt wel af van bv hoe het nu in Lubeck i is gemapt (als lcn_ref node naast de weg) en ook in York (als lcn_ref op de weg). Ik zie veel overeenkomsten met deze 2 situaties en de paaltjes in MTB routes. Of de verschillen groot genoeg zijn om een andere manier van taggen te introduceren daarover kunnen we van mening verschillen.
Ik ben het met je eens als het voor iets geheel nieuws is. Een lcn_ref dat niet een echt knooppunt is bestaat echter al heel lang. Die guideposts in Lubeck zijn er al een jaar of 6 en de route in York ook al een kleine 3 jaar. Het lijkt mij mosterd na de maaltijd als ik nu over deze manier van tagging e.e.a. zou gaan vastleggen/communiceren.
[edit: zin veranderd omdat het leek alsof het een quote was maar daar was geen sprake van]
Lubeck zijn administratieve wegwijzerpaalnummers. Niet voor een bepaalde route, gewoon alle fietswegwijzers. Typisch een voorbeeld van iets wat ik nooit zou mappen. Ik zou daar ook geen lcn_ref gebruikt hebben, maar ref. Op de OSM fietskaart ziet het er ook niet uit: https://www.openstreetmap.org/relation/27027#map=13/53.8638/10.6964&layers=C
York is wel goed vergelijkbaar. De genummerde punten zijn echt bedoeld als orientatiepunt voor fietsers van de Orbitalroute, waar ook de aparte wegwijzers voor die route staan. De wegwijzers verwijzen niet naar de twee aangrenzende nummers, maar geven de naam van het pad wat je daar volgt om bij het volgende punt te komen (tweezijdig).
Op de fietskaart ziet het er ook bruikbaar uit: https://www.openstreetmap.org/node/255883828#map=14/53.9596/-1.0890&layers=C
Ieder heeft zijn eigen definitie van “ziet er niet uit” maar de voornaamste reden is m.i. dat deze lcn_ref meer dan 3 posities zijn en dat wordt gerenderd met een leeg rondje. De MTB route van Sleen heeft dat probleem niet en wordt zo gerenderd. Los van de vraag of dit nu de juiste manier van taggen is ziet het er m.i. al wel beter uit.
Lubeck: als je een kaart van alle fietswegwijzers wil, dan moeten ze opvallen. Dat is leuk voor onderhoudsdiensten en zo. Kan je de korste route uitrekenen om alle palen te poetsen. Ik heb toegang tot het planningssysteem van een aannemer voor bepaalde wegwerkzaamheden, dat ziet er ongeveer zo uit. Maar voor niet-autistische fietsers is dit MI niet bruikbaar en zelfs hinderlijk want het overdekt wegdetails die je wel graag zou zien en ze staan overal. Als de nummers er ook nog in zouden staan zou het helemaal onbruikbaar worden.
Je zou misschien denk ik de gewone wegwijzerikonen iets steviger aan kunnen zetten zodat ze wat meer opvallen, maar geen kaartdetails verdringen. De nummers zijn daarvoor niet nodig, ze zijn al getagd als guideposts voor network=lcn. Dat maakt tevens dat het nummer -als je het toch zou willen registreren- gewoon als ref=* getagd kan worden.
Maar goed, als ze dat daar zo willen doen, soit. Ik zou er alleen geen voorbeeld aan willen nemen.