It would be wrong for them to treat roundabouts as bidirectional. It would be wrong for OSM to tag objects just to correct someone else’s errors. You don’t need to read a wiki to know that roundabouts have oneway traffic.
There’s a bigger issue here than just roundabouts. There are a bunch of places in OSM where people “overtag” because some data consumers are, shall we say, “less than optimal”. Another example is people adding “bicycle=yes” on trunk roads where it’s perfectly legal to cycle there.
Neither adding nor removing the tag is exactly “wrong”, but it’s a waste of everybody’s time.
If someone really is interpreting roundabouts in OSM as “two way by default”, someone else probably needs to have a quiet word with them suggesting that they engage brain before writing code - that’s certainly more silly than the “trunk roads” example.
I think that is a big european point of view. A lot of north american people have seen a roundabout only once or twice per year in their usual environment and saying they should know better is a bit far fetch. I would never engage in such conversation for something that seems obvious to a lot of you guys if I did not find several instances where people misused the data, not because they are uneducated on the subject, but because they just assumed something that is logical according to their local environment. I have seen circular junctions that are not oneway and people call them roundabouts or “giratoires” without any hesitation. Since in Quebec, roundabouts are still rare, I wanted to keep the oneway tag for more robustness and reduce the risk of errors.
It was probably on a wiki that I first read about Swindon’s Magic Roundabout. It is a one-way, for some definition of “one” and “way”, and part of router developer lore at this point. On the ways forming this roundabout and others of similar make and model, the word “roundabout” appears in name=* rather than junction=*, which neatly avoids misleading data consumers, validators, and rational skeptics alike.
At least the UK is a fairly rational place.
The more likely situation is that they aren’t interpreting the attribute tag junction=roundabout at all and are just interpreting the main feature tag highway=* as two way by default. It’s not all that surprising that a data consumer might expect a oneway=yes tag to be present wherever a highway=* is oneway, especially if they aren’t already processing junction=roundabout for some other purpose or if they are simply unaware this tag even exists.
Circular junctions that are not roundabouts (i.e. with oneway traffic and priority for traffic on the roundabout) should not be tagged as roundabouts. I am told that a few true two-way roundabouts exist; they probably could do with explicit oneway and direction tagging. I can imagine that not all starting mappers are familiar with roundabouts; please help them understand and map the few roundabouts in their vicinity correctly. Data users always need to familiarize themselves with the data definitions; the default oneway for roundabouts is well described and in no way hidden, controversial or obscured.
May there are not that many roundabouts in Quebec, but the ones present, are they very different from other roundabouts in the world?
E.g. In Nederland, roundabouts are oneway by definition, but do not legally have priority for vehicles on the roundabout. So to “deserve” the title of roundabout, all accessing ways have to have give_way signs. Even if only one accessing way does not have a give_way sign, the junction is not a roundabout for OSM, and we have to tag explicit oneway tags on alle the way segments on the not-roundabout. Luckily 99,99% have give_way signs (or shark’s teeth) all around.
E.g. In Nederland, roundabouts are oneway by definition, but do not legally have priority for vehicles on the roundabout. So to “deserve” the ttile of roundabout, all accessing ways have to have give_way signs. Even if only one accessing way does not have a give_way sign, the junction is not a roundabout for OSM, and we have to tag explicit oneway tags on alle the way segments on the not-roundabout. Luckily 99,99% have give_way signs (or shark’s teeth) all around.
same situation in Italy.
I just hit this, because the german version of the wiki states that oneway=true is implied for junction=circular while the english version does state that oneway is implied to be *
How is this to be reconciled? We cannot hope to build good navigation systems if we do not agree on a global data model. At this point, I do not care about the outcome one way or the other (pun intended) but we need to have only one way of tagging across all languages and communities.
Is there an authority in the OSM project for this kind of design questions?
The discussion above is actually a pretty good, nuanced, discussion of the issues.
OSM data is incomplete and sometimes wrong, but so are all the others. OSM’s advantage is that sometimes it is less wrong that the competition.
If you’re a data consumer of any data then you need to be always asking yourself “what was probably meant by …”, and this this doesn’t just apply to OSM. If your bank phones up about two rogue transactions, you need to ask yourself “is this really my bank?”.
If in OSM you see a junction=roundabout without a oneway, or a motorway without bicycle=no, you can as a data consumer say “I will assume that this is oneway” or “I assume bicycles are not allowed” if you know the jurisdiction for which you are making a map, you can guess the “missing” tag (and with motorways at least, that might depend on where in the world you are).
Like the database, our documentation site is a wiki that anyone can edit. Some edits represent a consensus hashed out in lengthy discussions like this, while others are less deliberate, even unilateral and controversial. Data consumers have to rely on common sense, analysis of the actual state of the database, and advice from the community.
Often discrepancies like this arise because the world turns out to be more nuanced or diverse than the original author of the documentation assumed, but whoever updated the documentation only speaks one language but not the other. Fairly or unfairly, many mappers treat the English documentation as being more authoritative in general, if only because it gets more attention from the global community than the other versions.
The English documentation elaborates further down:
- Add
oneway=*. Although the majority of circular junctions will be one-directional, sometimes (sections of) junctions can be bi-directional. This is especially common for cycleways.
An earlier version of the article gave another reason to set oneway=yes explicitly on a one-way circular junction:
As this is a new value for the junction key, many data consumers might not be able to assume the oneway property implicitly.
Not only do we lack a formal system to ensure consistency between translations of the documentation, but we also lack a formal system to ensure that data consumers stay up to date with the latest tagging innovations. This makes backwards compatibility a priority for any form of navigation mapping.
If a data consumer is looking for something machine readable, the corresponding data item offers slightly more predictability. Many items indicate a cross-language discrepancy by qualifying a statement with a limited to language (P26) qualifier.
Almost certainly German translation should be updated, though there are exceptions - looking into edit history of both would help. In general, translations of English wiki into other languages are relatively often outdated and wikifiddling happening there is often not noticed. Wikifiddling is editing wiki with a weird belief that changing wiki page will magically change beliefs and mapping of other mappers and map data will magically update itself to match new claimed definition.
I can’t find this. oneway=yes is implied by junction=roundabout but not for junction=circular. At DE:Tag:junction=circular - OpenStreetMap Wiki I read
in the box on the right side.
The text of the German wiki article could be adapted to the more comprehensive English version though.
Yeah, the German wiki says that oneway=yes is implied on junction=roundabout but that it’s required on junction=circular which presumably means that it’s not implied.
The more general problem is that lots of places in the Wiki claim that one tag “implies” another, but people don’t agree what that means.
Does it merely mean that in the absence of information to the contrary, it’s a reasonable assumption for a data consumer to make, but there can be exceptions (like vehicle=yes implies motor_vehicle=yes, or highway=secondary implies motorcar=yes)? Does it mean it applies by definition, so exceptions are not possible (e.g. natural=water implies area=yes)? Does it mean that mappers (who exactly?) have agreed not to add the tag explicitly but if you want to add it that’s not the end of the world? Or even that adding the tag explicitly is harmful and removing the tag is welcome?
The Wiki would be a lot clearer if it stopped saying that one tag implies another and instead clearly said what is meant.
I would lean towards generally assuming that “k1=v1 implies k2=v2” means “if k1=v1 and k2 is not specified, assume k2=v2, but if any other value for k2 is specified, that takes precedence”.
As for area, this is a special case as the wiki entry for each tag indicates the element type it is meant to be used with. For example, natural=water is intended for use with areas or relations, not with points or ways. (Btw, the wiki does not state that natural=water implies area=yes.)
The only restriction I would see is that tags should not be overridden in a way that is contradictory, e.g. highway=motorway, foot=designated, motor_vehicle=no. But that is no different from other technically possible but semantically nonsensical combinations à la highway=motorway, cuisine=chinese.
Redundant tagging is not an error and doesn’t do much harm, apart from taking up a few extra bytes. We have tags which are purely redundant, e.g. noexit=yes. The only information they carry is “dear fellow mappers, this is not an error or omission on my part, the situation on the ground really is as described here”.
Regarding junction=roundabout and junction=circular, in an ideal world we would have/reach a common understanding of what the default assumption for oneway should be – without a common understanding, any use of this tag without explicitly specifying oneway would be ambiguous and should be avoided. Ideally, the default assumption should be the most typical situation, and any deviations need to be tagged explicitly.
as a proposal to the last point:
Junctions and roundabouts should be considered oneway=yes in absence of the oneway tag. Should oneway be specified, that takes precedence.
Does this sound reasonable? If so, how does it become a decision?
I general I agree, but…
natural=water or landuse=cemetery and other area-implying tags are in general perfectly fine to be used on nodes (though areas are in basically all cases better)
Indeed, I didn’t look correctly. The wiki says natural=water is OK for points and areas (which presumably includes multipolygon relations), but not on lines or (general) relations.
It becomes a decision for you when you implement it in the rules that you use when interpreting OSM data, “Making a rule” or writing something in the wiki (or as here, in one of the language wikis) doesn’t magically make OSM data conform to that rule.
I can think of more than a few examples where OSM tags can mean different things (e.g. is a closed way with certain tags an area or a line?) and where my renderers’ interpretaton of those tags differs from others. Changing a wiki page doesn’t change what an OSM mapper meant when they mapped a feature; it just makes the wiki wrong.
The rendering in JOSM assumes that junction=circular implies oneway=yes.
If you are tagging a junction=circular, please always add either oneway=yes or oneway=no, because different data consumers are likely going to make different assumptions otherwise.
junction=roundabout has long been documented as implying oneway=yes. Originally that meant oneway=yes was optional, but then some mappers undertook a campaign to remove oneway=yes from as many junction=roundabouts as possible, so that a data consumer these days cannot reasonably depend on an explicit oneway=yes to indicate directionality.
If you want to see something similar happen with junction=circular, then you could undertake a similar campaign after consulting with the community on this forum, but support is not guaranteed. Before going through that trouble, you might want to analyze existing usage of junction=circular without oneway=yes, to see how many of these junctions are actually one-ways in the real world. If the results surprise you, you could add some advice to the wiki that data consumers should not depend on an explicit oneway=yes, and/or that mappers should make sure to add oneway=yes just in case.