Paalnummers MTB-route en aanvullende informatie toevoegen

eggie · 2020-12-19T11:12:04.000Z

Cor… dit is gewoon één doel volgens mij… de knooppuntroutes.
Het is niet direct bedoeld voor hulpdiensten.

Peter_Elderson · 2020-12-19T11:30:02.000Z

Het netwerkknooppunt is de intersectie, niet het paaltje. Het noodpunt is het paaltje, niet de intersectie.
Gewone pijlpaaltjes worden in knooppuntnetwerken niet gemapt en hebben geen knooppuntnummer, maar kunnen wel een noodpunt zijn en een noodnummer hebben.

Ik denk dat je hier het beste de boel gescheiden kan houden: netwerken gebruiken de intersecties, noodpunten staan ernaast.

Ook als er een netwerk is waar de knooppuntnummers ook als noodnummers dienen.

Als het op een bepaald punt logisch is om paaltje en intersectie als 1 punt te taggen, omdat bv het knooppuntnummer tevens als noodpuntnummer dient, is het MI niet fout om dat te kombineren op de intersectie. De **n_ref van het knooppunt bijt de ref van het emergency-punt niet.

Wat ik niet zou doen is noodpunten tot knooppunten benoemen omdat ze in een bepaald geval langs een bepaalde route staan.
In dit geval verwijzen de punten niet twee aan twee naar elkaar, dus het is geen knooppuntnetwerk.

Allroads · 2020-12-19T12:01:53.000Z

Hoe doe jij dat dan?

Zou kunnen doen.

Wat betreft de route, het paaltje vertelt je dan, dat op het knooppunt je een bepaalde kant op kan kiezen.

Het knooppunt kan in verschillende vormen aanwezig zijn:
kruising/rotonde (meerdere), met wel/niet naastliggende fietspaden/voetpaden, met wel/niet een rijrichting.
Vergelijkbaar met de knooppunten bij snelwegen, het is een gebied, waarbinnen alle van richting gaan veranderen op basis van de gekozen richting.

Het paaltje krijgt
tourism=information
information=route_marker of trail_blaze
route_marker:direction= (graden, de richting waar het bordje naar kijkt)
en de andere tags die je vertellen waartoe deze routemarker behoort, tevens de andere eigenschappen.
taginfo combinations route_marker

De volgende functie:
highway=emergency_access_point
emergency_access_point:direction= (graden, de richting waar het bordje naar kijkt)
emergency_telephone_code=112
en andere mogelijk tags.
taginfo combinations emergency_access_point

Eenieder bepaald zelf in hoeverre hij de mogelijke tags er op zet.

Een preset zou helpen om een afstemming te krijgen.

ligfietser · 2020-12-19T12:26:53.000Z

PeeWee32:

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?

Aannemende dat er al een node op de weg staat met rcn_ref, dan kan je die node voorzien van een extra tag, highway=emergency_access_point met ref=#. Wat mij betreft hoef je geen extra node naast de weg te plaatsen.
Wil je specifiek tot uiting komen waar die ref bijhoort (of wanneer ref al bezet is) dan zou je kunnen denken aan ref:emergency_access_point=#. Nog simpeler en m.i. beter is emergency_access_point=#.

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?

Ja, er is een conflict. Kennelijk krijgt het lcn_ref nummer de voorkeur (er is inderdaad geen onderscheid tussen lcn_ref en rcn_ref).
Bij de Loonse en Drunense Duinen krijg je helemaal geen nummer te zien (behalve bij mijn OFM style). Dat heb ik opgelost door ref=# te renderen, de emergency pois bij Osmand wordt alleen de name=* gerenderd. Lijkt me goed om dit tzt aan Osmand te melden als we weten hoe we deze access points nu precies gaan taggen als dit ook in de wiki is vastgelegd. Dan kunnen we ook die drie posities aankaarten.

In de taginfo link die Allroads aangeeft zie ik nog een mogelijke oplossing voor het conflict lcn_ref en ref. Bij de node highway=emergency_access_point wordt ook wel network=* gebruikt (1037x al), dus in dit geval kan je network=lcn gebruiken om aan te geven dat het bij het mtb netwerk hoort. Dient het paaltje meerdere netwerken dan network=lcn;lwn etc.

Resumerend, mijn voorkeur gaat uit naar:

een losse node naast de weg
highway=emergency_access_point
network=lcn en
ref=#

Keep it simple. Dan hoef je die ook niet op te nemen in een relatie van een knoopuntnetwerk, mtb of wandelrouterelatie.

PeeWee32 · 2020-12-20T10:39:34.000Z

Martin Borsje:

Een emergency access point is niet uitsluitend voor MTB’ers die de route, in de juiste richting, volgen.
Ook voor wandelaars en wat dies meer.
Ook de hulpdiensten zullen de MTB-route niet volgen.

Een aparte node, naast de route, lijkt mij op zijn plaats.

Ik kan me hier wel in vinden.

ligfietser:

Aannemende dat er al een node op de weg staat met rcn_ref, dan kan je die node voorzien van een extra tag, highway=emergency_access_point met ref=#. Wat mij betreft hoef je geen extra node naast de weg te plaatsen.
Wil je specifiek tot uiting komen waar die ref bijhoort (of wanneer ref al bezet is) dan zou je kunnen denken aan ref:emergency_access_point=#. Nog simpeler en m.i. beter is emergency_access_point=#.

Goed te vernemen dat je er geen bezwaar tegen hebt dat een node zowel een ref als een rcn_ref kan hebben. Je voorstel om emergency_access_point=# te gaan gebruiken ipv de huidige methode spreekt mij wel aan maar ik ga er geen voorstel voor maken. Als jij of iemand anders dat wilt doen… prima.

ligfietser:

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?

Inmiddels weet ik niet of een mailtje aan Osmand wel zinvol is vwb de meer dan 3 posities. Zie verderop waarom ik dat denk.
Zoals gezegd ga ik geen nieuwe discussie aan over welke tags zo’n emergency_access_point moet hebben. En zolang zo’n discussie niet gevoerd en afgerond is hou ik het er maar op dat het blijft bij


highway=emergency_access_point
ref=*

ligfietser:

In de taginfo link die Allroads aangeeft zie ik nog een mogelijke oplossing voor het conflict lcn_ref en ref. Bij de node highway=emergency_access_point wordt ook wel network=* gebruikt (1037x al), dus in dit geval kan je network=lcn gebruiken om aan te geven dat het bij het mtb netwerk hoort. Dient het paaltje meerdere netwerken dan network=lcn;lwn etc.

Resumerend, mijn voorkeur gaat uit naar:

een losse node naast de weg

highway=emergency_access_point

network=lcn en

ref=#

Keep it simple. Dan hoef je die ook niet op te nemen in een relatie van een knoopuntnetwerk, mtb of wandelrouterelatie.

Aangezien er geen bezwaar is tegen het opnemen van zowel een lcn_ref als een ref denk ik niet dat we in jouw voorstel de oplossing moeten zoeken. (NB. Gezien je antwoord dat een rcn_ref en een ref op 1 node zouden mogen trek ik em hier even door naar de lcn_ref. )

Ik ben nog even in Osmand gedoken en mijn (voorlopige) conclusie is dat Osmand ook niet principieel tegen deze combinatie is. Er zijn lcn_ref/ref combinaties te vinden die prima renderen (binnen zo’n circeltje met blauwe rand) maar dan moeten ze wel minder dan 4 posities lang zijn. Deze bv.
Als de lcn_ref minder dan 4 posities is en de ref meer dan wordt de lcn_ref getoond binnen zo’n cirkeltje. Bv deze

En als ze beide langer zijn dan 3 posities dan worden ze als blauwe tekst getoond. Bv hier . Lubek ziet er op Osmand dan ook erg blauw uit
https://i.postimg.cc/L8H30Fr6/lubek.png

En ook op de fietskaart oogt het wat vreemd maar dit is iets dat wellicht al jaren het geval is. Voor dit punt bv geldt dat de ref minder en de lcn_ref meer dan 4 posities is. Toch wordt op de fietskaart geen circeltje getoond met de ref erin wat er m.i. op wijst dat de lcn_ref de voorkeur krijgt.

Ik snap dat een renderer de xxx_ref binnen een netwerk zo uniform mogelijk wil weergeven maar dat wordt wel lastig gezien de verscheidenheid aan aantal posities van zo’n ref.
Wellicht helpt het als we alle xxx_ref opnemen in de relatie. Dan kan de renderer kijken welke ref binnen die relatie het meest aantal posities heeft en afhankelijk daarvoor alle ref binnen de relatie een zelfde uiterlijk geven.
Gezien bovenstaande weet ik niet of het verstandig een mail te sturen naar osmand of de openfietskaart. lcn_ref met meer dan 3 posities bestaan al heel lang en het lijkt me dat dit al bekend is.

Wat mij het simpelste (en meest logische) lijkt is dat een ref binnen een lcn, rcn,lpn,lwn etc gewoon de tag xxx_ref krijgt. Zo heb ik het eigenlijk altijd gedaan en ik zie nog geen reden daar van af te wijken. De vraag m.b.t. tot de MTB routes is dan nog waar de lcn_ref geplaatst moet worden. Op of naast de weg. In NL zien we (volgens mij) dat xxx_ref op de weg geplaatst wordt. In het buitenland is dat niet altijd het geval. Aangezien de betreffende MTB routes in NL liggen ben ik geneigd deze te verplaatsen naar de weg. Voor de emergency_access_point heb ik niet een uitgesproken mening. Martin lijkt een voorkeur te hebben om ze naast de weg te plaatsen maar als ik die lcn_ref naast de weg verplaatst splitsten we dus het paaltje in 2 nodes en daar lijkt ligfietser bezwaar tegen te hebben. Ik denk dat we 3 opties hebben:

1 Eén node OP de weg met :


highway=emergency_acces_point
ref=xxx
lcn_ref=xxx

2 Eén node NAAST de weg met :


highway=emergency_acces_point
ref=xxx
lcn_ref=xxx

3 a Eén node NAAST de weg (zoals het nu getagd is) met :


highway=emergency_acces_point
ref=xxx

samen met
3b Eén node OP de weg met :


lcn_ref=xxx

Volgens mij geen van allen echt fout maar wel verstandig om zeker in NL 1 lijn te trekken

Tja… lastig allemaal. Wat vinden (ook anderen) hiervan?

Peter_Elderson · 2020-12-20T11:23:50.000Z

Mooi samengevat!
Ik ga voor 3a voor het nood-verhaal

En 3b, maar dan alleen als de punten voor het routeren van belang zijn. Dus niet voor zeg maar genummerde hektometerpaaltjes.

In het geval van deze mtb-routes zou ik dus alleen de punten een lcn_ref geven waar een routevariant gekozen kan worden.
Aangezien het niet om een echt knooppuntnetwerk gaat (echt= de knooppunten verwijzen 2 aan 2 naar elkaar voor de routering en tussenin volg je alleen de pijltjes), zou ik ook op die keuzepunten geen network_type=node_network gebruiken.

Geim · 2020-12-20T11:45:02.000Z

ligfietser:

Bij de node highway=emergency_access_point wordt ook wel network=* gebruikt (1037x al), dus in dit geval kan je network=lcn gebruiken om aan te geven dat het bij het mtb netwerk hoort.

network=lcn mag volgens de wiki niet op een node. Zie: https://wiki.openstreetmap.org/wiki/Tag:network%3Dlcn

ligfietser · 2020-12-20T12:59:32.000Z

Peter Elderson:

En 3b, maar dan alleen als de punten voor het routeren van belang zijn. Dus niet voor zeg maar genummerde hektometerpaaltjes.

Dat is nou net mijn punt, het nummer dient niet voor het routeren dus zou ik ook nooit lcn_ref daar gebruiken en al helemaal geen twee verschillende nodes voor één en hetzelfde paaltje. Maar ja, het blijkt dat we het daarover nooit eens worden dus ik laat het hierbij.
Maar als het echt niet anders kan: optie 2.

Peter_Elderson · 2020-12-20T16:56:13.000Z

ligfietser:

Peter Elderson:

En 3b, maar dan alleen als de punten voor het routeren van belang zijn. Dus niet voor zeg maar genummerde hektometerpaaltjes.

Dat is nou net mijn punt, het nummer dient niet voor het routeren

Als ik mij goed herinner waren er een paar opties in de route, een korte en een lange of een doorsteek of zo. Daar heb je een keuze. Als daar een aanwijzing staat: 4 rechtsaf, 15 linksaf, en het paaltje zelf heeft een nummer, dan vind ik die nummers van belang voor routeren. Als er daarentegen staat Grote Route rechtdoor, kleine route rechtsaf, of route A vs Route B, of “Afkorting”, dan zijn de nummers niet van belang voor routeren.
Ik weet het niet voor dit geval, maar het zou zou kunnen zijn, en andere gevallen zouden zo kunnen zijn, dus ik hou in gedachten rekening met de optie.

multimodaal · 2020-12-23T18:12:21.000Z

Peter Elderson:

Mooi samengevat!
Ik ga voor 3a voor het nood-verhaal

Eens

En 3b, maar dan alleen als de punten voor het routeren van belang zijn. Dus niet voor zeg maar genummerde hektometerpaaltjes.
In het geval van deze mtb-routes zou ik dus alleen de punten een lcn_ref geven waar een routevariant gekozen kan worden.

Ook mee eens, maar dan wel voor alle paaltjes.

Er is maar een beperkt deel van de paaltjes waar je kiest tussen routes, maar bij het allergrootste deel van de paaltjes kies je wel tussen wegen. En daarmee is de link tussen de paaltjes en de routes dus veel sterker dan bij hectometerpaaltjes langs de weg. Als hm-paaltjes verdwijnen, dan verandert dat niets aan het verloop van de route, bij de mtb-paaltjes is dat anders.

Het moeten gebruiken voor van xxN_ref’s voor navigatie-keuzen is volgens mij geen vastgelegde eis, er zijn ook voorbeelden waar ze vooral ter oriëntatie dienen (het oude gebruik van lcn_ref, en het gebruik van lpn_ref).

Maar ook in de praktijk worden de paalnummers die geen keuzes tussen *routes *geven gebruikt om te communiceren met het publiek over waar je af moet slaan, bijvoorbeeld in onderstaande berichten over een afsluiting van afgelopen juli tm september:

MTB Trailcrew Utrechtse Heuvelrug:

OMLEIDING ROUTE LEERSUM
[…] Door de werkzaamheden moet de route van LE19 (Scherpenzeelseweg) tot aan LE53 (De Hazenberg / Bergweg) dicht.
[…] De omleiding loopt over het (drukke en toeristische!) Let de Stigterpad […]

MTB Trailcrew Utrechtse Heuvelrug:

OMLEIDING LEERSUM INGEKORT
De omleiding op Leersum is wat korter geworden. Tussen LE20 (oversteek Scherpenzeelsweg) en LE35 volg je de route. Vanaf LE35 gaat de omleiding weer verder over het Let de Stigterpad

MTB Trailcrew Utrechtse Heuvelrug:

OMLEIDING LEERSUM NOG VERDER INGEKORT
Er is weer een stuk vrijgegeven na de boswerkzaamheden. Alleen vanaf LE44 is er nog een klein stukje omleiding over het Let de Stigterpad.

Het is om meerdere redenen erg fijn om die referenties in de ways te hebben, zodat je dat in je navigatie kan gebruiken.
Het lijkt ook wel een beetje op afritten op snelwegen; die krijgen ook een apart getagde node op de splitsing met de hoofdrijbaan en een motorway_link als way die hetzelfde nummer heeft.

Peter Elderson:

Aangezien het niet om een echt knooppuntnetwerk gaat (echt= de knooppunten verwijzen 2 aan 2 naar elkaar voor de routering en tussenin volg je alleen de pijltjes), zou ik ook op die keuzepunten geen network_type=node_network gebruiken.

Helemaal eens!
Het lijkt me wel goed om ook expliciet te maken dat het geen node_network is.
Mijn eerste ingeving is dus network_type=roundtrip, maar ik heb zeker geen bezwaar tegen betere voorstellen

Overigens is er in de duinen ook een netwerk waar alle genummerde palen kruisingen van routes in het netwerk betreffen, maar lslechts een deel (1/3e?) van de kruisingen van routes een genummerde paal hebben. Als je dat met de knooppuntenmethodiek wil mappen in aparte routes per verbinding, dan krijg je een gigantisch aantal overlappende variaties. Daar kwam bij mij network:type=spaghetti op

Peter_Elderson · 2020-12-23T21:23:01.000Z

multimodaal:

Mijn eerste ingeving is dus network_type=roundtrip

Hm… mijn brein heeft er moeite mee om roundtrip als een netwerktype te zien.
Ook dat er genummerde paaltjes staan waar je langs komt, lijkt mij te weinig om van een netwerktype te kunnen spreken.
Het is meer een eigenschap per route.
numbered_markers=yes of zo.

PeeWee32 · 2020-12-24T05:23:45.000Z

multimodaal:

Helemaal eens!
Het lijkt me wel goed om ook expliciet te maken dat het geen node_network is.
Mijn eerste ingeving is dus network_type=roundtrip, maar ik heb zeker geen bezwaar tegen betere voorstellen

Ik kan me deze opmerking wel voortellen. Ik heb op de talk pagina voor een andere optie gekozen. Ik zou echte KNOOPpunt routes “option node network” willen noemen. Dit om het verschil te maken met netwerken waar geen/nauwelijks keuzes zijn maar die wel nodes hebben met hun unieke referenties binnen dat netwerk. Maar er zijn uiteraard meer mogelijkheden om onderscheid te maken binnen een groep.

Peter Elderson:

Hm… mijn brein heeft er moeite mee om roundtrip als een netwerktype te zien.
Ook dat er genummerde paaltjes staan waar je langs komt, lijkt mij te weinig om van een netwerktype te kunnen spreken.
Het is meer een eigenschap per route.
numbered_markers=yes of zo.

Dat is ook weer een kwestie van definitie. Je zou ncn,rcn,lcn ook netwerktypes kunnen noemen. Maar als je daarbinnen wil differentieren tussen bv wel/geen keuzenodes dan kun je ook dat onderscheid aangeven middels tagging. Hoe je dat noemt… tja daar kun je vele kanten op. En als je KNOOPpuntnerken wil onderscheiden in “wel of geen richting bordjes naar volgende nodes” dan is ook dat aan te geven met tags. De vraag is dan alleen of we dat willen en zo ja hoe?

Voor de puristen is er dan nog wel wat werk aan de winkel. Misschien dat de komende feestdagen daar het juiste moment voor is

edit: missing quote

dvdhoven · 2020-12-24T08:03:43.000Z

PeeWee32:

[ Ik zou echte KNOOPpunt routes “option node network” willen noemen. Dit om het verschil te maken met netwerken waar geen/nauwelijks keuzes zijn maar die wel nodes hebben met hun unieke referenties binnen dat netwerk. Maar er zijn uiteraard meer mogelijkheden om onderscheid te maken binnen een groep.

Als je een nieuw network:type wilt definiëren, invoeren, moet je daarvoor een nieuwe tag/waarde introduceren.
Het is naar mijn idee geen goed idee om een bestaande waarde te gaan hernoemen.
Even concreet:
Het bestaande knooppuntnetwerk heeft network:type=node_network
Laat dat ongemoeid.
Verzin voor je nieuwe netwerk een andere waarde en gebruik die.
Nu nog eens network:type=node_network door iets anders vervangen is een grote klus met een flink afbreukrisico.
Ook moeten routers, netwerk analyse tools, etc worden aangepast.
Al met al een gigantische transitie.
Niemand zit op zo’n klus te wachten.
Temeer omdat het besef van nut en noodzaak totaal ontbreekt.

Kijk, het introduceren van network:type=node_network was keihard nodig om een ontwerpfout te corrigeren.
Er was een lang sluimerend conflict tussen echte regionale routes en knooppuntroutes en dat werd urgent omdat Duitsland, van oudsher het land van de regionale fietsroutes, steeds meer knooppuntnetwerken ging opzetten.

Nu wil je een nieuw netwerk van hulppaaltjes, what so ever, opzetten.
Prima, geen probleem, maar blijf dan van de bestaande situatie af en verzin voor die paaltjes een nieuwe waarde.

Om voor die paar MTB hulpnetwerken zo’n plusminus 100K changes en vele uren werk te gaan uitvoeren, is pure waanzin.

Als jij bij de Duitsers, Fransen, Belgen aankomt met een wijziging van network:type=node_network omdat er in Nederland een paar MTB netwerken worden geïntroduceerd, wijzen ze naar hun voorhoofd.

Peter_Elderson · 2020-12-24T08:40:18.000Z

Lijkt me niet handig als je mtb-paaltjes met lcn_ref wil aanduiden, dat je dan het hele knooppuntnetwerksysteem met nu bijna 155.000 elementen in 6 landen en met 6 transporttypes zou gaan omtaggen…

network=*n gaat inderdaad om netwerktypes, een typologie die bereik (l,r,n,i) met transportmethode (c,w,h,p,m,i) kombineert.
network:type= geeft een systeemtype, namelijk hoe de elementen aan elkaar geknoopt zijn en gebruikt worden.

Beide keuzes zijn niet onbetwist. **n was ruim voor mijn tijd in gebruik genomen, ik vond dat een gegeven paard wat ik niet in de bek ga kijken, maar ik ben wel wat gemok tegengekomen.

network:type had de kritiek dat “type” niks zegt. Je zou moeten aangeven wat voor onderscheid je daar maakt. In dit geval, welk functioneel systeem er gebruikt wordt, dus network:system of network:signing_system of zo. Maar de enige value tot dusverre is node_network oftewel knooppuntennetwerk, en dat is bedoeld om de knooppuntennetwerken op de weg in osm-tagging en groepering (relaties) eenduidig vast te leggen zodat ze weergegeven kunnen worden en voor routers, planners en gebruikers bruikbaar zijn.

Op basis van network:type=node_network zijn door allerlei toepassingen aanpassingen gedaan. Deden ze dat niet, dan veranderde er niets, deden ze het wel dan konden de knooppuntnetwerken duidelijk onderscheiden weergegeven en gebruikt worden.

(Daar staat tegenover dat rXn, wat bij ons in gebruik genomen was om “knooppuntnetwerk” te betekenen, genormaliseerd werd tot wat het overal is: regionale X-route zonder speciaal systeem. Wij hebben daar zelf al volop van geprofiteerd en landen die mede om die reden geen knooppuntnetwerken invoerden konden dat nu zonder probleem gaan doen)

Als je dat nu gaat veranderen, dan hebben ze een groter probleem, want dan verandert ineens de hele bubs en werkt het niet meer.

Wat betreft de paardrijroutes: zie https://riding.waymarkedtrails.org/#main?map=13.95876462820497!52.2507!6.5666 en scan even over Nederland: die hebben het knooppuntensysteem (nummers op de keuzepunten, je kiest daar je volgende nummer adhv je planning) duidelijk in gebruik genomen.
Het is natuurlijk mogelijk dat er nog losse routes zijn die nummertjes langs de route hebben staan, maar die vallen dan buiten het knooppuntensysteem. Laten we die dan routepunten noemen of zo.

Kanoroutes in Noord- en Zuid-Holland met genummerde paaltjes heb ik ooit op dit voor geopperd dat je ze best als “uitgeklede” knooppuntroutes kan zien, maar daar werd ik over teruggefloten. Inmiddels zijn die routes grotendeels opgenomen in vaarknooppuntennetwerken, dus de nummers zijn knooppunten/keuzepunten die naar het volgende knooppunt wijzen. Ik heb daarover uit verschillende gebieden informatie en knooppuntkaarten, en ik heb die ook in Zuid-Holland op verschillende plekken zelf gezien.
Ook daar: het kan zijn dat er nog kanoroutes zijn met genummerde paaltjes erlangs waar geen keuze gemaakt wordt en die niet naar elkaar verwijzen. De routes worden nog steeds als themaroutes aangeboden, maar ze volgen het vaarknooppuntennetwerk en ik zie nergens iets over losse nummers waar je alleen langskomt. Zie bijvoorbeeld https://knooppuntnet.nl/nl/map/canoe#dpgv56-2nsf2xt-2nsf2wj . Op andere plekken is het minder goed ingevoerd, maar ook daar gaat het niet meer om losse routes.

Voor rolschaatsen zie ik tot nu toe 1 knooppuntennetwerk, https://skating.waymarkedtrails.org/#?map=13.978343881881504!51.9628!4.3364
Andere *in-routes zie ik niet, misschien zijn ze er wel maar nog niet ingevoerd?

Kortom, waar we het in dit onderwerp over hebben is alleen maar de paaltjes langs de mtb-route(s), en dat zijn geen knooppunten/keuzepunten.

De vraag is: is lcn_ref gereserveerd voor knooppuntnetwerken, en het antwoord is: nee, niet per se, want we hebben gedefinieerd dat knooppunten óók getagd moeten zijn met network:type=node_network.
Uitstapje: nog steeds is het zo dat we knooppuntnetwerken met rn en rn_ref taggen, maar de ontwikkelingen in Duitsland en Frankrijk gaan in de richting van (ook) ln/ln_ref knooppuntnetwerken. Men beschouwt de knooppunten en node2node-routes als lokale dingen, ongeacht het bereik van het netwerk, en daar zit ook wel wat in.

Dan de vraag of het handig is om voor een *cn-route genummerde intersecties te mappen waar wel een richtingwijziging is maar geen keuze. Ik zou zeggen, alleen als het voor het volgen van de routes nodig is. Dat lijkt mij niet het geval; je volgt het pad op basis van de pijlen, en daarbij kom je langs nummers, maar die nummers bepalen niet de route. De paaltjes zelf worden inclusief nummer gemapt voor plaatsbepaling bij bv emergency.

Ik heb er geen probleem mee als men daar anders over denkt, maar het heeft bij mij dan geen invoerprioriteit, en ik vind het zeker geen reden om het hele knooppuntensysteem te gaan heroverwegen!

Peter_Elderson · 2020-12-24T08:54:00.000Z

dvdhoven:

Als jij bij de Duitsers, Fransen, Belgen aankomt met een wijziging van network:type=node_network omdat er in Nederland een paar MTB netwerken worden geïntroduceerd, wijzen ze naar hun voorhoofd.

Aantekening: veel mensen wijzen zowizo al dan niet beleefd naar hun voorhoofd als het over knooppuntnetwerken gaat. Ze denken vaak in termen van routeren van A naar B; dat het niet om A->B gaat maar om de weg die je wil afleggen gaat er al moeilijk in, maar dat je dan onderweg ook nog eens allerlei nummertjes wil ‘aantikken’… voorhoofd!

PeeWee32 · 2020-12-24T09:16:58.000Z

dvdhoven:

Als jij bij de Duitsers, Fransen, Belgen aankomt met een wijziging van network:type=node_network omdat er in Nederland een paar MTB netwerken worden geïntroduceerd, wijzen ze naar hun voorhoofd.

Ho wacht ff. Ik bedoelde hier wat anders mee. Er zijn (ook buiten NL) routes met **n_ref die niet voldoen aan de definitie van een knooppunt netwerk met keuze. Dus kan de term node_network verwarrend werken als we dat alleen voor KNOOPpunt netwerken gebruiken. Dat de tag “network:type=node_network” alleen voor KNOOPpunt nerwerken (met keuze) gebruikt wordt is wat mij betreft jammer maar niet echt een probleem zolang maar voor iedereen helder is dat dat zo is. Dus expliciet benoemen lijkt me verstandig. Het omgooien van een taggingsschema is niet mijn opzet. Vandaar ook de laatste zijn.

PeeWee32:

Maar er zijn uiteraard meer mogelijkheden om onderscheid te maken binnen een groep.

Geim · 2020-12-24T09:19:43.000Z

Peter Elderson:

Dan de vraag of het handig is om voor een *cn-route genummerde intersecties te mappen waar wel een richtingwijziging is maar geen keuze. Ik zou zeggen, alleen als het voor het volgen van de routes nodig is. Dat lijkt mij niet het geval; je volgt het pad op basis van de pijlen, en daarbij kom je langs nummers, maar die nummers bepalen niet de route. De paaltjes zelf worden inclusief nummer gemapt voor plaatsbepaling bij bv emergency.

Helemaal mee eens, en dat lijkt ook weer het meest op de originele vraag van Mika.
Dan vind ik Jillis’ zijn voorbeeld zo slecht nog niet: https://forum.openstreetmap.org/viewtopic.php?pid=787596#p787596

PeeWee32 · 2020-12-24T16:53:20.000Z

Peter Elderson:

Ook daar: het kan zijn dat er nog kanoroutes zijn met genummerde paaltjes erlangs waar geen keuze gemaakt wordt en die niet naar elkaar verwijzen. De routes worden nog steeds als themaroutes aangeboden, maar ze volgen het vaarknooppuntennetwerk en ik zie nergens iets over losse nummers waar je alleen langskomt.

Maar dat is juist het mooie van zo’n forum. Je kunt mekaar hierbij helpen. En Multimodaal is niet de enige die meerdere modaliteiten gebruikt. Ik ben naast (lig)fietser, MTB-er, wandelaar ook kanovaarder maar veel minder professioneel en frequent . Dus ook een soort van multimodaal.

Zie hier een voorbeeld *van een kanoroute waar wel nummers staan maar waar je niet/nauwelijks keuzes hebt en al helemaal geen bordjes die je de richting wijzen.

En hier een voorbeeld van die bebording al moet ik toegeven dat ik die wat beter had kunnen fotograferen. Maar er zijn er meer. Zie ook bv deze site.

*(Disclaimer: dit overpass kaartje is nog in ontwikkeling dus wellicht werkt dit over een tijdje niet meer )

multimodaal · 2020-12-24T20:03:13.000Z

dvdhoven:

Het bestaande knooppuntnetwerk heeft network:type=node_network
Laat dat ongemoeid.
Verzin voor je nieuwe netwerk een andere waarde en gebruik die.

Daar ben ik het er helemaal mee eens, er is door meerdere mensen hier echt heel mooi werk geleverd de invoering van *network:type=node_network , zowel met het voorstel als met de aanpassing van de data. Daarmee is inderdaad een oude ontwerpfout opgelost (schaalniveau en type netwerk liepen eerst door elkaar in network=)

Peter Elderson:

multimodaal:

Mijn eerste ingeving is dus network_type=roundtrip

Hm… mijn brein heeft er moeite mee om roundtrip als een netwerktype te zien.

Gaat jouw brein er misschien nog van uit dat woorden in OSM dezelfde betekenis hebben als in de normale wereld ?

Ik heb zelf al een soort mappersdeformatie waardoor ik niet altijd meer opkijk van een tag-combinatie als carriage=yes; horse=no, voor die wagen mag gewoon een paard, want met horse bedoelen we geen paard, maar ruiter…
(net zoals we met bicycle geen *fiets *bedoelen, maar cycling)

In dit geval heb je denk ik gelijk als je bedoelt dat een paar losse rondjes niet echt voldoen aan een netwerk in de netwerktheorie, maar in OSM wordt dat woord al lange tijd in een bredere betekenis gebruikt.

Neem bijvoorbeeld wandelroutes in de tijd voor de wandelknooppunten. Een klein lokaal rondje zonder verbindingen met andere routes map je met route=hiking/foot ; network=lwn
Dat wordt al gebruikt sinds 2009 (link)

En in deze linkuit 2012 zie je ook dat met *lcn *wordt bedoeld:

Local walking network: used for small local walking routes
Regional walking network: used for walking routes that cross regions

Dus knooppunten of keuzepunten zijn niet vereist in het “netwerk”. Dat netwerk kan ook kan bestaan uit losse rondjes of heen-en-weertjes die elkaar niet raken. Binnen de brede groep “netwerken” is er ook een specifieke groep “knooppuntnetwerken”. Met de invoering van de key network:type= kan nu heel mooi het onderscheid tussen knooppuntnetwerken en andere type routes in het netwerk (in de brede OSM-zin) worden gemaakt.

Als het niet de bedoeling was geweest om andere type routes dan knooppuntroutes te duiden in network:type=* dan had beter *node_network=yes/no *kunnen worden gekozen, want anders zou *network * in *network:type * heel iets anders betekenen dan hetzelfde woord in local walking network. Maar zoals gezegd geeft network:type juist een mooie kans om voor alle type toutes specifiek aan te geven wat voor soort route het betreft.

Ook dat er genummerde paaltjes staan waar je langs komt, lijkt mij te weinig om van een netwerktype te kunnen spreken. Het is meer een eigenschap per route.
numbered_markers=yes of zo.

Dat is inderdaad een eigenschap die een route kan hebben, zou een nuttige toevoeging kunnen zijn op network:type=wieverzinterietsbetersdanroundtrip.

Voor nu: fijne kerstavond allemaal!

Peter_Elderson · 2020-12-24T21:21:34.000Z

multimodaal:

Neem bijvoorbeeld wandelroutes in de tijd voor de wandelknooppunten. Een klein lokaal rondje zonder verbindingen met andere routes map je met route=hiking/foot ; network=lwn
Dat wordt al gebruikt sinds 2009 (link)

En in deze linkuit 2012 zie je ook dat met lcn wordt bedoeld:

Local walking network: used for small local walking routes
Regional walking network: used for walking routes that cross regions

Dus knooppunten of keuzepunten zijn niet vereist in het “netwerk”.

Helemaal juist! In die goeie ouwe tijd werd met netwerk dus iets bedoeld vergelijkbaar met het wegennet/routenet, met een hierarchie van locaal tot internationaal en routenummers. Dat kun je ook nog terugvinden als waarschuwing dat het niet meer de bedoeling is om *cn_ref aan een serie wegen te hangen als routenummer. Zelfde beweging als bij gewone wegen.

In network:type is het functionele systeem bedoeld. Verwarrend, niveaus en recreatiesoorten en functionele systemen door elkaar, maar ja, zo is het nu. Roundtrip is nog weer iets anders, namelijk topologie. Roundtrips worden op allerlei manieren aangegeven, er zit volgens mij niet een duidelijk systeem in, anders dan: je begint, je volgt de pijlen of kleurenpaaltjes of kleurstreepjes of het bijbehorende symbool waar dat nodig is, en dan kom je bij het eindpunt uit, en dat is dan toevallig hetzelfde punt als waar je begon. Net zoals bij een LAW of LF, alleen die eindigt op een ander punt dan waar je begon. SP’s zijn dan weer vaak roundtrips, alleen die je daar wat langer over.

Een ander network:type, daar moet MI wat meer systeem achter zitten. Bijvoorbeeld de plannen voor functionele snelfietspadennetwerken rond grote steden, voor fietsforenzen. Ik heb er (als plannen) gezien die met genummerde routes (spaken en en ringen) werken met daarop afgestemde bewegwijzering op de snijpunten, waardoor je via de snelste/beste voorkeursroute naar je bestemming kan fietsen, dat zou ik echt wel een ander network:type noemen. Je route gaat dan bestaan uit afwisselend spaak- en ringsegmenten, als je die rijdt kom je het vlotst bij je bestemming aan.

Dat is dan geen knooppuntennetwerk, al zijn er ook keuzepunten en routes, maar meer een ring-spaak-netwerk, of een segmenten-netwerk, waarbij de keuze op een hoekpunt niet gegeven wordt als bestemming maar als route-segment-ref.

Terugkomend op de kanoroutes. Als de route een lijn of een ring is waarbij je alleen telkens naar het volgende schild/bord/paaltje moet varen, dan is dat MI geen netwerksysteem. De nummers doen er dan eigenlijk niet toe, als ze er niet staan (alleen de kenmerkende wegwijzers) dan gaat het net zo goed. Dat is dan een gewone lpn of rpn zonder node_network, ook al zijn er nummers. Van mij mogen die nummers rustig als lpn_ref getagd worden, alleen zoals gezegd heb ik dat ooit gesuggereerd maar werd toen teruggefloten. Maar dat was vóórdat network:type werd ingevoerd.

De kanonetwerken in het westen van het land (en dacht ik Gelderland Rivierenland en West-Betuwe ook?) zijn omgevormd naar knooppuntnetwerken.
De voorbeelden bij Meppel zijn nog gewone routes met genummerde richtingaanwijzers, tevens handige oriëntatiepunten denk ik. Zotezien vergelijkbaar met de mtb-routes met genummerde paaltjes. Zouden ze daar ook omslaan of overstag gaan (hahhah, grappig gevonden hoor), nu fietsen en wandelen ook daar helemaal doorgeknoopt zijn en het westen (Westfriesland is er vlakbij!) ook voor varen helemaal verknoopt is?
Het watergebied leent zich er denk ik wel voor.

PS ik zag dat in Polder Mastenbroek een kanonetwerk is gemaakt met gekleurde routes die elkaar her en der kruisen, maar zo te zien zonder genummerde keuzepunten.