Paalnummers MTB-route en aanvullende informatie toevoegen

Communities Nederland (Netherlands)
101

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 :slight_smile:

102

@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.

103

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.

104

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.

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

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

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)

105

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.

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.

106

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.

107

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?

108

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.

109

Ik geef de voorkeur aan één soort ref, vast op de weg of los maakt niet uit. Je mag 'm in de relatie hangen als je dat wilt. Mag geen bezwaar zijn van veel werk, zoals Peewee het heeft is het veel duidelijker dat het bij het netwerk hoort, en bij welk netwerk.
Maar in ieder geval niet én lcn_ref=* én ref=* voor één en hetzelfde paaltje. Bij voorkeur iets van mtb_ref in dit geval zodat je de gebruikelijke manier van taggen niet in de weg fietst. :wink:

110

Heren … bedankt voor de bijdrage. Het lijkt erop dat we meer tot elkaar gaan komen. Ik moet toegeven dat het (ook?) voor mij wel wat verwarrend was omdat ik in het begin ook niet door had dat die paaltjes 2 functies in 1 hadden.

Ja is heel herkenbaar. En later als je met anderen er wat dieper op ingaat verandert die mening soms/vaak (doorhalen wat niet van toepassing is) en vervolgens vind je em zelf weer goed. Mooi dat dat zo werkt :wink:

Het voorstel van Multimodaal om de highway=emergency_access_point naast de weg te taggen en de lcn_ref op de weg kan ik prima mee leven. Ik heb al het gevoel dat de meeste *cn_ref op de weg liggen dus daarvan afwijken is m.i. dan niet verstandig. En de highway=emergency_access_point naast de weg vind ik ook prima al lijkt de key (highway) er voor te pleiten om em op de highway te zetten. Maar het is voor mijn geen halszaak. En als we de highway=emergency_access_point met zijn ref op 1 node mappen naast de weg en de lcn_ref op de weg dan kom je tegemoet aan het bezwaar van ligfietser dat je niet zowel lcn_ref als ref op 1 element hebt staan.

Ik heb echter wel de voorkeur om de lcn_ref op te nemen in de relatie. Niet alleen omdat we dat bij bv rcn_ref ook doen maar ook omdat ik relaties datamodeltechnisch zo mooi vind om elementen die bij elkaar horen daar ook bij elkaar te zetten. Ieder met zijn eigen role.

Ik begrijp dat je de lcn_ref per relatie kunt groeperen door het aanwezig zijn van die punten op een highway die wel onderdeel is van de routerelatie maar dat is toch net wat anders. Niet alleen omdat het iets lastiger is maar ook omdat je dan minder controle hebt. Want wat doe je als een ander lcn netwerk kruist en precies op het kruispunt een lcn_ref heeft staan. Die zit dan onterecht ook in jouw relatie en daar heb je verder geen controle meer op. Misschien wat ver gezocht maar geeft wel aan dat je minder controle hebt. En voor rcn nemen we de rcn_ref wel op in een relatie dus waarom zou je daar voor een lcn van afwijken?

Voor een aantal MTB routes heb ik die lcn_ref opgenomen in relatie met als rol ref zoals in een plaatje eerder van Ligfietser ook te zien is.

Ik was al bezig met een overpass kaartje om rollen binnen relaties inzichtelijk te maken. Is nog niet helemaal af maar geeft wel een beeld. Mijn idee was om maximaal gebruik te maken van de functionaliteit die relaties bieden en dat is alles wat bij elkaar hoort ook bij elkaar op te nemen in de relatie met ieder hun eigen rol.

Op deze manier kun je eenvoudig alle elementen van bv een MTB route inzichtelijk maken. Voor de blauwe MTB route van DTH krijg je dan alle wegdelen met als rol veelal “main” maar ook “approach” en “alternative” voor de aanrijroutes en routeverkorting. Daarnaast zelfs ook nog het informatiebord met role “information”. Dit maakt het voor data consumers wel heel makkelijk een goed beeld te krijgen van die route.

En om met Peters woorden af te sluiten: “Dit is uiteindelijk mijn mening! Ik vind hem zelf wel goed eigenlijk.” Maar ik sta open voor kritiek/suggesties. :wink:

111

Drie overdenkingen

  • rcn_ref wordt in de routes opgenomen, maar dat is voor functie of display niet nodig. Sommige mappers vinden het handig bij het mappen (ik ook, ik maak dan minder integriteitsfouten), maar het kan geen argument zijn voor punten die op een andere manier gebruikt worden. Het is ook geen argument tegen… maar bij andere netwerken dan rcn is het veel minder gebruikelijk.
    Ik moet wel denken aan de manier waarop knooppunten in de netwerkrelaties zitten: een zak knopen waar niemand in kijkt, ze zitten er alleen omdat het nou eenmaal moet anders gaat de checker piepen, en de checker checkt het omdat het nou eenmaal zo gedefinieerd is dat het erin moet zitten. Het oorspronkelijk nut is vervallen. Hm… Moraal: je moet er ook echt wat mee doen aan de eindgebruikerskant, met dat membership van de relatie en met de rolaanduiding.
    Was je trouwens van plan om ze ook precies op de juiste plaats tussen de wegen te zetten? Dan kan je de sorteerfunktie in JOSM niet meer gebruiken, en andere bewerkingen verstoren de volgorde geregeld (al is dat veel minder geworden dan pakweg een jaar geleden; Id heeft daar goed werk verrricht want dat was daavoor vrijwel altijd de tool waarmee het gedaan was).

  • De kans dat een ander lcn-netwerk precies datzelfde paaltje gebruikt met een ander referentienummer… lijkt me verwaarloosbaar. Het kwam (komt) bij wandelnetwerken wel voor, maar dat was/is dan meestal een aansluitingsfout die nog opgelost moe(s)t worden. Het heeft dan geen enkel gevolg, want je neemt gewoon een van de twee en gaan met die banaan. Als er maar een labeltje aan hangt.
    Als je die kans reëel acht of totaal uit wil sluiten, omdat de doelen van de twee nummers kunnen verschillen, dan zou ik ook echt een andere soort ref nemen, bv inderdaad mtb_ref met bijpassende definitie, af te beelden door mtb-kaarten, of beter nog ref:mtb=* om in de stijl van de ref-wiki te blijven.

  • rollen: voor recreatieve routes (waaronder mtb, en niet spevciaal knooppuntroutes) is een rollenset approved, inclusief aanwijzingen voor het geval wegen twee rollen krijgen (bv forward tegelijk met alternative of connection).
    Voor nodes is alleen de rol guidepost “erkend” voor serieuze wegwijzers, van die dingen met armen, of paddestoelen), ik denk de facto, en vele andere zijn gesuggereerd en bediskussieerd, allerlei dingen zijn adhoc gebruikt, maar niets in de richting van consensus of zelfs maar een serieus voorstel. Dan denk ik dat je alleen je eigen rendering en data use zover krijgt om daar iets mee te doen!

112

Er zijn meer highway-nodes die niet op de weg liggen maar wel losjes (ruimtelijk) bij de weg horen. Maar emergency=access_point is ook mogelijk, dat is vzihb precies hetzelfde.

113

(was dubbel)

114

Volgens mij kan dat echt niet, er is maar 1 paal met 1 nummer. Dan mag je daar geen 2 nodes van maken op twee verschillende locaties.

115

Ik ben het met je een dat er verschillende redenen zijn waarom we mappen op een bepaalde manier. Het uiteindelijke doel is om data consumers te helpen er iets moois van de maken maar keuzes om de integriteit te verbeteren zijn er ook en dat helpt uiteindelijk ook weer de afnemers.
Het mappen op een manier waar momenteel een dataconsumer (nog) niets mee doet is m.i. geen reden om daar mee te stoppen (of niet te beginnen). Als je alle members die horen bij een relatie in die relatie stopt (met de goede rol) dan stel je de data consumers in staat om zelf een keuze te maken welke en hoe te gebruiken.

Je vraag over de plaats (volgorde) in de relatie is een goeie. Ik heb momenteel alle wegen van de hoofdroute netjes achter elkaar in de goede volgorde gezet maar de rcn_ref daar niet tussen staan. Momenteel staan die er allemaal boven. Net als de wegdelen die geen main” zijn maar bv “alternative” of “approach”. Had wellicht ook gekund om ze er onder te zetten. Is daar nog een voorkeur voor gedefinieerd? (onder of boven de main?)

Op zich acht ik die kans niet heel groot maar de suggestie om een andere ref dan lcn_ref te gebruiken vind ik wel interresant. Momenteel worden MTB routes gemapt als lcn maar dat zijn in de praktijk wel andere lcn dan die routes voor gewone fietsen. Ze zijn daarvan wel te onderscheiden omdat ze route=mtb zijn en geen route=bicycle maar toch.Wellicht is het beter om niet lcn te gebruiken maar iets anders. En in dat geval kunnen we ook een andere ref gebruiken. Op mij komt het inconsequent over als we wel lcn gebruiken voor een MTB route maar vervolgens geen lcn_ref zouden moeten gebruiken maar bv mtb_ref. Misschien de MTB routes niet meer taggen als lcn maar iets anders ?

In het begin zal dat zeker zo zijn maar je stelt data consumers wel in staat er iets mee te doen. Een geaccepteerd voorstel is m.i. de beste manier om wijzigingen in OSM door te voeren maar het kost heel veel tijd (zoals we beiden weten) en is niet de enige manier. Je mag ook zonder een geaccepteerd voorstel een nieuwe mappingsmethode gebruiken. Daarbij is het wel van belang dat deze niet tegenstrijdig is met wat gangbaar is of op een andere manier data consumers enorm in de weg zit. Dat er af en toe een dataconsumer/renderer iets moet aanpassen aan zijn kant is inherent aan wijzigingen in OSM. Zolang deze maar de data krijgt om dat te kunnen doen (liefst eenvoudig) is er m.i. niet veel aan de hand.

116

Op zich is het niet ongebruikelijk om bepaalde elementen die naast de weg liggen op de weg te mappen. Dat doen we met rcn_ref maar ook met highway=traffic_signals. Waar ik nu wel benieuwd naar ben is hoe jij zou handelen in de volgende situaties.

Stel dat een MTB route geen melding over 112 op zijn paaltjes had staan maar alleen de referenties en evt een richtingsdriehoekje.

Als ik die zou zijn tegen gekomen dan had ik die op 1 van de volgende manieren gemapt.
**
Manier 1**
Ik zet de lcn_ref OP de weg (en neem ze evt op in de relatie maar dat is voor deze vraag niet relevant
Manier 2
Ik zet de lcn_ref NAAST de weg (en neem ze evt op in de relatie maar dat is voor deze vraag niet relevant)

Een paar maanden later wordt er een melding bij gezet dat je het nummer/ref ook kunt gebruiken om een melding te maken bij 112. Wat zou jij doen in geval 1 en in geval 2 als je het heel belangrijk vindt dat er een highway=emergency_access_point gemapt moet worden?

117

Herkenbaar voor derden van een emergency_access_point

Geval 1, Niet herkenbaar

Geval 2, Wel herkenbaar

118

Ik heb niet zo lang geleden de fout gemaakt om te vlot te werk te gaan (Nee echt? Ja, gek he?). Het is wel zo netjes om in ieder geval zo goed mogelijk te inventariseren óf er inderdaad toepassingen last van hebben, en die dan minimaal in te lichten over de wijziging, of de tijd te geven eea aan te passen.
Ja, dat is wel lastig en vertragend, zeker als je er verschillende forums bij betrekt. Maar het helpt wel.

Mijn ervaring is dat als het om routes en zeker om knooppunten gaat, je niet bij de tagging list moet wezen. De meesten snappen uberhaupt niet waarom je een routerelatie zou vastleggen, je kan toch gewoon van A naar B routeren? Of waarom het eigenlijk vreemd is om een al kompleet aanwezige route via een gpx naar een device of app te sturen die het dan opnieuw gaat routeren op basis van OSM. Terwijl hij de route dus al kant en klaar in OSM heeft, en ook op de kaart toont. Maar goed, dat is een andere frustratie!

119

In het eerste geval: helemaal niet mappen. Zo’n nummer op een routepaaltje is kennelijk alleen voor administratieve doeleinden van de beheerder daar geplaatst. Heeft m.i. op dat moment nog geen enkele waarde voor de gebruiker (fietser, wandelaar, ruiter etc). Ik moet er niet aan denken om de richtingaanwijzers van de ANWB die ook een ref nummer hebben te gaan mappen maar ieder zijn meug.

Pas als de 112 melding erbij wordt gezet wordt het voor de fietser/paardrijder/wandelaar en dus ook voor OSM relevant. Mappen op of naast de weg, ik heb geen specifieke voorkeur, mag beide. De rcn_ref knooppunten heb ik vroeger ook gemapt op de plek waar de overzichtskaart stond en niet op de weg, tegenwoordig zou ik dat op de weg zetten. Maar wat mijn punt is, gebruik liever niet twee nodes voor één punt. Zowel én op de weg én op de plek waar dat paaltje fysiek staat is m.i. niet gebruikelijk.

En dan mijn volgende praktische vraag. Ik heb zelf ervaring met het renderen van kaarten.
De renderers moeten dus op de hoogte worden gehouden van een veranderde zienswijze van mappen. De wiki moet worden aangepast want tot nu toe is lcn_ref alleen voorbehouden tot knooppunten*. In ieder geval Osmand en de cyclemap.org moeten worden benaderd dat wij dit hier nu anders gaan mappen. Dat gebeurt niet vanzelf, daar ben jij als mapper óók verantwoordelijk voor. Ga jij dit aanpakken?

*) Zie https://wiki.openstreetmap.org/wiki/DE:Key:lcn_ref

120

Het was niet de vraag of jij dat moest mappen. De vraag was als er een paal is die 2 doelen dient hoe map je dat. Maar laat ik de vraag dan nog iets anders stellen.

Stel er is een rcn_ref fietsknooppunt. Die staat nu gemapt op de weg. Jij fietst erlangs en ziet opeens dat er op dat paaltje een bordje bij is gekomen die aangeeft dat je bij calamiteiten 112 moet bellen. Jij wilt de highway=emergency_access_point toevoegen. Hoe doe jij dat dan?

Wellicht is het niet gebruikelijk om een paaltje met 2 doelen als 2 verschillende nodes te mappen. Maar stel dat hetgebruikelijk is om de ene functie op de weg te plaatsen (rcn_ref) en de andere ernaast (emergency_access_point) … dan is er wel een dillema. En ik heb niet echt een voorkeur hoor dus als een aantal renderers een voorkeur hebben voor een methode dan heb ik er geen moeite mee om die te gebruiken.

En dan nog even over de lcn_ref die in jouw ogen altijd voorbehouden zou moeten zijn aan een knooppunt (met keuze mogelijkheid). Ik begin steeds meer te geloven dat er nogal wat spraakverwarring is (geweest). Een node_network zou je ook kunnen zien als een (fiets) route waar je van punt(node) naar punt(node) fietst zonder keuzemogelijkheid. Zie hier een voorbeeld van zo’n een lcn waarbij ik lcn_ref zie die op de weg zijn geplaatst. Osmand, Waymaked trails en de fietskaart lijken hier prima mee overweg te kunnen. Zie overigens ook de tag roundtrip=yes. In het woord node zit niet per definitie een keuze opgesloten. Maar een knooppunt suggereert al veel meer dat er meerdere wegen bij elkaar komen en dat je binnen het netwerk een keuze hebt.

Op zich snap ik de verwarring wel. Omdat zeker in NL we dit soort netwerken niet/nauwelijks kennen vereenzelvigen we node_netwerk met een knooppunt netwerk met keuzemogelijkheid maar dat is niet altijd het geval. Om onderscheid te maken is er later een extra tag network:type=node_network voor knooppuntnetwerken bedacht. In die wiki staat nog dat andere values voor de key network:type bedacht kunnen worden. Als network:type= node_network bedoeld is voor knooppunt netwerken met keuzemogelijkheid (zo komt het op mij over in ieder geval, ook gezien de foto met richings keuzes) dan zouden we een andere value kunnen bedenken voor de netwerken die een rondje beschrijven. (iemand suggesties?) Misschien moet ik ook de roundtrip=yes toevoegen op de MTB routes omdat ze in de basis wel een roundtrip zijn.

Dan even over de problemen van renderers met de huidige tagging van de MTB routes op de Utrechtse heuvelrug. Wereldwijd zijn er maar een heel beperkt aantal lcn_ref dus wellicht hebben deze bij renderers ook niet heel veel aandacht gehad omdat ze ook weinig problemen hebben opgeleverd. Wat mij nu opvalt bij een aantal renderers is het volgende:

Het lijkt erop dat zowel de OSM fietskaart als Osmand niet meer dan 3 posities hebben gereserveerd voor de tekst van een lcn_ref en dat als gevolg daarvan de ene lcn_ref wel en de andere niet goed wordt gerenderd.
Osmand lijkt qua rendering (kleur/zoomniveau) geen onderscheid te maken in lcn_ref en rcn_ref
Osmand toont alle highway=emergency_access_point van de Utrechtse heuvelrug (waar ook de lcn_ref op staan) maar die bij de loonse en Drunense duinen (waar geen lcn_ref op staat) worden niet getoond. Misschien toch een issue met de combinatie lcn_ref en emergency_access_point?

En als het renderers helpt dat ik ze een mail stuur over vreemde rendering dan wil ik dat best doen hoor. Vooralsnog zou ik dan melden dat ik het fijn zou vinden als ze ook de lcn_ref met meer dan 3 posities willen renderen.