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.
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.
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
@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.
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.
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
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)
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.
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.
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.
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?
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.
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.
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
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.
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!
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.
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.
