Routes gebruik *=designated t.o.v. permissive

Bepalend is de bebording bij binnenkomst gebied of deelgebieden van een eigenaar (bebording art.461).
Daar staan de regels voor gebruik op, een eigenaar kan ten alle tijden een deelgebied afsluiten. Ondanks dat daar een gemarkeerde route loopt.
Op bebording staat waar een vervoersvorm mag komen, zo worden termen gebruikt als bijvoorbeeld: mtb-paden, ruiterpaden, fietspaden. Terwijl in het gebied het niet als zodanig wordt aangegeven, men ziet dan route markeringspalen.

Eigenaren kunnen ten alle tijden deelgebieden afsluiten, permissive.
Het gaat mij om de combinatie designated en permissive voor een vervoersvorm.

Ik zie dan ook dat op juridisch openbare wegen (wegenlegger) *=designated wordt neer gezet, dit alleen op basis van routemarkering.

Ja, zeker. Maar je tagt per weg de access. Alleen als de hele route onder de designation valt (dwz er staat bijvoorbeeld een bord dat fietsen op het terrein mag, maar alleen op het fietspad; of een terrein waar alleen wandelaars in mogen met aanvullend “op de paden blijven”.), en dat voor de gehele route en als er meerdere delen zijn voor alle delen van de route, dan zou je dat kunnen aangeven met designated op de route.
Maar dat is tegelijk overbodig want dan zijn horen de afzonderlijke wegdelen al designated te zijn.

mtb-routes zijn vaak designated dmv mtb-bordjes, terwijl ze ook wegen bevatten waar ze wel opmogen maar niet speciaal voor mtb’s. Mtb’s vallen denk ik nog onder route=bicycle?
Ik kan me dan voorstellen dat je dan route=bicycle + mtb=designated op de routerelatie zet.

Dit om aan te geven, dat een eigenaar zomaar een stuk afsluit zonder officiële verkeersborden te gebruiken.

O.a. om het hier geschetste probleem (een “way” kan zowel yes/designated zijn als permissive) vind ik “permissive” geen fijne waarde als access value. Het mag wat mij betreft afgeschaft worden maar ik vrees dat dit een achterhoede gevecht gaat worden. (En dit dan nog even los van een discussie of het op een route getagd zou moeten worden)

Ik zie access=desire

Een mapper, die zowel op het juridische en feitelijke openbaarheid *=designated zet op alle highways.
Op basis van een route.

Dan vraag je je af, wat is correct, dit ook gezien dat ik aan een andere preset voor JOSM werk.
Is een tag combinatie in elke situatie correct.
Zowel bij juridische als feitelijke openbaarheid, het permissive aspect.
Zie ook image eerdere post G11 in het feitelijk openbare, zo ook G12a.

Helaas is er slecht zicht op welke wegen tot het juridische openbare behoren. Vooral op de scheiding.

okee, dus het gaat niet om designated taggen op een routerelatie, maar designated taggen op de wegen in de routerelatie, omdat de wegen in een (inderdaad designated, maar met te grove vervoerswijzen) route zitten.

Dat is onjuist, omdat een route over allerlei wegen kan gaan, met allerlei toegangen en beperkingen. Voetgangers kunnen bv tegen het verkeer inlopen, of aan de ‘verkeerde’ kant van de weg. Of fietsers gaan over een weg waar use_sidepath opstaat. Of de weg is beperkt open, maar dat zie je niet aan de route.
En er kunnen, nee zullen, fouten in routes zitten, en dan kan je je toch echt niet op beroepen als je toegangsverboden negeert.

De access=designated moet op de wegen zelf gebaseerd zijn, en de relatie geeft die niet.
Je kan hooguit zeggen, als ik een fietsrelatie afleg, dan heb ik een goede kans om veel designated fietspaden tegen te komen - in Nederland. Maar de bevestiging moet van de weg komen, niet uit de relatie.

Nog een voorbeeld: een paardenroute gaat waarschijnlijk over ruiterpaden, maar ook over voetpaden, tracks, fietspaden, stukken gewone weg, bruggen. Die kan je niet allemaal designated gaan taggen.

Dat is mijn mening!

1 Like

Ben het eens met Peter, als je =designated al zou kunnen afleiden uit het enkele feit dat een highway lid is van een routerelatie met route= , dan is er ook geen noodzaak om die tag op alle highway’s te zetten. Door die tag zo algemeen te gebruiken verlies je inderdaad ook het zicht op andere onderscheiden die met access=* worden aangegeven (yes vs permissive)

Het grappige is dat oorspronkelijk de access-key maar 1 vraag beantwoorde, namelijk: wat is de juridische soort / grondslag van de toegang:

Eerste versie van de access-wiki :
https://wiki.openstreetmap.org/w/index.php?title=Key:access&oldid=3772#Core_values

image

image

Het is rommelig geworden toen later allemaal waarden aan access=* zijn toegevoegd die eigenlijk een andere vraag beantwoorden, zoals “welke groepen mogen wel niet” (access=forestry) of “is het pad specifiek voor deze groep aangewezen” , “moet je een vergunning hebben” etc.

Extra rommelig werd het toen de specifieke waarde public (je hebt een recht om ergens te komen dat een gorndeigenaar niet zomaar kan intrekken" is vervangen door “access=yes”, dat heel algemeen klinkt , maar in OSM een hele specifieke betekenis heeft

Huidige versie access-wiki
https://wiki.openstreetmap.org/wiki/Key:access

Eigenlijk hadden die toegevoegde vragen in een eigen subkey moeten komen, of de oorspronkelijke waarden hadden moeten verhuizen naar een subkey, net als andere nieuwe waarden die eigenlijk een andere vraag beantwoorden (zoals access=permit: een weg kan zowel permissive, designated, als permit zijn…)

[edit : eigenlijk probeert dit lijstje ook al 2 vragen te beantwoorden :
[1] Mag je hier komen?
[2] Wat is juridische de grondslag van de toegang / het verbod?

Maar dat zie je op zich vaker en het hoeft op zich geen probleem te zijn als je uitsluitende categorieën hanteert en een catch-all waarde hebt bijvoorbeeld als wel duidelijk is dat je ergens mag komen, maar niet wat de juridische grondslag in, zoals in NL : openbare weg vs opengestelde eigen weg)

Eens, op mijn droomlijstje voor OSM staat een nette simpele opbouw van de access-key, waarin 1 vraag per key wordt beantwoord met een beperkt aantal waarden, en aanvullende vragen in aparte (sub-)keys. Dan zouden we ons meer kunnen richten op verbeteren van onze database in plaats van steeds weer terugkerende discussies en wijzigingen die het gevolg zijn van een hele ongelukkige opbouw van deze key.

Maar dat zal inderdaad helaas een achterhoede gevecht zijn gelet op de grote hoeveelheid reeds geplaatste tags en onduidelijkheid daarover. Erg zonde dat er zo weinig sturing is vanuit de centrale OSM-organsiatie op zulke kernpunten. Access-informatie -zeker van wegen waar navihatiefabrikanten niet komen en voor de kleinere vervoerswijzen zijn echt iets waar OSM bijzondere positie inneemt ten opzichte van veel andere informatiebronnen.

Maar omdat de opbouw van de access-key zo’n rommeltje is geworden (18 -deels overlappende- waarden in de wiki en 733 in Taginfo ) is het zowel voor mappers als voor eindgebruikers van OSM-data onnodig lastig en frustrerend geworden.

1 Like

De route relatie ontstaat op basis van wat er in het veld te zien is.


Hier in het feitelijk openbare.
De vraag is dan, is dit al bepalend om “designated” te zetten hier voor horse. (wiel carriage)

Of is het juist de combinatie met het zone art.461 bord van de eigenaar, de eigenaar van de wegen.
Waar Natuurmonumenten op deze borden aan geeft wat mag, overige verboden.

  • ruiters uitsluitend op gemarkeerde routes.

Staatsbosbeheer geeft aan wat niet mag: “Geen toegang:”.

  • met fietsen en paarden buiten de daarvoor aangegeven route

Beide spreken niet over ruiterpaden, wat ook wel bij andere wordt vernoemd.

Komen we dan tot de conclusie, dat er op basis van deze twee geen grond is om “designated” te zetten, tenzij er een bord “ruiterpad” staat.

afbeelding

Juridisch openbare:
Alleen op basis van het paaltje was nu “designated” gezet.


tweerichtingen gemarkeerd, palen staan zo nog op het feitelijke openbare.

Ik begrijp maar zeer weinig van deze discussie.
Maar het lijkt erop dat iemand designated, etc in de routerelatie wil hebben.
Maar designated, permissive, etc horen niet in een routerelatie thuiis. Punt.
Dat kan ook helemaal niet, daar is het relatiemodel van OSM niet op gebouwd.

Een route wordt opgebouwd uit members, dat zijn de wegen waarover de route loopt.
Voor die members zijn er 2 velden in de relatie: role en name (nou ja achter de schermen wordt dat een ID)
Waar moet dan dat permissive, etc. komen? Daar is helemaal geen plek voor.
De role is hard nodig voor de rol, dus die valt af
En in de kop van de relatie kan het ook niet, want dat permissive, etc slaat op de wegen.

Een denkbeeldige wandelroute:

  • openbare weg
  • weg over een klompenpad met specifieke klompenpad toegankelijkheden
  • stukje boerenerf
  • openbare zandweg
  • pad over terrein Natuurmomumenten
  • schouwpad
  • openbaar G11 fietspad
  • pad over een particulier landgoed

Dan heb je al met tich verschillende toegankelijkheden te maken, dat wil je helemaal niet in de routerelaties hebben

3 Likes

Een vraag is volgens mij deze:

Er loopt een route=horse over een highway=unclassified, krijgt highway=unclassified dan horse=designated.

Het antwoord is naar mijn idee een duidelijk nee.

Is het goed en duidelijk te omschrijven waarom precies? Dat antwoord is waarschijnlijk ook nee, zo staat er op NL:Key:access

Een voorkeursroute of aangewezen route voor het type vervoersmiddel dat de sleutel aanduidt, zoals foot=designated in het geval van een voetpad. In het algemeen betekent dit dat er een verkeersbord staat dat expliciet aanwijst als (in dit voorbeeld) een voetgangersgebied.

Als je alleen de eerst zin leest zou je op andere ideeën kunnen komen.

2 Likes

De route zegt: deze weg is door de routemaker uitgekozen voor deze route. Dat kan die weg ook niet helpen.

“Door de routemaker uitgekozen voor een blubblup-route” is niet “Officieel aangewezen” of “speciaal geschikt gemaakt” voor blubblups.

Dat gezegd zijnde, als de routemaker de officiële instantie is die over de wegen gaat, en als die de route aangeeft als speciaal bedoeld voor pakweg forenzende fietsers, dan zou je het er nog over kunnen hebben. Maar ik denk dat er dan borden bij die wegen staan die aangeven dat de wegen speciaal aangewezen zijn voor dat gebruik, en dat je moet blijven uitkijken of delen van de route misschien wel opgenomen zijn, maar niet speciaal voor dit gebruik. Koppelstukken zeg maar.

En als over een weg meerdere routes loopt? MTB, wandel knooppunt en een ruiterroute, krijgt hij dan 3x designated?
Nee, het is niet de route dat de classificatie bepaalt, maar de weg (waar de route later aan toegevoegd wordt).

1 Like

In topicpost geef ik duidelijk aan een tag op de wegen.

Dit zette mij op het verkeerde been, ik las hier dat ze designated of de routerelatie willen taggen.

1 Like

Ik was toch benieuwd waar we nu over spreken en met deze overpass query kan je alle 706 unclassified wegen met *=designated in Nederland laten zien. Daarvan zijn er:

  • 465 met bicycle=designated
  • 125 met moped=designated
  • 48 met mofa=designated
  • 21 met horse=designated
  • 20 met foot=designated
  • 13 met hgv=designated

Even bij mij in de beurt gekeken en maar in de Hoeksche Waard zijn dat voornamelijk wegen parallel aan N-wegen die bedoeld zijn voor fietsers, snorfietsen, brommers en landbouwverkeer en ander bestemmingsverkeer. Niet echt verkeerd wat mij betreft.

Er zijn ook andere wegen, nu alleen bekeken op basis van unclassified, kijkend naar track en ook path, daarbij zou je ook de combinatie met route over een weg kunnen bekijken, voor bepaalde vervoersvormen.

Niet echt duidelijk, het benoemen van verkeersbord, maar niet wat er in het feitelijk openbare staat aan bebording, wat wel/niet grond zou kunnen zijn voor het gebruik van designated.

Ik worstel met het feit bij art.461 borden of dit genoeg reden is om "designated: te zetten bij een routebordje.

Zo, nee, mag je die data dan uit Openstreetmap halen of veranderen in “yes” voor de vervoersvorm.?

Ik zou het uit OSM halen als er sprake is van aanvullende beperkingen. Bijv. als je alleen overdag zo’n pad mag gebruiken.

Permissive voegt weinig toe als een pad in de praktijk gewoon 24x7 beschikbaar is. In Engeland kijken ze daar anders tegenaan, omdat er historische rechten zijn op een manier die we hier niet echt kennen.

Verder zou ik op een of ander manier dat bord markeren (geen idee of daar een standaard tag voor is), dan kan iedereen een router daar iets mee laten doen.

Ik zet het bord als node met een kijkrichting van het bord
access_sign=NL:*
afbeelding
In ontwikkeling (al jaren). Moet nog een style maken.