Het gaat hier inderdaad om een eenrichtingsweg. Dus:
oneway=yes
oneway:psv=no
En op het stukje ten oosten van het middeneiland:
vehicle=no
horse=no
psv=yes
Daarnaast zijn de fietspaden ten onrechte als vrijliggend ingetekend; dit zijn in werkelijkheid fietsstroken.
De tagging tussen de Generaal Smutslaan en het aansluitpunt van de fietspaden zou dan moeten worden:
De gebruikte waarde ‘permissive’ is inderdaad onjuist en zal berusten op een verkeerde interpretatie van die waarde.
De tag motor_vehicle=psv is zeker geen optie want de syntax in onjuist. Access, motor_vehicle en psv zijn allemaal access-keys en kunnen niet elkaar als waarde krijgen.
Dat er bij deze bus-/taxibaan een verkeersbord C02 i.p.v. C01 staat heeft vermoedelijk te maken met de weginrichting. Na de eerste 20 meter is het niet meer een afgebakende busbaan maar gewoon onderdeel van een rijrichting.
De toegang is daarom geregeld voor de weg als geheel en niet voor deze enkele wegstrook.
Voor de weg als geheel geldt niet een geslotenverklaring voor beide richtingen, nee het is in de basis een éénrichtingsweg.
Omdat de bus-/taxibaan in OSM terecht als apart lijnelement staat ingetekend moet je de toegang daarvoor echter wel specifiek aangeven en is gebruik van enkel oneway-tags niet toereikend.
Ik ben het eens met de opmerkingen en voorgestelde tags van 85Bas met de volgende aanpassingen voor het stukje ten oosten van het middeneiland:
Access=no i.pv. vehicle=no en horse=no → voetgangers mogen er immers ook niet komen gezien de nabije trottoirs.
Ik zie geen fietssymbolen op het wegdek in Mapillary, dus cycleway=shared_lane i.p.v cycleway=lane voor het noordelijke gedeelte.
Voor de zuidoostelijke tak zou ik i.p.v. oneway:psv=yes gebruiken oneway=yes i.c.m. psv=yes.
De psv=yes overruled dan de oneway=yes waardoor de werking wordt: eenrichtingsverkeer behalve voor psv.
Vanaf de noordzijde wordt de toegang tot die zuidoostelijke tak door een middengeleider aan al het rijverkeer ontzegd.
De doorwerking van alle verkeerstekens samen op de zuidoostelijke tak is aldus: geen toegang voor bestuurders (en voetgangers mogen er ook niet komen) dus access=no + horse=no, maar wel toegang in noordelijke richting voor psv dus oneway:psv=yes.
Het grappige is dus dat een enkel verkeersbord C02 normaal betekent dat je niet in de huidige richting en wel in tegengestelde richting de weg mag gebruiken, terwijl in dit geval juist alleen de huidige richting voor psv is toegestaan en de tegengestelde richting geheel niet is toegestaan.
Bij mij ontstaat de indruk dat een aantal zaken door elkaar worden gehaald.
oneway=yes is geen access-tag en wordt dus niet overruled door psv=yes.
De syntax met oneway= werkt namelijk precies andersom:
oneway=yes wordt overruled door
oneway:psv=no
Dat geldt dus alleen als er geen gescheiden rijbanen zijn, dus voor het N-deel van de weg.
Voor de ZO rijbaan moeten we ons doel dus anders bereiken.
De juiste manier lijkt mij dan
access=no
horse=no
daar moet dan een access-tag aan toegevoegd worden die access=no overruled:
psv:forward=yes
Je hebt gelijk. Ik had in mijn redenatie oneway als access-tag meegenomen i.p.v. als restriction-tag.
Het overruled dus niet maar geeft een aanvullende beperking op de typen van vervoer die toegang hebben.
De combinatie van Alphensebezorger is dus wel correct.
Ja, dat doet waarschijnlijk het meest recht aan de situatie.
‘Can be’ betekent in dit geval gewoon ‘dit is hoe het is’. Je kan het ook niet doen, dan werkt het niet.
Daarom is er ook een ‘generic system’. Om alle access mogelijkheden in 1 systeem onder te brengen. En oneway is een heel duidelijk voorbeel van ‘access’: je mag er namelijk vanaf 1 kant niet in.
Maar goed OSM is vrijheid blijheid. Als een router het anders wil doen, dan wordt het vanzelf een chaos.
Oneway=yes met maxspeed=60 betekent dus: eenrichtingsverkeer metn maximumsnelheid van 60 km/u voor alle verkeer dat (via de access-tags) is toegelaten.
In de Nederlandse verkeersregels is er een klein verschil tussen eenrichting en verboden in te rijden aangaande wel of niet mogen keren en achteruit rijden. Een router/navigatiesysteem zou dit onderscheid eventueel kunnen maken vanuit de tags.
Een bord C2 geeft ‘oneway=yes’ maar een bord C6 aan een kant van een straat ‘motor_vehicle:backward=no’
Natuurlijk is er een subtiel verschil tussen eenrichtingsverkeer en gesloten voor een bepaalde rijrichting.
Maar dit subtiele verschil betekent niet dat er opeens een nieuwe hierarchie ontstaat.
Historisch gezien zijn oneway en access wel gescheiden. Het heeft wel even geduurd voordat forward en backward geintroduceerd zijn.
Maar nu heeft access een algemeen schema waarmee vrijwel alles uit te drukken valt.
Een access-tag met gebruik van forward of backward als niet aan beide zijden van het wegdeel een verbod wordt aangegeven.
Het verschil tussen geslotenverklaring / verboden in te rijden enerzijds en eenrichting anderzijds is een half jaar geleden besproken in dit topic: https://forum.openstreetmap.org/viewtopic.php?pid=768521#p768521.
Het zijn voorbeelden die naast elkaar bestaan, niet onder elkaar. Vehicle, psv, bicycle, foot, horse, emergency, enz. vallen allemaal onder access. Let wel: tags als vehicle, psv, bicycle zijn een verkorting van access:vehicle, access:psv en access:bicycle.
Oneway en maxspeed vallen niet onder access, ze kunnen niet als sub key van een access-key dienen.
(Access:)psv:oneway bestaat niet. Oneway:psv wel.
De alinea gaat over het gebruik van sub keys zoals in het kopje staat (sub-values is een foutieve benaming).
Een ‘vehicle type’ kan als sub key worden toegevoegd om uitzonderingen aan te geven, zoals oneway:bicycle=no.
Een uitgebreid overzicht van alle vehicle types / transportation modes staat op de pagina over de access-key, zoals hierboven door mij gelinkt. Dat is de reden van de verwijzing.
Zoals het daar staat lijkt het er wel op, al staat er niet expliciet bij dat de ‘oneway street’ dan met oneway=yes getagd zou horen te zijn of met vehicle:backward=no.
Hoe een oneway-tag zich verhoudt tot de access-tags vind ik nergens duidelijk vermeld.
Het lijkt wel logisch om oneway te interpreteren als vehicle:backward=no.
En dan zou de psv=yes inderdaad die tag overrulen.
Het beste lijkt me om zulke specifieke situaties te vinden en dan te testen met verschillende routers. Ik zal een poging wagen.
Ik heb gezocht naar situaties met oneway=yes en bicycle:backward=yes of psv:backward=yes.
Die zijn beperkt beschikbaar in en rondom Nederland.
Enkele enigszins bruikbare voorbeelden van oneway=yes met bicycle:backward=yes en zonder verstorende tags heb ik getest met de fietsrouters van de OSM-website: OSRM en GraphHopper. Dat geeft wisselende resultaten waarbij opvalt dat het uitmaakt of het begin- of eindpunt zich op of dichtbij de betreffende weg bevindt. Zo ja, dan routeert het vaker wel via de backward-richting. Zo nee, dan routeert het vaker niet.
Testen met oneway=yes en bicycle=yes is natuurlijk ook zeer nuttig.
Hier is een geschikte testmogelijk van een (tijdelijke) wegsituatie in Groningen, een traject van enige lengte met oneway=yes en bicycle=yes en geen verstorende tags: