Paalnummers MTB-route en aanvullende informatie toevoegen

Communities Nederland (Netherlands)
141

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

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

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:

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.

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

Voor nu: fijne kerstavond allemaal!

142

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.

143

Hier kan ook ik me helemaal in vinden. Dat wellicht een beter naam dan node_network hadden kunnen kiezen is dan misschien wel zo maar niet echt een probleem zolang iedereen maar weet dat we daar knooppunt netwerk mee bedoelen. De introductie van de key network:type biedt nu wel de mogelijkheid om onderscheid in typen te maken en dus ben ik ook blij met het werk dat verzet is om dit mogelijk te maken.

Wat mij betreft een goede conclusie. Wellicht ten overvloede merk ik op dat de tag network:type zowel voor de route(relatie) als voor de **n_ref gebruikt wordt. Maar welke typen onderscheiden we en hoe gedetailleerd willen we verschillen tot uiting brengen in deze waarde?

Even een brainstorm (en dat betekent dat er volop op geschoten kan worden :wink: )

Wat is de overeenkomst tussen de netwerken die ik momenteel voor ogen heb?
Het zijn allen netwerken voor recreative doelen wat al aangegeven is met de tag network = rcn, lwn etc. In de key network:type hoeft dat dus niet nogmaals kenbaar gemaakt te worden maar het geeft wel aan dat ik niet aan het nadenken ben over types anders dan voor recreatieve doelen.

De overeenkomst is dat ze allen referenties hebben die binnen het netwerk uniek te identificeren zijn. (veelal nummers). Mijn idee is dat dit de groep is waarvoor we waardes zoeken voor de key network:type.

Om een enigszins limitatief lijstje te maken van de values van network:type helpt het om de attributen te benoemen waarop we onderscheid kunnen/willen maken. Ik noem er een paar:

1. Wel/geen keuze per referentiepunten
2. Wel geen richting aangegeven bij de ref (dus bijvoorbeeld bij knooppunt 1 staat dat je links moet naar 2 en rechts naar 3) 
3. Wel geen richtingsbordjes tussen de nodes in (al dan niet met de refentie waar de richting naar verwijst)
4. Eén of 2 richtingen (Veel, zo niet alle MTB routes zijn in 1 richting)
5. Roundtrip/geen roundtrip
6. Fijnmazigheid: Fiets/wandelknooppunt netwerken zijn erg fijnmazig maar wiel/spaak netwerk al weer veel minder. (maar waar ligt die grens?) 
7. Vul aan

Van een aantal atributen is het niet nodig deze in de value van de key network:type op te nemen. Rounttrip=yes/no en oneway=yes/no kun je ook als losse tag opnemen in de relatie. Voor een aantal anderen kunnen we een nieuwe (of bestaande?) tag opnemen in de relatie waardoor deze niet tot uiting hoeven te komen in de value van network:type.

Als we een heel grof onderscheid in de typen willen maken dan kunnen we dat doen op het wel/geen keuze hebben bij de refs. Dat zou dan de volgende indeling kunnen worden

network:type=node_network (=knooppunt netwerken met keuze)
network:type=no_option (of iets anders) (netwerken waar het meerendeel van de ref geen keuze heeft)

Iets zegt me wel dat dit een te bepekt lijstje is. Ook omdat het ontbreken van de “network:type=no_option” geen verschil zal maken. Immers alle netwerken zonder “network:type” zijn netwerken zonder keuze opties.
OK … zomaar wat gedachtes op de vroege eerste kerstdag.

Een groot voordeel van het invoeren van network:type is dat het voor mappers veel eenvoudiger/eenduidiger wordt om de ref’s te taggen. Als het netwerk een **n is en binnen dat netwerk komen unieke refs voor dan kun je die gewoon taggen als **n_ref ongeacht wat voor type netwerk dat is. Indien gewenst kan de network:type toegevoegd worden op de ref en op de relatie (voor het geval die daar ontbreekt) . Als iemand alleen de lcn_ref wil zien van een echt knooppunt netwerk dan hoeft er alleen naar network:type gekeken te worden.

144

Dit klopt, met één aantekening: De nummers (of labels) zijn niet per definitie uniek binnen het netwerk. Kan wel, maar is niet vereist. Sterker nog, soms zijn er hele klusters met hetzelfde nummer.

Dit klopt, met één aantekening. Los van hoe de nummers gebruikt worden, kun je aangeven dat ze bedoeld zijn voor een bepaalde soort recreatie. (Alhoewel je dat ook niet altijd kan zien als je het niet weet… verrassend veel mensen hebben die nummersystemen nooit opgemerkt of er niet bij nagedacht waar ze voor zijn, laat staan dat ze verschillen zien! Maar goed, mappers zijn wel iets bewuster bezig denk ik.)
Maar of het l, r, n, of i is, dat kun je niet aan één nummer zien.

network:type gaat MI over het functionele netwerk, dat wil zeggen niet over uiterlijke kenmerken, maar hoe het werkt voor planning/routering.
Dan is het dus niet doorslaggevend of je nou bij een genummerd punt een volgend nummer moet kiezen of bepalen welke kleur je moet volgen om naar het volgende keuzepunt te komen; het basissysteem is dat je per keuzepunt de weg kiest naar een volgend keuzepunt, en dat je daarbij een voorgeschreven tussenroute volgt, op welke manier die ook aangegeven is. Een geplande route bestaat dan uit een reeks punten verbonden door routesegmentjes. Tweezijdigheid is denk ik wel een belangrijk kenmerk.

De klassieke route gaat van beginpunt naar eindpunt, klaar. Ook daar geldt dat het op duizend-en-een manieren kan zijn aangegeven. Een roundtrip werkt precies zo, alleen kom je op hetzelfde punt uit als waar je begonnen was. Dat kan tweezijdig of eenzijdig zijn. Te weinig om het een apart systeem te noemen denk ik.

Een route of roundtrip met genummerde richtingwijzers is nog steeds gewoon een klassieke route. De nummers zijn misschien handig ter oriëntatie of voor noodlokalisatie, maar als ze ontbreken kan je de route net zo goed volgen. Dus je kan de nummers taggen maar een ander netwerksysteem is het MI niet.

Als het zo zou werken als bij zo’n paardenbak voor schoonrijden, dat er rondom nummers staan waarmee een route uitgezet wordt van nummers die je met je voertuig achter elkaar moet aandoen, dan zou je wél een ander netwerksysteem hebben.

En het beschreven vooralsnog theoretische ringen-spaak-systeem (spinnewebsysteem) werkt ook echt anders.

145

PS. Het zou volgens mij wel goed zijn om mtb als type recratief transport eens principieel beter te onderscheiden. Ik ben te vaak wandelend over een mtb-route gestuurd, en zelfs met de gewone fiets (met trekkersbagage). Avontuurlijk, dat wel, ik vergeet het nooit meer…

146

De doelt bv op dit soort punten waar een nummer meerdere keren voorkomt. Tja daar heb je wel een punt. Blijft lastig die definities.

Veelal zie je bij de nummers en soms/vaak ook bij de routeaanwijzers tussen punten in wel een symbooltje dat aangeeft waar het voor bedoeld is. (fiets, hoefijzer, kano, driehoekje met 2 bolletjes voor MTB). Ik kan ook aan die nummers niet zien of het l, r, n, of i is. Ik weet ook niet of het onderscheid altijd zo helder is. Heb me er eerlijk gezegd ook nooit in verdiept.

Ik neem aan dat je hiermee niet algemeen over network:type hebt maar specifiek over network:type =node_network. Toch?

Als als je met tweezijdigheid bedoelt dat ie in 2 richtingen te volgen is dan vind ik dat ook een belanrijk kenmerk. M.i. is dat met een tag op de relatie aan te geven (oneway=yes)

Op de route relatie staat route=mtb maar daar ben je waarschijnlijk nog niet mee geholpen omdat een MTB route vaak ook deels over wegen/paden gaat waar je ook mag fietsen/wandelen. Enige tijd geleden heeft Multimodaal de tag geintroduceerd voor die stukken singletrack waar andere recreanten niets te zoeken hebben: bicycle:designated:type =mtb. Ben bij mij in de buurt zie ik voor dat soort stukken singletrack dat men zelfs een C16 bordje op het MTB paaltje hebben toegevoegd. Dan zet ik het op foot=no. Dit soort tags helpen ook de andere recreanten maar ik vermoed dat er nog wel heel wat werk verzet moet worden om dat in NL allemaal te regelen. (in het veld en daarna in OSM)

Even een zijstapje.

Ik moet wel zeggen dat ik niet verwacht had dat dit onderwerp zoveel zou losmaken. En ik moet ook toegeven dat ik door dit onderwerp wel een beetje anders ben gaan kijken naar deze paaltjes. Want laten we nu wel wezen ,als we het plaatje zien wat hier de aanleiding voor deze post was:

LDD-groene-MTB-route-mamazetkoers.jpeg1600×1200 493 KB

Is dat nu echt een emergency_access_point? Op basis waarvan? Als ik er nu naar kijk zie ik een code op een paaltje. Als ik wat verder kijk zie ik dat dit een code is binnen de MTB route en dus m.i. een referentie. En aangezien de MTB route een lcn is vind ik dat dit als “lcn_ref =M07” getagd zou kunnen worden. Maar op basis waarvan zien we het als een emergency_acces_point is? Ik zie nergen dat er 112 gebeld moet worden. Ik begrijp als MTB-er de drang wel om het te taggen als emergency_access_point maaar met die zelfde logica zou ik ook ieder hectometer paaltje zo kunnen taggen maar dat schiet zijn doel voorbij. Dus puur obv wat ik zie zou het m.i. geen emergency_access_point zijn.

Maar goed ….zo zag ik het destijds (en velen met mij) niet.

Best een aparte constatering :wink:

147

Ik denk inderdaad dat de tekst “M07” totaal niets met een emergency_access_point van doen heeft:

  • er staat geen telefoonnummer
  • er staat geen tekst van dien aard
  • als het wel zo zou zijn: alleen voor MTB’ers, niet voor joggers, wandelaars etc.?
  • ik vermoed zo maar dat de hulpdiensten geen lijst hebben met deze refs

Het lijkt mij dat dit eerder een interne referentie is van de ATB-club die de route uitzet en onderhoudt.

148

Bij het originele plaatje zag ik geen noodzaak om het nummer te taggen - allerlei dingen op de weg zijn genummerd, bv lantarenpalen, handwegwijzers, paddestoelen, dukdalven, en die worden zelden in OSM gezet. Dus de vraag is dan waarom zou je het in dit geval doen, en toen kwam dat noodlokalisatieverhaal. met andere voorbeelden waarbij het duidelijk wél een emergencypunt is.
En naar de andere kant, genummerde routepaaltjes waarbij de nummers toch meer met het (in dit geval) varen verbonden zijn. Want bij het mtb-verhaal volg je vrij duidelijke sporen en paden en kom je er vlak langs, terwijl de afstanden bij varen meestal groter zijn en er op grotere wateroppervlakten meestal geen duidelijke sporen zijn. Maar voor het vinden van de route heb je de nummers niet echt nodig, wel duidelijke aanwijzers.

Als de nummers dan heel prominent zijn, of een duidelijk bijkomend doel hebben, dan is het niet gek om ze te willen mappen.
Het eerste voorbeeld zou ik dat niet doen: geen duidelijk extra doel en niet nodig voor het plannen/volgen van de route. Vgl paddestoelen met nummer. Maar het staat op de route dus als iemand het wil mappen als routepunten, prima.

Een later voorbeeld had 112 erbij en het nummer stond apart van de richtingpijl. Dat is dus emergency, waar al een tagging voor bestaat, toe te passen op het object zelf.

Het voorbeeld van de kanoroute met manshoge nummers op de tweezijdige richtingborden, daar lijkt het mij vooral met oriëntatie op de route verbonden. Maar voor het routeren hadden het ook ongenummerde reuzepijlen kunnen zijn. Ook hier: als iemand het wil mappen, prima.

Met knooppunten zoals in knooppuntnetwerken heeft het in MI beide gevallen niets te maken.

**n_ref kan gebruikt worden voor niet-knooppuntennetwerken, al zijn er mogelijk nog wel toepassingen die naar r*n_ref kijken om te bepalen of het om een knooppuntennetwerk gaat.

Een **n_ref met een network:type=node_network tag je op de intersectie: het punt wat de routesegmenten verbindt.
Een losse **n_ref hebben we dacht ik geen harde afspraken over of dat op het routepunt of op het dragerobject naast de route komt. Kan denk ik allebei, en het kan ook samenvallen.

149

Het mooie van de tag network:type=node_network is dat je deze op de node (**n_ref) en op de relatie kunt zetten. En dat is zeker in NL veel gebeurd. Dat maakt het vrij eenvoudig om onderscheid te maken tussen **n_ref die WEL en die NIET onderdeel zijn van een knooppunt netwerk. Ik zie 3 methodes.

  1. Rechtstreeks op de **n_ref node. Is er een tag network:type=node_network dan is het een knooppunt **n_ref
  2. Indirect door te kijken of de **n_ref node op een weg (way) ligt die onderdeel is van een netwerk relatie (**n) met de tag network:type=node_network .
  3. Indirect door alle **n_ref nodes op te zoeken die opgenomen zijn in een netwerk relatie (**n) met de tag network:type=node_network . (dus ongecht of de **n_ref op of naast de weg geplaatst is)

Hieronder wat overpass turbo voorbeelden van deze 3 methodes.

**1.Rechtstreeks op de **n_ref node **
Wel knooppunt ref (voornamelijk rcn_ref en rhn_ref)
http://overpass-turbo.eu/s/11BI

*Geen knooppunt ref: (voornamelijk MTB, kano en wandel *n_ref)
http://overpass-turbo.eu/s/11BJ

2. Indirect via de way
Wel knooppunt ref
**n_ref nodes op wegen die opgenomen zijn in een knooppunt netwerk relatie (**n) (network:type=node_network). Wederom voornamelijk rcn_ref en rhn_ref omdat het daarvoor gebruikelijk is de **n_ref op de weg te plaatsen i.p.v. ernaast. En de wegsegmenten maken op hun beurt weer onderdeel uit van een relatie.
https://overpass-turbo.eu/s/11BK

Geen knooppunt ref
Hier die **n_ref die onderdeel zijn van wegen die opgenomen zijn in een relatie (**n) die zelf geen knoopunt relatie is. (m.n. kano route)
https://overpass-turbo.eu/s/11BP

NB: bij de volgende bevraging vind je de lcn_ref van de MTB route niet omdat deze lcn_ref niet OP maar NAAST de weg zijn geplaatst.
https://overpass-turbo.eu/s/11BO

**3 indirect via de netwerk relation (n)
Wel knooppunt ref:
**n_ref die onderdeel zijn van een netwerk relatie (**n) met de tag “network:type=node_network”. Weer mn rcn_ref en rhn_ref omdat het voor knooppunt netwerken gebruikelijk is de ref op te nemen in een relatie.
https://overpass-turbo.eu/s/11C2

*Geen knooppunt ref: *
**n_ref die onderdeel zijn van een netwerk relatie (**n) zonder de tag “network:type=node_network”. (voornamelijk mtb en een beperkt aantal wandel knooppunten.)
https://overpass-turbo.eu/s/11C4

Het lijkt erop dat de echte knooppunt routes en hun **n_refs uniform getagd zijn maar dat er bij de niet-knooppunt routes verschillende verschijningsvormen zijn. De **n_ref is soms OP maar soms ook NAAST de weg geplaatst. En bij de ene relaties is de **n_ref WEL opgenomen en bij de andere NIET. Ik denk dat er hier nog wat te uniformeren valt.

150

Ik weet niet of dat persee nodig is?

Ik weet wel dat je het niet makkelijk internationaal uniform gaat krijgen. En dat vind ik inmiddels wel een overweging, want het spreidt zich nu behoorlijk internationaal uit.

151

Das een goeie vraag. Ik weet het ook niet en ik was ook niet van plan om hier momenteel een actie voor op te tuigen. De echte knooppunt netwerken zijn nu behoorlijk goed gedocumenteerd en goed te onderscheiden van de rest. Zolang er voor de niet knooppunt relaties verschillende manieren van taggen blijven bestaan is het voor een data consumer iets lastiger maar nog steeds te doen. Ik zou het wel jammer vinden als bv binnen de kano netwerken verschillende manieren van taggen gaan ontstaan. Dit dan puur uit consistentie overwegingen.

Mocht ik of iemand anders ooit een poging doen om hier internationaal afspraken voor te maken dan helpt het hopelijk om delen van dit draadje nog eens na te lezen.

152

Voor mij is de informatie over kanoroutes en -netwerken te wisselend en onduidelijk over bv hoe recent het is en wie het beheert, dat ik daar niet aan begin. De paar kanoknooppunten die ik vanaf de wal gezien heb (omgeving Schipluiden) stonden al goed in OSM.

153

Waarom heb je dan toch alle kilometer bordjes van de MTB-route Sleenerzand gemapped?

https://www.openstreetmap.org/changeset/96713722#map=14/52.8175/6.7714&layers=N

154

Ik begrijp niet wat je bedoelt. Ik heb bij geen van die nummers een “bel 112” oid gezien en dus ook niet gemapt als emergency_access_point gemapt maar alleen als lcn_ref van deze lcn.

En de reden waarom ik die map is omdat zo’n nummer in een bosgebied kan helpen bij hulp bij ongevallen. Met een MTB zeker niet denkbeeldig. Mijn MTB-maatje ging daar woensdag j.l. hard onderuit maar hij belande gelukkig ik de blubber en mankeerde niets. Bij een ernstig ongeluk had ik kunnen melden tussen welke nummers de plek des onheils was. Ik sluit niet uit dat de meldkamer ook deze nummers heeft en zo niet dan kan het hulpverleners ter plekke helpen om de juiste plek te lokaliseren.

155

Het is wel een beetje vreemd dat het losse punten zijn zonder objecttype, zonder hoofdtag, met alleen een lcn_ref. Wij weten nu hier waar het over gaat, maar voor de rest van de wereld moet dit een kompleet raadsel zijn.

156

Een lcn_ref wordt gebruikt om een node in een node netwerk aan te geven zie: https://wiki.openstreetmap.org/wiki/Key:lcn_ref Deze MTB route is geen node netwerk (dan had er wel network:type=node_network bij gestaan) en de paaltjes die jij een lcn_ref hebt gegeven zijn gewoon kilometerpaaltjes, die aanduiden welke afstand je al hebt afgelegd.

Ze zijn inderdaad niet getagged als emergency_access_point, maar je hebt ze wel om die reden getagged, gezien je verhaal. Je verwacht dus ook dat ze zo gebruikt zullen worden.
Overigens zet ik er grote vraagtekens bij of deze nummers bij de meldkamer bekend zijn en gezien het kilometerbordjes zijn staan ze ook gewoon midden in het bos naast een single track. Hoe denk je dat dit de hulpverlener in het bos zou kunnen helpen?

Edit: Typo

157

Zijn het Km-bordjes? Ik dacht van niet, de afstanden lijken te verschillen, maar ik kan die kronkellijnen niet goed inschatten. Ik dacht dat het genummerde richtingaanwijzers zijn.

158

Ga er nou niet vanuit dat die paaltjes bij de hulpdiensten bekend zijn of worden en het zijn ook geen fietsknopen of netwerkknopen.

Niet alles kan en behoeft getagd te worden.

159

Nee, zijn daadwerkelijk kilometer bordjes. Controleer maar op brouter.
Richtingaanwijzers zijn het zeker niet, omdat het bekende MTB teken (3 balletjes) ontbreekt en ze niet structureel voor een afslag staan.

160

Inderdaad, komt ook al commentaar uit het veld: https://www.openstreetmap.org/note/2482791#map=15/52.0842/5.3430&layers=CN

Edit: quote toegevoegd