Talk:Key:oneway

From OpenStreetMap Wiki
Jump to navigation Jump to search

Default?

What is the default value of this key? I don't place oneway=no on two-way streets and only tag one-way streets. --Seav 05:26, 8 January 2009 (UTC)

Additional clarification: renderers seem to assume that the absence of the oneway tag means that the road is two-way and the routing softwares seem to assume this too. I think it would be best to explicitly indicate the default value. --Seav 05:28, 8 January 2009 (UTC)

Default is oneway=no, except for highway=motorway which implies oneway=yes. junction=roundabout also implies oneway=yes. highway=motorway_link has been a discussion a few times before, and it's best to add the oneway=* tag on those all the time, one way or not. --Eimai 12:59, 8 January 2009 (UTC)
Should this be indicated in the page? --Seav 10:49, 14 January 2009 (UTC)
Other implicit oneway=yes cases are: highway=motorway_link, highway=trunk_link and highway=primary_link. --Beldin 21:55, 22 April 2009 (UTC)
Resolved: I think that it is solved Mateusz Konieczny (talk) 20:12, 3 July 2020 (UTC)

Allowed values

There should be a listing of what the permitted values are. I've seen a lot of ways tagged with oneway=true - MapLint dislikes that, and prefers oneway=yes as generated by e.g. Merkaartor. I think the valid values are "yes", "no", and "-1". --Tms13 14:12, 27 January 2009 (UTC)

It doesn't look uniform to have oneway either true or -1, or just not set... I'd suggest it to be numerical in the first place, allowing the following values:
  • 0 -> Two-way road, default in most cases, equal to "false"
  • 1 -> One-way road, equal to "yes" and "true"
    • The road is one-way in the direction of arrows (way direction)
  • -1 -> One-way road, no equals at the moment
    • The road is one-way in the opposite direction of arrows (way direction)

This scheme would make road numbering more rational process, but would also require changes to mapping software... --Direc 21:36, 25 February 2009 (UTC)

I dislike 0/1 It is not guessable compared to yes/no or true/false. It's strange to think that 1 is yes Sletuffe 10:06, 27 February 2009 (UTC)
I'm moving my old comment from access to here : Sletuffe 10:04, 27 February 2009 (UTC)
Somebody please provide an example of where oneway=-1 is necessary. I haven't found one yet, and I'm not convinced this value is necessary. --tms13 21:02, 4 August 2011 (BST)
#One-way street that change direction by time of day? --Tordanik 21:28, 4 August 2011 (BST)

oneway=yes/1/true no/false/0

The oneway tag is one of the last tag (are there others ?) to have multiple values for the same meaning.

Since yes/no is used about anywhere else but here, I would propose to deprecate 1/true and false/0

That's not such a big deal, but I would find it much easier for every one to agree on a unique one.

Okay yes, that proposal doesn't talk about yes/true or no/false anymore, but that's my fault because I changed it unilateraly, and I regret what I did, since I should have proposed it instead of doing it.

But now, the 1/0 is back on the map feature template, but I think it better shouldn't. ( The user that did that said he did because It shows too much "waring" on the maplint error checker)

what do you thing ? Sletuffe 20:34, 7 November 2008 (UTC)

Please please stop worrying about what the value should be. All of the options are perfectly valid and understandable. If I want to tag with a oneway=true then that's fine, as are those that wish to tag with oneway=1 or oneway=yes. Just because maplint doesn't like it doesn't mean it can't be used, it means that maplint needs to have the value added. We want to encourage people to add data, not drive them away because they might use the wrong value! blackadder 12:11, 3 March 2009 (UTC)

I don't agree that oneway=1 is understandable for common people, that's not helping them to create some "geek values". And for the rest, yea/true, I don't care, I just think it complicates things for beginners to deal with two different values. The maplint case or whatever tool is a different problem, I'm only talking about documentation on the wiki here. Sletuffe 23:29, 3 March 2009 (UTC)
Resolved: I think that it is solved Mateusz Konieczny (talk) 20:11, 3 July 2020 (UTC)

One-way street that change direction by time of day?

In Hamburg, Germany we have a one-way street that changes direction from outbound to inbound between 4 am and 12 noon. I've now tagged it oneway=yes:0h-4h;yes:12h-24h;-1:4h-12h to at least attempt to capture this rule. Are there other examples of one-way streets with time restrictions?

You could use these proposals [1] [2] for your situation and put these two tags onto that way:
  • oneway = yes
  • oneway:time{4:00-12:00} = -1
Alternatively use "oneway:time{0:00-4:00;12:00-24:00} = yes" for the first tag, but it should be equivalent.
This way of tagging has the advantage of being documented (but probably not implemented in applications) already. It's using opening_hours syntax. --Tordanik 21:17, 2 May 2009 (UTC)
Washington, DC has some of these, and there are some motorways with express lanes that reverse direction, as well as the one-way only Southern Expressway in Australia. Not all of them are tied to time; some may change to suit day-to-day traffic (with strict access control measures in place). I've been using oneway=reversible for these. The Southern Expressway uses FIXME=How on earth does one tag tidal oneways? :) --NE2 05:54, 21 March 2010 (UTC)
How to map a oneway road turned by a traffic light every X seconds or minutes? Something like oneway=reversible + reversible:timer=HH:MM:SS? See also here. Thank you!--Stemby (talk) 15:16, 4 February 2014 (UTC)
We solved this problem by using oneway=no + lanes=1--Stemby (talk) 18:23, 5 February 2014 (UTC)
I think this only a solution for cases where there is only one lane --Jgpacker (talk) 17:57, 7 February 2014 (UTC)
oneway=alternate? It's already used: can we make it an official tag?--Stemby (talk) 14:41, 6 October 2016 (UTC)

Two-way streets with no-entry at one or more ends

Some streets are actually two-way, but restrict access at one end (or even both ends, with entry to the street only via a junction in the middle. These often cause confusion in real-life, with drivers assuming that no-entry and one-way are the same. However, once on such a street it is permitted to drive freely in both directions.

How should these be represented?

I've sometimes seen those being entered as really short oneway sections. The best available solution, however, is probably using turn restrictions that forbid entering the street. --Tordanik 15:22, 12 June 2009 (UTC)
Not really. A short oneway section is probably the best way to tag it. It's how I've always done it, and actually it fits well with what you see on the ground (generally such a street has a little constricted section on the end, alongside the no entry sign) . Turn restrictions are just for the more rare case where you're allowed to enter when approaching from one direction, but not the other. -- Harry Wood 14:55, 15 June 2009 (UTC)
I can't really imagine what you mean with "little constricted section". In my experience, those roads connect to the junction as a non-restricted road would, but maybe there are local differences. Around here, there are often (redundant) signs with arrows on them in addition to the no entry sign, just like those used for turn restrictions - basically, the signs state a turn restriction for every possibility of approaching the junction -, so maybe that's why using turn restrictions seems more natural to me. If a small section of the road is indeed visibly different, then splitting the way is an easy and good solution, of course. --Tordanik 21:27, 15 June 2009 (UTC)
How about extending turn restrictions to include "no_entry" as well as the more specific restrictions such as "no_left-turn"? This would more clearly express the nature of the junction and allow for map rendering that distinguishes between one-way and no-entry. If the map rendering shows a one-way arrow, one might assume that the whole road is one-way, not just the section at the end. Dnallsopp 12:29, 18 June 2009 (UTC)

Also note that some cities, in the civil code have officially designated one-way streets. However they achieve them by just putting the do not enter signs at the tail with no special sign in the front. So these are not the so-called Faux oneway streets, but genuine one-way streets, where the city just wants to reduce clutter by not putting signs at the entrance. Homeowners in the middle of the block can't pull out of their driveways and drive the other way without breaking the law. Jidanni (talk) 19:29, 8 November 2022 (UTC)

oneway exceptions for vehicles

I was asked via mail to add this information as a discussion page entry, so here we go: My proposal for conditional tagging can be used together with oneway and allows to express exceptions to the oneway restrictions - these may be based on time (see above), but also vehicle-specific (or any combination thereof). An example: A situation where busses may use the oneway in both directions can be expressed as

  • oneway=yes
  • oneway:bus=no

Note that this does not provide lane information, though, only directional information (it cannot express whether the busses use their own lane or share the space with other means of transport). We do not yet have a good way to describe lanes in OSM. --Tordanik 19:56, 28 August 2009 (UTC)

Thanks for that! --Neil.dewhurst 06:14, 29 August 2009 (UTC)

It has to be noted though that the opposite syntax is in much wider usage, i.e.:
* oneway=yes
* bicycle:oneway=no
Another alternative is to make use of ":forward" and ":backward" suffixes:
* bicycle:backward=yes
For Belgium we do have a different meaning for those two: oneway is only used in combination with oneway signs (and as such it's only possible to have bicycle:oneway and moped_A:oneway), backward/forward is for when prohibition signs are used at one end. In the latter case one would rather see something like motorcar:backward=no in that case (1). There's a need to only tag oneway when there's a oneway sign because the traffic rules change in those cases.
Note (1): in this case one would also have to tag only a small part at the end of the road, because the roads aren't oneway and one is allowed to turn around his car in the middle of the street and drive the other direction. --Eimai 11:51, 29 August 2009 (UTC)
bicycle:oneway may be in wider usage (which is of questionable relevance, because cycleway=opposite has been recommended as the "official" way to handle this situation until now), but it is not part of a general concept. While conditional tagging is a consistent idea that can handle a lot of different situations, bicycle:oneway and similar keys seem to be invented to solve a single problem at hand. (This is no problem, of course, it is even desirable - but single-problem solutions like this should be replaced when a more general approach is invented.)
Btw, I agree with the usage of *:forward - these tags are interestingly synonymous with the tags proposed as part of conditional tagging. --Tordanik 12:56, 29 August 2009 (UTC)
Your choice for oneway:bicycle is actually just as arbitrary. Whether or not it is part of some "bigger proposal". This oneway:bicycle usage was already there before you wrote the proposal. Yeah sure, we also have cycleway=opposite, but try to work that out in a country which also often excludes mopeds class A from the oneway restriction. And before saying that your proposal is better, I want to see it worked out formally anyway, so something non-human can also make sense of it.
btw, I was also just saying that *:forward shouldn't be a synonym of oneway:*. It can be the case just for access rules, but there's more to consider as well, and mapping one with the other can result in inaccuracies. --Eimai 13:57, 29 August 2009 (UTC)
Is there any improvement to the Wiki page still needed? Mateusz Konieczny (talk) 20:12, 3 July 2020 (UTC)

Image

The image is quite confusing. Please replace it with an explicit definition of a oneway street. By the way: the image is taken from wikipedia and the german text on wikipedia for this sign tells something like "traffic sign jungle".

So which one do you prefer as a better oneway image?

--WanMil 16:28, 31 October 2010 (UTC)

None ;-p I would prefere one which does not make use of any words of any language. Such as an image with a real car comming from and a [4] sign. But I failed to find one. sletuffe 16:31, 3 November 2010 (UTC)
The swedish variant? File:Sweden road sign E16-1-1.svg --WanMil 18:25, 3 November 2010 (UTC)
@WanMil and Sletuffe: I replaced the blooper image with a standard sign from New Zealand. New Zealand has adopted a design incorporating elements of the one-way signs in the Americas and Eurasia, so I think it's a good compromise. I don't think a wordless image is a good idea for this English-language article, because people in most of the Americas expect text on a one-way arrow. In the U.S., we have a sign that looks identical to the Swedish sign above but merely means that a destination is to the left. – Minh Nguyễn 💬 06:22, 30 October 2022 (UTC)

Speed limit per direction?

Does anybody have an idea how to map a simple (bidirectional) street which has different speed limits per direction? I think that two parallel unidirectional ways are kind of misleading. Any opinions?

-- NachtSpazz 00:40, 10 October 2012 (BST)

Key:maxspeed suggests maxspeed:forward=80 and maxspeed:backward=100. --Tordanik 16:17, 10 October 2012 (BST)
See Lanes for one approach --tms13 20:00, 10 October 2012 (BST)
But note that these have different meanings - they are not always interchangeable and there are situations where only one is correct. If maxspeed depends on what lane you drive on, maybe even with different maxspeeds for lanes that go in the same direction, you use Lanes. When maxspeeds depends on driving direction rather than lane (e.g. even if you use a shared lane for either direction), then maxspeed:forward/backward need to be used. There are cases where both tagging conventions can adequately model a real-world situation, though. --Tordanik 12:22, 11 October 2012 (BST)
Thanks for the replies. Actually, it is well explained already on Key:maxspeed#Driving_direction. I somehow missed that. -- NachtSpazz 23:49, 22 October 2012 (BST)
Resolved: I think that it is solved Mateusz Konieczny (talk) 20:11, 3 July 2020 (UTC)

Oneway tag without oneway sign exists

Tag oneway=yes can, does, and must exist also without a "oneway street" traffic sign: think dual carriageway roads, where the carriageways usually only have a no entry sign at each intersection, but demand the oneway tag. One osm way is not a one-to-one representation of a road, but tries to convey a reasonable and usable abstraction of a part of the network. It's the original "used when this way can only be used in one direction" that matters - just split the ways where necessary.

As mentioned in the recent mailing list thread, real world vehicles have length and need to move forward (and/or backward) to turn around, so around each "no entry" sign (or similar signs for limited sets of vehicles) there is always a short section where a driver can no longer choose to start moving/turning in the forbidden direction without ending up driving past said sign; that short section is in practice oneway. Only what's present beyond the sign can then tell us whether the rest of the street (the other part of the split way) may or may not get the oneway tag, but it doesn't change the only allowed traffic direction on that short bit. I'm not saying that the no entry relation is bad in some places, but this made up requirement for a oneway street sign is already distracting mappers. Alv (talk) 07:09, 5 February 2014 (UTC)

@Alv: Is any action needed at the Wiki? Is there anything that should changed in the article? Mateusz Konieczny (talk) 20:11, 3 July 2020 (UTC)
Haven't been active lately, but a quick read of the current page doesn't give me any ideas for improvement. The version in German is quite good at describing the need for a mapper to consider the layout in detail and as a whole street, as opposed to looking for a (missing) oneway traffic sign. It's worth a mention and linking when other pages or discussions try to erroneously imply that a specific sign is always needed for the oneway tag. Alv (talk) 20:59, 10 August 2020 (UTC)
@Alv: @Mateusz Konieczny: I translated the section from the German wiki. It appears to mostly be a German concept, as I couldn't find anything about these searching in English, thus the awkward name. It may be useful to discuss which of the two approaches should be prefered, as both have their advantages. --Popball (talk) 17:56, 15 September 2022 (UTC)
I think both options currently mentioned on the page (Split a small section at the entrance to the street and tag it with oneway=yes and use a relation) are ugly and there is a good alternative I think, implicit=yes. That is already mentioned on relation:restriction and Mapbox wrote a nice page on it, see Mapping implicit turn-restrictions. See taginfo, it is also used and even in combination with oneway=* there is already some usage of implicit=yes.
So instead of using a relation that should in this case also be mapped with implicit=yes, let's map the way with oneway=yes + implicit=yes so you do not need that relation --- Emvee (talk) 06:48, 16 September 2022 (UTC)
The problem I see is that these are not true oneway roads. You can make a U-turn on them and drive the opposite direction on them (usually only until the next intersection, where there may be another "no entry" sign). However, they are (for most intents and purpaces of through traffic) oneway roads. --Popball (talk) 08:25, 16 September 2022 (UTC)
Yes, almost everything is not a clear yes or no, you will find always in-betweens but based on what you describe this is for me a clear oneway=yes with implicit=yes if there is no sign ;-) --- Emvee (talk) 08:47, 16 September 2022 (UTC)

Does oneway:bicycle also apply to cycleway=track or cycleway=opposite_track?

Somebody argues that oneway only applies to the lanes of a highway and not to those facilities like cycleway=opposite_track or cycleway=track. Actually cycleway=opposite_track is not interepreted by many routers to be usable against the oneway direction for cyclists. So you may have to add oneway:bicycle=no to fix this issue. I do not have a fix oppinion on that, but it is nothing good if this remains undecided, because mappers may remove this information and make the map unusable.--U715371 (talk) 19:55, 25 February 2015 (UTC)

After reading Key:oneway#Sub_keys_.2F_exceptions again, I am pretty sure that oneway:bicycle=* applies to cycleway=opposite_track. I think it is decided already. Closed.--U715371 (talk) 23:36, 1 March 2015 (UTC)
Resolved: I think that it is solved Mateusz Konieczny (talk) 20:10, 3 July 2020 (UTC)

Request for removal of the One Way tag

This tag is completely inadequate and should be removed.

The correct tag should be motor_vehicles=forward under the 'allowed access' options. --pmailkeey 2016:6:8:12:30

Sorry, but that is a horrible idea and it is not going to happen Mateusz Konieczny (talk) 17:23, 13 March 2019 (UTC)
Resolved: I think that it is can be treated as solved Mateusz Konieczny (talk) 20:09, 3 July 2020 (UTC)

Broken link - Set of tags that imply oneway=yes according to iD editor

The Set of tags that imply oneway=yes according to iD editor link is broken. As far as I can tell, the information is only available using this code search.

It may be simpler to just write "In the iD editor oneway=yes is implied by highway=motorway and highway=motorway_link" -- Zstadler (talk) 04:56, 22 July 2016 (UTC)

I found where the list moved to in iD and updated the link. Mrwojo (talk) 01:18, 24 July 2016 (UTC)
Resolved: I think that it is solved, after fixing it again in 2020 Mateusz Konieczny (talk) 20:09, 3 July 2020 (UTC)

Interpretation when used as suffix, i.e. *:oneway family of tags

There has been some debate in josm ticket #17307 how to correctly interpret *:oneway=* family of tags, i.e. when oneway is used as a suffix to other tags.

It has been claimed in the ticket discussion that in this case *:oneway=yes is polymorph to both *:oneway=1 and *:oneway=-1, but this would strongly oppose wiki documentation as documented above in section #Allowed values and many other places in the wiki. --Cmuelle8 (talk) 15:03, 13 March 2019 (UTC)

"*:oneway=yes is polymorph to both *:oneway=1 and *:oneway=-1" can you explain meaning of this? Mateusz Konieczny (talk) 15:21, 13 March 2019 (UTC)
For example, what would "piste:oneway=yes is polymorph to both piste:oneway=1 and piste:oneway=-1" would mean in practice? 15:26, 13 March 2019 (UTC)
See wiktionary:en:polymorph for a general explanation of the term. First, I do not support the idea of the value yes being polymorph to both numeric values. It means, here, that the value yes may correctly replace the numeric values and that the concrete interpretation, i.e. one that is identical to the use of exactly one of the numeric values, must depend on additional information. Without the latter you will not be able to tell whether yes replaces 1 or -1, but that it must stand for one of both. --Cmuelle8 (talk) 16:19, 13 March 2019 (UTC)
For example, Doug claimed that in a
(:left refers to the left side of the osm way, regardless of the traffic system).
I'm in strong disbelief that the value yes is polymorph, because I've learnt that it is a strict synonym to the numeric value 1 within the osm realm of values. This favors a conretion of cycleway:left:oneway=yes to cycleway:left:oneway=1 under any circumstances, regardless of the traffic system you're in.
Doug claims that the live data is in favor of the example laid out above and that he has found lots of data samples in Germany supporting polymorphism of the yes value and I've asked him for locations (e.g. osm map links) to verify the claim. This is the point we've reached so far.
Another claim is that *:oneway=* is to be interpreted differently than oneway=*, in that not solely the osm way direction (i.e. the direction given by order of node list) is referenced, but additionally things like
  • presence of left/right-hand side traffic system at the location the tag is employed or
  • the value of oneway=* if present
Also, questions were raised about default values, in case of absent tags (and if/how these default values differ depending on the traffic system). --Cmuelle8 (talk) 16:19, 13 March 2019 (UTC)
If there are instances of cycleway:left:oneway=yes that are poorly tagged (oneway not based to direction of way) then it should be fixed as a bizarre tagging. Even if all cycleway:left:oneway=yes are tagged in this way it still should be relatively easy to fix as this tag is rarely used and there is no valid reason to have several ways of how oneway works. Though for now I assume that this mistagging is rare and not dominating and therefore a blatant tagging mistake. Mateusz Konieczny (talk) 17:22, 13 March 2019 (UTC)
Ok, but if we are to believe Doug's research this does seem to be a substantial problem!? Maybe it's better to discourage yes and favour numeric values in the future, but then again -1 and 1 only differ by one char: To distinguish the values on the human side of things, the established triple <yes, no, -1> does have clear advantage, so maybe we can "rescue" the value of yes being a strict synonym to and only to a numeric value of 1 by improving the documentation - shouldn't the outcome of the conversation under #Allowed values be part of the article?? Or do we have to vote on the meaning of yes in oneway value context? --Cmuelle8 (talk) 19:28, 13 March 2019 (UTC)
I've written up a scratchpad, reusing the SVG diagrams of Bicycle. Maybe it helps to clarify the intended meaning of the non-legacy, non-traffic-system-dependent tags. It consistenly uses numeric values to work around the unclear status of yes (is it polymorph as laid out above <> or does it conform to the interpretation described under #Allowed values). This is by no means a request to tag according to the scratchpad, hence the name and the proposal note at the beginning. For live editing always use the documentation given in Bicycle instead. --Cmuelle8 (talk) 19:11, 13 March 2019 (UTC)
I agree with Cmuelle8, oneway=yes is synonym with oneway=1, while oneway=-1 means a oneway against the direction of the OSM way. --Dieterdreist (talk) 09:23, 15 March 2019 (UTC)

Pedestrian oneways

The recent addition of oneway:foot seems problematic to me because it contradicts the general rule that oneway does not apply to pedestrian traffic. According to how conditional restriction syntax works, adding a mode of transport such as :foot only ever limits who the tag applies to, it doesn't normally add someone it applies to. I would therefore suggest using foot:backward=no for pedestrian oneways instead, which does not have this problem. --Tordanik 11:24, 5 January 2020 (UTC)

I actually share your concerns and have changed the page accordingly. Nonetheless the tag is documented and has 1300 uses. Would you be willing to propose an alternative key? —Dieterdreist (talk) 20:29, 5 January 2020 (UTC)
  • oneway=* does not apply to pedestrian traffic - I generally agree here, though there are case where mappers used this tag to tag oneway pedestrian direction, especially on ways where only pedestrians are allowe. But why oneway:foot would not apply to pedestrian traffic? It is quite explicit. I am not sure why conditional restriction is relevant, it is for keys with :conditional prefix. "only ever limits who the tag applies to" - we have over 12760 oneway:bicycle=yes on ways without oneway=yes, see https://overpass-turbo.eu/s/Pub . Personally foot:backward=no is really confusing for me and I am not fan of this solution. Mateusz Konieczny (talk) 10:47, 6 January 2020 (UTC)
There's no issue with oneway:bicycle=* as the regular oneway key applies to bicycles as well. I admit that I used the term "conditional restrictions" incorrectly: What I meant was "the rules for composing machine-readable restriction tags from well-defined building blocks" (which were defined with the conditional restrictions proposal as well as older proposals that it built on). Of course we could say that oneway is an exception from that general rule. But I hate unnecessary exceptions and special cases. :) --Tordanik 18:07, 7 January 2020 (UTC)
oneway=* tag is one of the tag from access=* family tags, which regulates the possibility of movement in a certain direction on the way. This is default tag that we use to specify allowed direction of different kind of traffic. Also, we imply that presence of this tag on motorable roads do not affect pedestrian traffic. In addition, we use the `backward`\`forward` suffixes in conjunction with the type of movement to specify same thing and this can be considered as a substitution for oneway=* tag. Hence, we have two equal schemas that can be used to specify allowed oneway direction of the traffic, where oneway=* is used for default values and `backward`/`forward` suffixes to alter default values for specific modes of movement. Q: Why Wiki recommends not follow general approach of usage oneway=* tag for roads that were intentionally designed and used for pedestrian traffic? --Andygol (talk) 07:38, 22 May 2021 (UTC)
Note: I posted on tagging mailing list looking for more feedback Mateusz Konieczny (talk) 21:33, 8 January 2020 (UTC)

@Mateusz Konieczny: @Tordanik: and what was the result? The current usage now very much contradicts the wiki: oneway=yes+highway=path is used in almost all cases, and both oneway:foot=* and foot:backward=* usage is negligible. All the above sounds like a good theory which completely contradicts practice (and seemingly the expectations of mappers, and in turn the editors[' validators] used by everyone). --grin ✎ 12:58, 12 November 2021 (UTC)

Do you have a proposed definition of oneway that is consistent with both current usage and the voting-approved rules for conditional restrictions? Is there a concise and easy-to understand rule that works for the various cases (pedestrian-only paths, shared footways+cycleways, pedestrian roads with oneway vehicle traffic)? --Tordanik 13:21, 13 November 2021 (UTC)
@Tordanik: (I pinged you becaue you may be interested in the discussion, it was Mateusz who said he asked on the tagging list.) It wasn't me who asked on the tagging mailing list, so I guess you wanted to ask Mateusz as well. I asked about the result, since if there was anything agreed then it's not productive to start an already rejected scheme. I could create definitions, rules and else, but I don't think that was the question right here and right now. If there wasn't any useful conclusion then indeed that will be my next step, since the wiki section about oneway paths right now is highly fictional. --grin ✎ 15:28, 13 November 2021 (UTC)

discussion from the wiki page

@JeroenvanderGun: let's not use the wiki page for discussion. You wrote there:

#1*Not all current usage reflects the above theory. For example, in late 2021 highway=path+oneway=* used on 32000 (out of total 72000) objects, oneway:foot=yes on 550 (out of 2200 total oneway:foot=* objects, mainly used as "oneway=yes+oneway:foot=no") and foot:backward=no on 110 (out of total 260), showing that some mappers consider oneway=* valid for all kinds of movement, including foot. #2*On the other hand, there is a massive number of one-way streets tagged only with oneway=yes which are bidirectional for pedestrians. #3*Data consumers could follow the vehicle-only theory in most cases but pay special attention and possibly deviate from that theory if oneway:foot=* is present or if oneway=* is set on a footway. Of course, data consumers may always decide to interpret tags however they deem suitable.
  • (1) "Not all" - that's an extreme euphemism, 32000 vs 110, that's almost two magnitude. I'd say alternative usage is close to non-existant, may be a result of a few mappers. May be "a few edits" more accurate. :-)
  • (2) May I guess that none of those are highway=path, highway=footway, etc.?
  • (3) This is a bad, potentially harmful advice, and I would remove it. Data consumers shall probably take oneway on vehicle purpose roads as vehicle-only and on footway oriented roads as footway related (and generally if a way main purpose is not vehicle then oneway reflects the directional requirement of that purpose). "Of course anyone can do whatever they want" is a good advise *snicker*. :-) --grin ✎ 09:42, 15 November 2021 (UTC)
It seems there is some confusion as to whether the text you added applies to all highways or whether it applies specifically to footways and footway-like paths. That matters a lot w.r.t. what the majority is. Feel free to edit the text as long as you avoid this ambiguity.
Your proposed data consumption advice seems fine, but for ways with dual vehicle and pedestrian use I'd recommend sticking to the advice I wrote. If possible, the text would benefit from a more specific indication of what is a pedestrian-oriented way: e.g. the text currently mentions highway=track, but I would definitely not consider that pedestrian-oriented. Perhaps there is also some variation in tagging conventions across the world here.
It would also be nice to know how pedestrian route planners deal with these tags. --JeroenvanderGun (talk) 21:01, 19 November 2021 (UTC)

Meaning of oneway=-1

I see some streets in my city are marked this way instead of oneway=yes and I can't figure what would set them apart from other one way streets. My best guess is that whoever mapped them found this easier than reversing the object. Interestingly OsmAnd shows the direction arrows on these streets in blue instead of black. Is there any special meaning to oneway=-1 that I'm missing? Rostaman (talk) 01:52, 7 January 2020 (UTC)

I turned Tag:oneway=-1 into an article to make this easier to find. It is described in this article see Key:oneway#Normal_use (search page text for "-1", any decent browser has this feature). Mateusz Konieczny (talk) 10:15, 7 January 2020 (UTC)
Ok, I'm gonna replace those tags with oneway=yes then. I figured as much, I just wanted to double check. Rostaman (talk) 20:03, 7 January 2020 (UTC)
There may be reasons like relation membership which make it easier to add oneway=-1 rather than inverting the way direction and fix all resulting problems. oneway=-1 is just as good as oneway=yes, no reason to reverse the way (but also no harm, provided you take care of all the consequences like direction dependent membership roles and tags). --Dieterdreist (talk) 09:02, 8 January 2020 (UTC)
oneway=yes is more clear and less confusing that oneway=-1, in my opinion it should be used where it is not causing even worse issues (I am not alone, JOSM authors also consider it as inferior to oneway=yes) Mateusz Konieczny (talk) 21:25, 8 January 2020 (UTC)
Did it here, there were about 25 streets with oneway=-1. A few of them have relations but it seems to me that iD has dealt with this intelligently. Rostaman (talk) 22:38, 8 January 2020 (UTC)
Resolved: I think that it is solved Mateusz Konieczny (talk) 20:08, 3 July 2020 (UTC)

implicit oneway

Currently the page states, that junction=roundabout and highway=motorway and others are implying oneway=yes. Which are these "others"? Not even the key definition for oneway can tell me which highway types imply "oneway=yes"? https://wiki.openstreetmap.org/wiki/Key:oneway#Implied_oneway_restriction --Dieterdreist (talk) 13:32, 3 July 2020 (UTC)

In large part - because what is treated as implied/guessed depends on a data consumer Mateusz Konieczny (talk) 21:00, 3 July 2020 (UTC)
then it can be removed because this is nothing specific to oneway, and it doesn’t add information if it does not list which combinations it applies to.—Dieterdreist (talk) 07:25, 4 July 2020 (UTC)

broken link

I've had a look at the link you marked as broken. I think this is probably the new location of this content. About halfway down there is a list of 20-30 tags after export var osmOneWayTags = {. Most are predictable: rivers, ski-lifts, conveyor belts... Rostaman (talk) 19:17, 3 July 2020 (UTC)
Link fixed, thanks! Mateusz Konieczny (talk) 20:08, 3 July 2020 (UTC)
thank you, I had suspected it was fixable that’s why I didn’t remove it. —Dieterdreist (talk) 20:26, 3 July 2020 (UTC)

How to tag reversing water flow direction?

There is https://wiki.openstreetmap.org/wiki/Key:oneway#On_waterways which strongly discourages `oneway` but offers no alternative... Mateusz Konieczny (talk) 19:20, 21 August 2021 (UTC)

I thought about eg oneway:physical=*, but it may be about whether a pipe or culvert is designed for two-way flow... (From OSM Word https://discord.com/channels/413070382636072960/782593988611014676/878694287368388649) Better ask on Talk:Tag:flow_direction=both for your flow_direction=reversible. Somehow Key:flow direction page doesn't exist first. Proposed features/Sinkholes refinement also have refitted=yes and anthropogenic=yes "approved" for use with natural=sinkhole (reminds me of artificial=*), which may possibly indicate whether a water channel has been modified for two-way flow. ---- Kovposch (talk) 09:34, 22 August 2021 (UTC)
In addition to the comment above: We could of course refer to tidal=*, but that only covers a portion of situations.
For me bidirectional=yes came to mind as a logical option, but currently that key in only used 28 times and not on waterways: https://taginfo.openstreetmap.org/keys/bidirectional#combinations
Maybe there haven't been too many cases in which mappers wanted to use such a tag outside tidal situations? Nevertheless I think it's good to make clear that oneway=* refers to the legal situation instead of the physical to avoid usage becoming mixed up in the future. Cheers Multimodaal (talk) 10:14, 22 August 2021 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:oneway&oldid=2432414"