Paalnummers MTB-route en aanvullende informatie toevoegen

PeeWee32 · 2020-11-21T07:51:16.000Z

Geim:

Geim:

PeeWee32:

Kun je dan niet veel makkelijker in Osmand je huidige locatie delen (in lat & lon) met de meldkamer?

Goeie vraag. Zou handig zijn als dat zou kunnen maar hoe stel je je dat voor? Via Whatsapp naar 112 doorsturen?

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.

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

Geim:

Maarre hoe wilde jij doorgeven tussen welke paaltjes je ligt met, zeg, een gebroken bekken?

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.

Geim:

PeeWee32:

Als ik hier kijk zie ik die optie er niet bijstaan. Ook in de daar genoemde infografic mis ik die optie.

Staat net onder de optie met paalnumemrs MTB

Maar ik zie daar wel een 112 app staan. Wellicht is dat het ei van Columbus?

Ik zie alleen tolkcontact staan. Bedoel je die?

Nee… op de infografic zie ik rechts de 112 app die in ontwikkeling is.

ligfietser · 2020-12-14T15:26:25.000Z

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.

ligfietser · 2020-12-14T18:02:19.000Z

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.

multimodaal · 2020-12-14T19:56:40.000Z

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…

PeeWee32:

Mijn voorstel zou dan zijn om de nodes van de paaltjes te verplaatsen naar een node in de weg (meestal op het kruispunt van highways) en de nodes zelf uit de relatie te halen.

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

multimodaal · 2020-12-14T20:03:17.000Z

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.

PeeWee32 · 2020-12-14T20:39:00.000Z

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.

multimodaal · 2020-12-14T21:26:44.000Z

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

Peter_Elderson · 2020-12-14T22:04:00.000Z

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.

PeeWee32 · 2020-12-15T06:58:19.000Z

Peter Elderson:

lcn_ref is voor knooppunten in lokale fietsknooppuntnetwerken. Je kan vinden dat het erop lijkt, maar dit is geen knooppuntnetwerk.

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.

ligfietser · 2020-12-15T08:21:43.000Z

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.

ligfietser · 2020-12-15T08:28:13.000Z

PeeWee32:

De ref geeft m.i. aan dat het binnen de lcn een referentie is maar niet wat voor type referentie.

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:

lcn.jpg959×774 245 KB

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.

osmand.jpg737×593 132 KB

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)?

PeeWee32 · 2020-12-15T19:21:14.000Z

ligfietser:

En mocht Osmand dat dan niet renderen, dan kan je via github een verzoek indienen.

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.

multimodaal · 2020-12-15T20:09:45.000Z

Het feitelijk gebruik van lwn_ref is zeker niet beperkt tot alleen knooppunten
(in 2017 heeft iemand dat in een stil hoekje van de wiki wel opeens tot “node networks” beperkt, en daarbij zelfs zo sterk beperkt dat je die tag alleen maar in Duitsland zou mogen gebruiken… 2013 vs 2017, ook niet echt maatgevend dus…)

Verder is de scheiding ook niet zo messcherp als je bedenkt dat we alleen in ons land al meer dan 1.000 rwn_ref’s hebben met expected_rwn_route_relations=2, oftewel ook geen echte junctions waar je meer dan 1 keuze hebt in voorwaartse richting.
https://overpass-turbo.eu/s/11dS

Het gebruik van lwn_ref om aan te geven dat de betreffende data betrekking heeft op de lcn-route.

Door alles (alleen) in "ref " te gooien ipv “lcn_ref” -met als aanleiding kennelijk ongewenste rendering…- worden er meer problemen gemaakt dan opgelost:

-het opnemen van de nodes (die al in een way van de relatie zitten) is extra werk voor zowel de invoer als de verwerking (die dan uit het lidmaatschap van een relatie zou moeten afleiden dat “ref” slaat op “lcn”

-het opnemen van deze nodes apart in de relatie wordt door veel mappes als dubbel -en daarmee ongewenst- gezien, de nodes zitten immers al in de ways

-bij meerdere soorten refs op 1 object kom je op het probleem zoals hierboven geschetst; de ref waarde van het object dat lid is van de lcn-relatie (en van de lwn-relatie) wordt dan

ref=DTH38;GV 1133

Dan weet je dus nog niet welk getal op de lcn slaat en welk getal op de rwn
Ik heb in het veld ook al situaties gezien waar je op 3 waardes uit zou komen in ref (fietswegwijzer met lwn+rwn)

Het gebruik van de route-prefix lost dat op.
En als je het onderscheid tussen
-"echte"knooppuntnetwerken (meeste nodes meer dan 2 verbindingen, sommige met 2)
en
-dit soort "pseudo"knooppuntnetwerken (meeste nodes 2 verbindingen, sommige 3 in geval van splitsing van routes)
expliciet wil maken, dan hebben we daarvoor de prachtige tag network:type=node_network (dank daarvoor nog, Peter & co!).

Daarmee geef je aan dat iets een (echt) knooppuntnetwerk is. Die zetten we dus niet op de mtb-paaltjes

ligfietser · 2020-12-15T21:11:50.000Z

@peewee: als er een iemand is die hier tagt voor de renderer ben ik het wel. Die term heeft m.i. een veel te negatieve lading gekregen hier op het forum en dat is jammer. We taggen immers allemaal om iets op de kaart te kunnen krijgen, daar is helemaal niets mis mee. Het is alleen not done als we objecten gaan taggen die er helemaal niet zijn bv om een leuk kleurtje te geven aan de kaart, maar daar is hier geen sprake van. En in dit geval maak ik me druk om alarmpaaltjes die de kaart (en ik in eerste instantie ook) als knooppunten ziet maar misschien heb ik het mis en zal de renderer moeten worden aangepast, bv door ook te kijken naar de tag network:type, zoals ik bij mijn OFM ook heb moeten doen.
@multimodaal: bedankt voor je verhelderende bijdrage, daar kan ik me wel in vinden.

Peter_Elderson · 2020-12-16T00:00:25.000Z

multimodaal:

dat iets een (echt) knooppuntnetwerk

Ik heb die vraag de laatste tijd heel vaak gekregen… Sommigen zeiden: het moet met nummertjes gaan, anders is het geen knooppuntnetwerk. Anderen zeiden: alleen de volgende knooppunten moeten erop staan, of ze moeten heel duidelijk van eindere bestemmingen gescheiden zijn door aparte bordjes of héél duidelijke grotere letters met een apart kadertje of zo…

Volgens mij gaat het om het systeem. Je kiest bij een knooppunt/keuzepunt het vervolg van de route niet op eindbestemming, maar op volgende knooppunt/keuzepunt. De aangrenzende knooppunten verwijzen twee aan twee naar elkaar. Tussen de knooppunten/keuzepunten is een generieke aanwijzing genoeg om de volgende te bereiken.

De mtb-routes voldoen hier niet aan. Je rijdt het rondje en daarbij kom je nummers tegen, maar de nummers verwijzen niet naar elkaar. Er is geen keuze; om de route te rijden hoef je geen secties achter elkaar te plakken. Op een paar punten na, die zou je dan knooppunten kunnen noemen, als ze naar elkaar verwijzen.

Bij de knooppuntennetwerken worden de intersecties van wegen als knooppunten getagd. Dan staan die knopen automatisch in de routes (want eindpunten van de ways). Bij de mtb-routes zie ik dat de paaltjes zelf getagd zijn, dus ze staan niet in de routes, maar ernaast. Dan zijn het geen knooppunten zoals we die gedefinieerd hebben. Het zijn ook geen guideposts. Het zijn genummerde pijlbordjes, maar voor het routeren zijn de nummers niet nodig, je komt er alleen langs. Daarbij doet het er in wezen niet toe hoe je je voortbeweegt.

Het enige waar ze apart voor gemapt worden (en dat is denk ik een prima reden om ze te mappen) is de functie als lokalisatie voor speciale gevallen.
Dus highway=emergency_access_point of emergency=access_point, en ref=nummer op het paaltje. Rendering is er misschien al (ik weet zeker dat ik het ergens gezien heb), en anders kan die aangevraagd worden bij de algemene renderers of de gespecialiseerde toepassingen/lagen.

Als er langs dat paaltje ook knooppuntroutes van alle soorten lopen, maakt niet uit want die gebruiken de intersectie-knopen op de ways, niet de paaltjes ernaast.

Dit is uiteindelijk mijn mening! Ik vind hem zelf wel goed eigenlijk.

Dus hoewel *cn_ref oorspronkelijk misschien niet voor knooppuntnetwerken gereserveerd was, lijkt het mij niet handig om in dit stadium die tag voor iets anders te gaan gebruiken.

multimodaal · 2020-12-16T10:21:22.000Z

Ik ben het met je eens hoor dat deze mtb-routes erg ver verwijderd staan van echte knooppuntnetwerken en dat er zeker geen tag network:type=node network op moet. Er zijn andere routenetwerken (of semi-knooppunten) aan te wijzen die in een grijs gebied zitten, maar deze niet.

Peter Elderson:

Dus hoewel *cn_ref oorspronkelijk misschien niet voor knooppuntnetwerken gereserveerd was, lijkt het mij niet handig om in dit stadium die tag voor iets anders te gaan gebruiken.

Daar ben ik het niet mee eens. Als we vanaf nu *cn_ref -in afwijking van het bestaande gebruik- alleen nog maar zouden willen gaan gebruiken voor knooppuntnetwerken, dan was het ook niet nodig geweest om network:type=node_network op ondertussen meer dan 57.000 nodes (taginfo) met rcn_ref / rwn_ref / lcn_ref etc. toe te voegen

Maar de (terechte) reden die in het voorstel werd gegeven was juist:
https://forum.openstreetmap.org/viewtopic.php?pid=762039#p762039

Peter Elderson:

LS
network:type=node_network toevoegen aan alle knooppunten, knooppuntroutes en de knooppuntnetwerkrelaties.
Dit geldt voor alle recreatieve knooppuntnetwerken.

Daardoor staat bv network=rcn zonder de nieuwe tag niet meer voor een fietsknooppuntnetwerk, maar voor een gewone regionale fietsroute.

[…]
Een logische vraag is: waarom ook de knooppunten meetaggen, dat zijn immers nodes met een knooppuntref erin, dus dan weet je het al! Antwoord: het blijkt behoorlijk vaak voor te komen dat nodes met een XXn_ref getagd worden terwijl ze níet in een knooppuntnetwerk zitten. Daar zijn zeker wat fouten bij, maar ook series waar het niet onlogisch is, bijvoorbeeld genummerde paaltjes die een kanoroute in volgorde passeert, getagd met lpn_ref=*. Vandaar.

En dat gebruik van bijvoorbeeld lpn_ref=* is ook zo beschreven op https://wiki.openstreetmap.org/wiki/Key:lpn_ref en https://wiki.openstreetmap.org/wiki/Tag:route%3Dcanoe

Local canoeing routes (not being a junction network) in complex water area’s often also have numbered signposts along the way for orientation purposes. These nodes can be tagged with lpn_ref=*.

Die mtb-paaltjes lijken hier heel erg sterk op. Nu zijn ze toevallig naast de weg getagd, maar PeeWee geeft aan dat hij ook taggen op de weg overweegt, en dat laatste zou ik zelf ook hebben gedaan (ik wil er ook al een hele tijdje een aantal doen, maar er ligt nog zoveel ander survey-materiaal om in te voeren, oa kanoroutes…)

Wat vinden jullie hiervan als compromis voor de nu overlappende tagging van ref en lcn_ref op dezelfde nodes?
Op de nodes *naast *de weg highway=emergency_access_point met alleen ref
De lcn_ref verplaatsen naar een node op de weg (zonder ref)
Geen van beide nodes apart opnemen in een routerelatie (ook een wandelaar die langs de een emergency_access_point komt kan 112 bellen, en de node met lcn_ref zit al in de way die in de lcn-relatie)

En om elke mogelijke twijfel weg te nemen of het misschien toch niet een klein beetje om een knooppuntnummer zou kunnen gaan, zou bij de node met *lcn_ref *eventueel nog kunnen worden toegevoegd: network:type=roundtrip oid

Het taggen van een object naast de weg en de doorwerking op de weg lijkt op dat bij een traffic_sign, dat zetten we de werking daarvan meestal *in ieder geval op de weg *(de hele weg in dat geval), en eventueel aanvullend als object naast de weg. Het plaatsen op een node in de weg en het paaltje ernaast lijkt nog het meest op wat we doen met aftsandsmarkeringen op rivieren https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dmilestone

(waarbij het verband tussen het paaltje en de lcn-route wel sterker is dan bij de rivier: als je alle paaltjes bij de rivier weghaalt, dan blijft de rivier de rivier en kan je de afstanden zelf ook nog wel meten, maar als je genoeg routepaaltje weghaalt dan wijzigt /verdwijnt de route)

Allroads · 2020-12-16T12:11:04.000Z

Voor mij hoort dat paaltje naast de weg.
Dat MTB met een emergency wijze is gekomen is logisch.
In het veld/bos, voor vele andere sporters en mensen die daar genieten, geldt eveneens dezelfde noodzaak.
Het mekaar kunnen helpen.

Het kunnen benoemen waar je bent. Vlakbij, naar toe te gaan.

Zou dit in een opmaat zijn naar meer van deze type bordjes, komt er later een meer landelijkere aanduiding?
Ergens begint het, is overgewaaid uit andere gebieden.

Een paar jaar geleden had ik een discussie over stenen met nummers die men wilde verwijderen ( op de perceel hoek). Deze lagen bij kruisingen.
Men wilde het niet meer aangegeven op papieren kaarten en op de bebording. Waarom wel, het inzien van het nut.

verliezen van historisch identiteit van het bos. Dat maakte het bos anders dan andere bossen.
gebruik voor routering, daar moet je denken aan speurtochten, droppings, etc. vele campings gebruikte het in de notities.
aangeven waar je bent. Een herkenningspunt, die te benoemen is. naam nummer een goede referentie.

Kruispunten in het bos en het benoemen.
Wel of niet toegankelijk voor emergency.

Een paaltje is nodig om het in een app te kunnen aangeven, het kunnen benoemen in het veld.

De boswachter kon direct vertellen als ik een nummer op noemde waar het was, gebiedskennis, hij zei toen dat ze dat al eens hadden gebruikt bij een noodgeval. De hoogte van het nummer was voor hem al belangrijk in welke richting hij moest gaan.

Het taggen van een object naast de weg en de doorwerking op de weg lijkt op dat bij een traffic_sign, dat zetten we de werking daarvan meestal in ieder geval op de weg (de hele weg in dat geval), en eventueel aanvullend als object naast de weg

Ooit ben ik het verkeersbordentopic gestart, wat daar uit gekomen is, dat we het vooral bij fietspaden gebruiken.
De doorwerking, is het afgeleide van de node (verkeersbord), het access, nu zetten we daar ook traffic_sign=NL:G12a op de way. Toen werd duidelijk, waarmee we te maken hadden. Inzichtelijker, we kunnen de afgeleide tagging beter controleren.
Nu ben ik van mening, dat we daar in de fout zijn gegaan. Mea culpa, niet goed genoeg doordacht, zo gaat dat.
Hoewel de methodiek ook in de wiki beschreven staat. Hetzelfde verhaal niet goed genoeg doordacht. Overgenomen., helaas.
Het afleiden, van de source had benoemd moeten worden als source:traffic_sign=NL:G12a, en oneway als source:traffic_sign:forward=NLG12a
Laatst kwam ik een blog tegen over verkeersborden, daar werdt vermeld het vele aantal verkeersborden in Nederland, Osm onderzoek, en dacht toen, zo worden er verkeerde conclusies getrokken op basis van wat wij invoeren.

Met andere woorden.
Ik zie een nieuw systeem in ontwikkeling, die elders naar toe gaat waaien.
Wat in mijn ogen los staat van enige routes, wel logisch is dat het bij routes als eerste komt, gebruiksintensiteit, de keuze voor nummers (benoeming) moet zo gekozen zijn dat de paden/wegen niet behorende bij de route een goed samenhangend verband vormen.

En dat we met de keuze hier, daar rekening mee moeten houden.

Edit ik zie hier dan ook een overeenkomst met
Tag:emergency=assembly_point

Wij, Openstreetmap, benaderen, als routeerders/ gebruikers, situaties vanuit een andere ooghoek, het valt ons op wat jaren niemand anders is opgevallen.
Maak je een melding, dan krijg je als reactie, wat bedoel, niet de insteek begrijpend, zo hadden we het nog niet bekeken.
Zo bij het maken van tags, komen we wellicht tot andere conclusies, waar de initiatiefnemers van de emergency points nog niet aan gedacht hebben, zo ook de eigenaren van de percelen die toestemming geven de paaltjes te plaatsen.
Een reactie die kant op is wellicht gewenst.
Zo ook de veiligheid regio, gaan die daar op in spelen.

Peter_Elderson · 2020-12-16T12:54:06.000Z

Allroads:

Edit ik zie hier dan ook een overeenkomst met
Tag:emergency=assembly_point

Daar heb ik ook naar gekeken, maar dat is toch wat anders. Als er een ramp is (dus niet dat houzelf wat overkomt) dan ga je daarnaartoe. Dus bijvoorbeeld, een aangewezen verzamelpunt bij brand. Mocht er brand zijn dan gaat de reddingsploeg daarheen, zonder verdere melding.
In dit geval gaat het om: ik sta op punt X, kom mij redden.

Peter_Elderson · 2020-12-16T13:15:18.000Z

multimodaal:

Wat vinden jullie hiervan als compromis voor de nu overlappende tagging van ref en lcn_ref op dezelfde nodes?
Op de nodes naast de weg highway=emergency_access_point met alleen ref
De lcn_ref verplaatsen naar een node op de weg (zonder ref)
Geen van beide nodes apart opnemen in een routerelatie (ook een wandelaar die langs de een emergency_access_point komt kan 112 bellen, en de node met lcn_ref zit al in de way die in de lcn-relatie)

Op die manier kan je ze in de route opnemen, als je de nummers belangrijk genoeg vindt voor het volgen van de route zelf.
Als het echt een nieuw network:type zou zijn dan zou je daar een passende value voor moeten verzinnen. Roundtrips een network:type noemen, hm, kwenie…

De kanoroutes met genummerde paaltjes gaan nu steeds meer op in de kanoknooppuntnetwerken denk ik?

Allroads · 2020-12-16T13:20:00.000Z

Peter Elderson:

…maar dat is toch wat anders…

Beide, hoe kom je tot elkaar.
De ernst van de situatie is bepalend.
De plaats van highway=emergency_access_point is zo gekozen i.v.m. bereikbaarheid emergency. (voertuigen)
Indien mogelijk, zal je je naar dat punt begeven. Of gaat een ander naar dat punt om aanwijzingen te geven, zijn fiets af te staan aan de dokter.