Staan die dichter dan 100 meter van elkaar?
Nee effe zonder dollen. Zou je me in het kort uit kunnen leggen wat het nut is om de paaltjes op de kaart te zetten?
Stel ik val tijdens het MTB’en op m’n plaat (niet zo ondenkbaar, gisteren nog gebeurt 
), en stel, ik heb een dusdanige verwonding dat ik niet meer verder kan, maar nog wel 112 kan bellen. Hoe helpt het dan dat we de paaltjes gemapped hebben?
Als jij bv Osmand op de telefoon hebt staan dan kun je daar de MTB route op zien (mits gemapt) , de paaltjes met ref/nummers en je eigen locatie. Dan kun jij de meldkamer melden waar je bent. (tussen paaltje x en y, 100m bij paatje X vandaan). De locatie van de paaltjes zijn bekend bij de meldkamer en in hun GIS systeem ingevoerd. Dus kan de meldkamer de exacte locatie van jou doorgeven aan de ambulance/politie. En ook zelfs de locatie waar ze het best met de auto naar toe kunnen rijden om vervolgens te voet of met brancard/AED naar jou toe te gaan.
Mocht je een GPS hebben dan zijn al die paaltjes daar eenvoudig op te zetten door bv uit Overpass turbo dit resultaat als gpx te exporteren. Dan kun je ze dus ook op je GPS zien. Den Treek Henschoten biedt bv de MTB routes in .gpx formaat aan inclusief de paaltjesnummers. En last but not least, ook andere kaartmakers dan Osmand kunnen deze locaties in hun kaart inbakken.
Op de standaard OSM fietskaart zie je bij knooppunt fietsroutes de naam van de verbinding tussen 2 knooppunten. ( Hier de cijfers 51-95). Als zoiets ook in te bakken zou zijn in een kaart dan wordt het al helemaal makkelijk (en snel) om door te geven waar je bent tov de paaltjes. Dat was de reden waarom ik begon te denken om die routes op te knippen in aparte relaties tussen 2 paaltjes in. Of de paaltjes op de weg te plaatsen zodat het af te leiden is.
Je ziet de ref van de relatie. Je kan per sectie een routerelatie maken, en de secties in een andere relatie in de juiste volgorde daarin zetten. De dwarsverbinding kan je in de totaalrelatie de rol “connection” of “alternative” geven, conform de vastgestelde rollen voor recreatieve routes. (Waar de oorspronkelijke “aanstichter” trouwens zelf nog niks mee gedaan heeft…)
Je kunt ook meerdere totaalrouterelaties maken voor verschillende rondjes (bijvoorbeeld als ze aparte namen hebben zoals “De korte lus” en “De lange lus”.)
Of rondje A en rondje B en rondje B met allebei een “connection”.
Om de paaltjes op de kaart te zien kan je ze inderdaad invoeren en taggen als knooppunten op de route, of als POIs ernaast zetten op de echte plek waar ze staan. Beide zijn renderbaar. Omdat knooppunten al renderen is dat het handigst, maar het heeft wel een beetje een luchtje van taggen voor de renderer. Aan de andere kant, knooppunten met twee routes, oftewel genummerde punten langs de weg, zijn bij knooppuntnetwerken heel normaal, in dit geval zijn het er alleen wat veel.
Kun je dan niet veel makkelijker in Osmand je huidige locatie delen (in lat & lon) met de meldkamer?
Edit: typo
Ben jij dat, Sheldon Cooper? 
Voor gewone mensen: https://play.google.com/store/apps/details?id=com.what3words.android&hl=nl&gl=US
Fietsknooppunten worden getagd als rcn_ref en dat zijn het zeker niet. Wel een referentie in een netwerk maar niet een knooppunt in de zin van een keuzepunt (op een paar na). Je zet met wel aan het denken want de meeste (zo niet alle) MTB routes zijn LCN. Waarom taggen we die paaltjes dan niet als lcn_ref ipv gewoon ref? Momenteel wordt in NL de lcn_ref niet gebruikt maar dat is geen reden het niet te doen. Mijn voorstel is dus om die ref om te zetten naar een lcn_ref. We lopen dan de kans dat de referentie door kaartenmakers weer niet gerenderd worden maar we taggen niet voor de renderer 
De highway=emergency_access_point worden in Osmand wel getoond maar het zou kunnen dat we dan de nummers niet te zien krijgen. Maar misschien ook wel. Geen idee.
Goeie vraag. Zou handig zijn als dat zou kunnen maar hoe stel je je dat voor? Via Whatsapp naar 112 doorsturen?
Als ik hier kijk zie ik die optie er niet bijstaan. Ook in de daar genoemde infografic mis ik die optie. Maar ik zie daar wel een 112 app staan. Wellicht is dat het ei van Columbus?
Waarom zou dat niet kunnen? Je belt 112, zet je telefoon op handsfree, start osmand op, klik op je locatie en lat/lon komt voor je neus te staan.
Maarre hoe wilde jij doorgeven tussen welke paaltjes je ligt met, zeg, een gebroken bekken?
Staat net onder de optie met paalnumemrs MTB 
Ik zie alleen tolkcontact staan. Bedoel je die?
Je bedoelt dat je in Osmand je lat/lon opzoekt en die dan in het gesprek met de centralist doorgeeft. Ja… misschien best mogelijk. Geen idee
Als ik mijn telefoon/GPS nog kan bedienen kan ik zien dat ik tussen paaltje 8 en 9 lig. In het gesprek met de centralist geeft ik die nummers door. Hij ziet die in zijn GIS systeem en stuurt de hulpdiensten. En als ik verga van de pijn dan kan hopelijk een ander dit zelfde doen.
Nee… op de infografic zie ik rechts de 112 app die in ontwikkeling is.
Sinds de laatste december update van Osmand wordt de fietskaart overspoeld door emergency access points.
Komt denk ik door de tag lcn_ref 
Heeft niets met knooppunten te maken die paaltjes, ref volstaat m.i. En mocht Osmand dat dan niet renderen, dan kan je via github een verzoek indienen.
Ook de cyclemap is nu vervuild met emergency access points:
https://www.openstreetmap.org/#map=13/52.0888/5.3675&layers=C
Haal ze maar weer van de route relaties af Peewee, zo schiet je je doel voorbij.
Als de huidige rendering niet in de smaak valt, dan kan je een verzoek tot aanpassing indienen 
Ik vind het erg goed dat deze paaltjes met hun nummers zijn ingevoerd (dank daarvoor!).
Had gewild dat ze al in OSM stonden toen paar jaar geleden mijn gewonde fietsmaatje door de reddingsbrigade moest worden opgehaald, had de communicatie makkelijker gemaakt…
Vind het ook erg goed dat ze in OSM onlosmakelijk verbonden zijn met de routes. Dat is niet alleen heel praktisch, maar het zijn immers geen paaltjes die zomaar “toevallig” langs de route staan, maar de route wordt bepaald door deze (+ de ongenummerde) paaltjes; zonder paaltje geen route en zonder route heeft dit paaltje minder betekenis.
De nummers op de paaltjes worden voor veel meer doeleinden gebruikt dan alleen voor hulpdiensten, ze worden (ik denk veel vaker) gebruikt voor communicatie tussen fietsers om aan te geven waar ze zijn / waren / elkaar ontmoeten en door de routebeheerders om aan gebruikers aan te geven op welk stuk van de route een omleiding of obstakel etc is (of waar spullen gevonden zijn). En omdat ze opeenvolgend genummerd zijn helpt het ook in de oriëntatie in hoever je al in zo’n slingerronde bent.
Ik ben daarom persoonlijk voor een neutrale term die wel aangeeft dat het paaltje aan deze MTB-route is gerelateerd (en niet bijvoorbeeld aan een wandelroute die er ook vlak naast loopt).
De huidige situatie lijkt me op zich ok, de rendering verdient wel aandacht…
Dat lijkt mij persoonlijk een uitstekend voorstel
Ik zou de nodes op de wegen , gelet op het bovenstaande, persoonlijk taggen als
lcn_ref=*
expected_lcn_route_relations=2
(en 3 op paaltjes waar twee routes splitsen)
Knooppunten met slechts 2 aantakkende wegen komen ook in “echte” knooppuntnetten voor.
Dit is een randgeval, maar door dit steeds expliciet aan te geven kunnen datagebruikers die zich meer richten op splitsingen van routes alle nodes met expected_lcn_route_relations=2 negeren
Als je zou moeten kiezen, dan vind ik persoonlijk deze paaltjes eerder een element van de lcn-route dan een highway=emergency_access_point.
Het is een routepaaltje waar in dit geval weliswaar 112 op staat, maar ook zonder die tekst zou het dezelfde functie hebben en zou de meldkamer net zo goed een overzicht van deze paaltjes hebben. Kort gezegd: een routepaaltje dat daarnaast ook functioneert als een emergency_access_point. Het nummer van een ANWB-paddestoel zou dezelfde functie kunnen vervullen.
De voorbeelden op https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_access_point laten toch vooral “dedicated” emergency_access_points zien, en dat zijn deze paaltjes niet.
PS
Nog genoeg te mappen, zag gister bij wandeling in Den Treek toevallig dat de bordjes van de wandelroutes ook genummerd zijn (maar dan onopvallend aan de achterkant…)
https://www.mapillary.com/map/im/Ki2zWCxO2CxnbH4UvjTzSM
PPS
eigenlijk zou in plaats van
expected_lcn_route_relations=2
het in dit geval (zonder opsplitsen van de lcn-route in deeltjes tussen palen, lijkt me onnodig complex) zuiverder zijn om te zeggen
expected_lcn_route_ways=2
Voordeel van het op de nodes van de ways in de relatie taggen is ook dat je heel makkelijk de wegsegmenten kan opvragen die horen bij de melding “omleiding van Am6 tot Am14 tot mei”.
Omgekeerd kan ook: je kan in routebeschrijvingen dan ook automatisch opnemen van welk tot welk paalnummer het specifieke traject gaat.
Ik heb op die punten/nodes een ref= geplaatst om voor de highway=emergency_access_point aan te geven welke het is. Daarnaast heb ik ook een lcn_ref= geplaatst (met de zelfde waarde) om aan te geven welk lcn_ref het betreft.
In chat met Ligfietser lijkt het erop dat de combinatie van ref= en lcn_ref = wellicht de oorzaak van wat problemen is. Het kan zijn dat het niet gebruikelijk is om in een lcn de lcn_ref te gebruiken maar dat de ref= de voorkeur heeft. Ik dacht dat ref in een routerelatie meestal de drie letters van het type relatie als prefix hadden staan (bv lcn_ref) . Als in een lcn netwerk ref de voorkeur heeft boven lcn_ref wil dat dat best aanpassen. Geen probleem.
Voordeel van lcn_ref boven ref is dat duidelijk wordt gemaakt waar de betreffende waarde betrekking op heeft (net zoals er nu ook veel nodes zijn met rcn+ref=x + rwn_ref=y )
Met gewoon “ref=” , dan zou dat nummer net zo goed betrekking kunnen hebben op een heel ander type object, zoals een wandelpaaltje
Hier de andere kant van het gemarkeerde wandelpaaltje uit mijn vorige post, gebroederlijk naast het MTB-paaltje:
https://www.mapillary.com/map/im/maFVJv4yg4P6qoIbcRiHOq
als je alles in ref wil zetten dan zou het
ref=DTH38;GV 1133
worden
Dat is om meerdere redenen erg onhandig:
-je niet makkelijk alleen de objecten selecteren die in jouw geval relevant zijn (alleen fietspaaltjes of alleen wandelpaaltjes etc.)
-en als je de objecten al kan selecteren (bijvoorbeeld door de nodes weer apart/dubbel aan je lcn-relatie toe te voegen, dan krijg je in de verwerking / rendering ook de waarden van voor jou niet relevante punten cadeau
Handiger in dat geval is de systematiek volgen die we al gebruiken bij overlap van rwn en rcn knooppuntnetwerken :
lcn_ref=DTH38
lwn_ref=GV 1133
lcn_ref is voor knooppunten in lokale fietsknooppuntnetwerken. Je kan vinden dat het erop lijkt, maar dit is geen knooppuntnetwerk.
lwn_ref, daar geldt hetzelfde voor. Wordt momenteel zelfs aktief gebruikt in Frankrijk.
Het zijn genummerde wegwijzers, vergelijkbaar met hektometerpaaltjes. Slechts enkele zijn knooppunten waar een keuze gemaakt wordt tussen verschillende richtingen. Er zijn geen heen- en weer verwijzingen tussen de punten.
Het zijn wel punten gerelateerd aan één bepaald type route, namelijk mtb, waar geen apart knooppuntnetwerk voor gedefinieerd is.
Kortom, ik zou er dan liever een nieuwe tag voor maken: mtb_ref of zo. Dat is dan gewoon een lokalisatiepunt voor mtb-routes. Of ref:mtb. En dan zien om dat goedgekeurd en gerenderd te krijgen, ofwel gaan gebruiken voor een eigen kaart.
Als het niet specifiek aan mtb gerelateerd is, dan zijn het algemene lokalisatiepunten (nieuwe tag nodig denk ik) of reddingspunten (bestaand)
highway=emergency_access_point + ref lijkt precies hetzelfde te zijn als emergency=access_point en ref. Ik dacht dat dat wel gerenderd werd, maar ik zie het nergens op een kaart terug.
Knooppunten in een lcn worden inderdaad getagd als lcn_ref maar dat betekent niet dat ieder lcn_ref een knooppunt hoeft te zijn. Net zoals een koe een dier is maar niet ieder dier een koe. Als ieder lcn_ref een knooppunt zou moeten zijn zou een andere naam wat duidelijker geweest zijn. (bv node_number= oid.). De ref geeft m.i. aan dat het binnen de lcn een referentie is maar niet wat voor type referentie.
Ik begrijp je bedoeling dat die paaltjes onderdeel zijn van het routenetwerk. Dat druk je uit door de paaltjes op te nemen in de route relatie van dat mtb netwerk, prima. Wat ik niet begrijp is dat je het nummer van die palen zowel de tag lcn_ref en ref meegeeft. Eén Ref tag is toch genoeg? Dat die niet bij het wandelnetwerk hoort, wordt al weergegeven doordat je die verzameling palen onderdeel hebt van de mtb route relatie. Als die paaltjes ook bij het wandelnetwerk horen (zou kunnen, bv één paal met zowel de richting van wandelroute als mtb route) dan neem je ze toch ook op in de wandelroute relatie? Dus volstaat één tag, de ref. Laat die lcn_ref nou maar met rust. Of ga je tzt alle renderers benaderen (er zijn er vast meer dan de genoemde twee) dat hun rendering niet klopt? Het is op de kaart nu een grote puinzooi met nummers, dat gaat niet werken, je schiet zo je doel voorbij.
Jawel, er staat toch een tag met ermergency_access? En network=lcn staat er ook al. lcn_ref is totaal overbodig. Geldt trouwens ook voor rcn_ref, is kennelijk een tag die bedacht is voordat de route relaties zijn ingevoerd? Maar goed, ga dat maar proberen te veranderen binnen OSM, veel succes. 
Even ter verduidelijking dit plaatje:
Dat die refs onderdeel uitmaken van een lcn /mtb route kan de data consumer afleiden uit dit verband.
Je hebt helemaal geen extra lcn_tag nodig! Laat die nou maar lekker voor knooppunten gereserveerd, hoewel ik jouw redenatie wel kan volgen over dat een koe een dier is. Maar dat scheelt je een hele hoop werk om al die renderers te benaderen die het “verkeerd” doen.
Hier valt me trouwens nog wat op, er is een verschil tussen de refs van Den Treek (DTH) en Austerlitz en Zeist, die laatste twee hebben zo’n knooppuntnetwerk rondje, DTH niet. Wat is hier anders getagd, of is de ref gewoon een max. aantal tekens om binnen de cirkel te passen (zie ZE10)?
Wat ik jammer vind is dat je met je post hier de suggestie wekt dat ik hier tag voor de renderer. Daar is helemaal geen sprake van en was totaal mijn opzet niet. In de discussie met Peter Eldersen kwam ik hier op het idee om de nummers als lcn_ref te mappen omdat ik vond (en nog steeds vind) dat dit refs zijn van de MTB route. Niet meer en niet minder. Een PM of opmerking op een changeset met de vraag waarom ik dat zo gedaan heb zou m.i. meer op zijn plaats zijn geweest. Ik had het je graag uitgelegd.
We zijn het in ieder geval over 1 ding eens en dat is dat de prefix van de routerelatie niet echt nodig is ( of zou moeten zijn) voor zo’n ref als de ref al in de relatie is opgenomen. Dit omdat in de relatie zelf al staat of het een lcn, rcn etc is. Ik wist niet dat dit een overblijfsel was van het OSM tijdperk dat relaties nog niet bestonden maar had wel zo’n vermoeden. Dat betekent dat in OSM de slag gemaakt had kunnen worden om die prefix niet meer te gebruiken. Ik was in de veronderstelling dat die slag niet gemaakt was en dat betekent dat ik me maar hou aan hoe het volgens mij zou moeten en dat is met de prefix. Daar kan ik naast zitten natuurlijk maar op zich is het m.i. niet vreemd dat ik er een lcn_ref van maak.
Wellicht is die slag niet gemaakt wegens het voorbeeld dat Multimodaal aangeeft waarbij op 1 paal meerdere verschillende ref waardes te vinden zijn van verschillende type routes. Ik kan het je niet vertellen.
Als de consensus is om om bij een lcn de prefix weg te laten (en bij een rcn niet) dan wil ik me daar uiteraard wel aan houden maar het helpt wel als ik ergens kan vinden dat dit de consensus is. Ik ben nog steeds in de veronderstelling dat een ref die onderdeel is van een lcn, rcn, rhn etc. de prefix krijgt van die route. Het zou ook kunnen dat de prefix alleen gebruikt moet worden voor knooppunt routes en als dat niet het geval is (omdat niet iedere ref een keuzepunt is) dat er dan een ref gebruikt wordt. Als dat zo is dan verneem ik het ook graag. (linkje naar een wiki zou fijn zijn) En als het zo is dan blijft de prefix m.i. overbodig omdat deze nodes zijn opgenomen in een “network:type =node_network” waardoor je ook hier kunt afleiden dat het knooppunt nummers zijn maar dit even terzijde.
Ik wil nog benadrukken dat zo’n paaltje 2 doelen dient. Een ref binnen een lcn en een punt waarvan de 112 meldkamer deze in zijn systeem heeft staan. Dat zijn 2 verschillende dingen die hun eigen tagging kennen. De ene heeft een lcn_ref= en de ander de combinatie van highway=emerency_access_point met ref = . Iedere renderer mag bepalen welke van de 2 hij wil tonen en kan dat m.i. ook doen o.b.v. de huidige tags.
Uiteraard is er ook nog de mogelijkheid om van zo’n paaltje 2 nodes te mappen. Bijvoorbeeld de lcn_ref (of gewoon ref) op de highway (zoals Multimodaal aangeeft) en een punt op de plek van het paaltjes (naast de highway) met daarop de tags voor de emergency_access_point. Wellicht lost dit het probleem op voor een renderer maar dat mag m.i. niet de reden zijn het zo te taggen. Mogelijk is het wel.
En obv de plaatjes die je toont lijkt het mij dat dit een renderer probleem is. Als ze niet meer dan bv 3 characters kunnen/willen renderen voor een lcn_ref maar wel meer voor een emergency_access_point dan kun je dat de mapper niet kwalijk nemen. Maar als het zo is dat alleen voor knooppunt routes de prefix gebruikt mag worden en voor niet knooppunten de ref gebruikt mag/moet worden dan kan ik em ook nog snappen omdat die nummers veelal niet meer dan 3 posities hebben.
