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:
cycleway=opposite is een oerlelijke tag en overbodig en onvolledig want die werkt alleen voor bicycle. oneway:bicycle=no + oneway:mofa=no en eventueel oneway:moped=no (afhankelijk van het onderbord) geven betere tagging en dan houdt je de cycleway tag vrij voor een eventuele fietsstroken
Andries’ voorstel "Testen met oneway=yes en bicycle=yes is natuurlijk ook zeer nuttig lijkt mij logisch gezien niet juist en conflictueus. In de ene tag stel je eenrichtingsverkeer voor alle bestuurders, in de tweede dat fietsers er mogen komen maar stel je niet expliciet dat juist fietsers ook in de andere richting dan door het eenrichtingverbod aangegeven mogen rijden.
De door Dick gesteunde tagcombinatie oneway=yes and oneway:bicycle=no is de enige juiste: kort, duidelijk, eenduidig.
Ook ik zie voor dit soort wegen vaak rare tags gebruikt worden met cycleways, lanes, opposite etc. terwijl met name in gewone ‘Nederlandse’ straten er geen aparte infrastructuur (lanes, ways,…) is voor tegemoetkomende fietsers.
Suggereer dan ook niet dat die er is.
Stel je de vraag: “Heeft de simpelste tagging het gewenste effect?” en als het antwoord bevestigend luidt: houd het daarbij.
Het is niet zo gek als je oneway=yes en bicycle=yes uitsplitst in forward en backward.
oneway=yes wordt dan vehicle:backward=no
bicycle=yes wordt bicycle:forward=yes en bicycle:backward=yes
In dat geval is het heel duidelijk dat de bicycle:backward specifieker is dan vehicle:backward en dat fietsen dus wel in de tegengestelde richting mogen.
Zoals ik het begrepen heb, vroeg Andries zich af hoe je de combinatie oneway=yes, bicycle=yes moet opvatten. Wordt de oneway-tag al dan niet opgeheven door de expliciete toestemming voor fietsers. Daarover lijkt geen heldere uitspraak in de Wiki te vinden. Daarom onderzocht hij hoe routers met deze tagcombinatie omgaan. Ik zie (vooralsnog) geen voorstel om deze tagcombinatie te gebruiken om ‘eenrichtingsverkeer uitgezonderd fiietsers’ te taggen. Ik beschouw de berichten van Andries dus als zoektocht naar de interpretatie van deze combinatie, niet direct als een aanzet tot wijziging van de gebruikelijke tagging.
Dat is een mogelijke interpretatie, maar blijkbaar zien de gebruikelijke routers de oneway-tag als iets wat min of meer losstaat van de access-tag. Die gaan ervanuit dat oneway=yes niet voor fietsers opgeheven wordt door bicycle=yes.
Naar mijn idee is er onduidelijkheid wat de tagcombinatie precies betekent, dus kan er beter gekozen worden voor wel duidelijke tagging, zoals bijvoorbeeld oneway=yes,oneway:bicycle=no, of vehicle:forward=no, bicycle:forward=yes.
We zijn het helemaal eens.
Wat ik bedoelde met de ‘nuttige test’ is simpelweg dat wat ik heb gedaan: uitvinden wat fietsrouteplanners doen op in OSM aanwezige trajecten met deze tag-combinatie. Dit om uit te vinden hoe de interpretatie van Phicoh in de huidige praktijk uitpakt.
Deze beperkte test bevestigt voor mij dat oneway=yes inderdaad alleen door oneway:*=no kan of hoort te worden overruled.
Toevoeging: ik had de opvolgende berichten nog niet gelezen. Alphensebezorger heeft het goed verwoord, dank daarvoor!