something like highway=foot with area=yes also wouldn’t be wrong
you could add traffic_island=yes
https://taginfo.openstreetmap.org/keys/traffic_island#values
This is technically true, although it can still be a safety feature, if not a calming feature specifically. Some cities systematically paint islands as a minimal, “quick-build” form of protection for cyclists, as a precursor to a raised concrete island. (My city has placed sturdy-looking but totally harmless plastic bollards to reinforce the islands in the meantime.)
We don’t have an established key for safety features more broadly, so I’m not surprised that mappers have bent traffic_calming to accommodate some calming-adjacent features.
Sometimes, but many traffic islands and traffic medians aren’t intended for pedestrians. The narrow island approaching an intersection or roundabout often attracts panhandling, but standing there is discouraged or illegal. Larger traffic islands may be landscaped or, in drier climates, left as dirt.
This can also be true of the sort of traffic island that we’re saying belongs in traffic_calming, but we have a tag for that based on the function that it serves:
1 Like
that’s probably in the United States of Motorists, around here standing roadside is only forbidden on motorways (except you’re in an emergency), you can walk and stand everywhere unless it’s explicitly forbidden and these are rare (e.g. tunnels tend to be forbidden for pedestrians), actually standing on the carriageway is also here forbidden, while walking on the road is allowed if there is no sidewalk or if you are carrying bulky stuff that would impede other pedestrians on the sidewalk.
In your first picture it would eventually be forbidden to step on the flowerbeds
1 Like
Hah, fair enough. Though for once, it isn’t only about catering to motorists. The regulations about standing on this median dividers are usually also part of a policy to curb panhandling. So for example, the signs near me say “No Solicitation Zone” instead of simply “No Pedestrians”, but the effect is the same.
Anyhow, common sense says these aren’t sidewalks, even though sidewalks do sometimes occur in a traffic median:
I do agree that sometimes the paint marks off a gore that doesn’t calm traffic at all and can hardly be called an island. Or if it is an island, it’s hardly a tropical escape:
Hi there.
Last week I was surprised to see that iD changed the preset of traffic_calming=island + area=yes.
Although the initial proposal stated that traffic_calming should be used on nodes and ways, that fact is it has been used to map physical islands in the road, to separate ways and slow traffic on incoming crossings/intersections.
Taginfo informs that there are more than 40 thousand uses of traffic_calming=island + area=yes and now, suddenly, the wiki was changed and the iD preset was also altered.
Not only I don’t agree with this change after so many uses (we have to remember that use is one of the main stays for something to be mapped in a certain way), but also I don’t agree that these aren’t traffic calming features:
Their function is exactly to reduce speed and discipline traffic in various ways.
This being said, what’s the gain from changing a well established scheme like traffic_calming=island + area=yes to area:highway=traffic_island?
I think if paint demarcates a significant area of separation and delineates flows of traffic, I think it’s okay to map it. Especially in some countries like Greece, where physical kerbs are far less common.
How about creating a new post? The vast majority of uses are almost certainly because iD uses it as a misleadingly named preset and allowed on areas, not that it’s good or accepted. area=yes is not a well-thought extension. area:highway= exists both in proposal and relatively standard use. The problem is two-fold, whether they are “traffic calming”, and how should areas be treated.
Example 1 is not traffic calming, as the curve already exists, and is the undeflected vehicle path for the highest speed. That’s called channelizing. If you want to slow down vehicles, you won’t use such curved islands. Rather, there should be a 90-degree perpendicular entry to the road, together with small corner radius. A straight island would only be used to separate the movement for driver route decision, reduce crossing length, further slow down vehicles by narrowing, and install street furniture viz traffic lights for separately signaled turns.
traffic_calming=island + area=yes has a different meaning from traffic_calming= points. It is a physical thing, not functional on the linear highway= road
As a result, the traffic_calming=island + area=yes feature is not included on the linear highway= road, and is thus unroutable. The topological relationship is lost. A spatial query is not suitable for application.
For a solution, if hypothetically another traffic_calming=island point is created on the highway= road, this causes conflicting meanings between object types, which is bad. (When the road is split to a pair of oneway=yes , a traffic_calming=island point on each of them could be considered as how the roadways are traffic-calmed. But traffic_calming=island becomes a physical feature, not functional.)
Features should be “type-agnostic”. Don’t make the use on different object types have a different interpretation. If traffic_calming=island + area=yes is accepted, should standalone traffic_calming=island points or lines as an initial level-of-detail physical thing be accepted as well?
And then there’s the question of crosswalk refuge islands, from Example 2. There are some opinions about traffic_calming=island being unsuitable for =crossing , where there is already crossing:island=yes . How should this differ by object type, or functional vs physical features?
The better direction would be eg area:highway=traffic_island + traffic_calming=yes (treat as attribute, not unspecified or double-tagged feature) / traffic_island=traffic_calming / traffic_island:traffic_calming=yes
traffic_calming= has many more issues. Semicolon multival is not good for features, nor is fusing new vals viz =choked_* a scalable and simple solution. How to indicate a device only affecting 1 direction, or certain lanes?..
I think one thing doesn’t nullify the other. In this case you mention, mind you that when an island is drawn as an area, the road is split because there’s a physical separation in the middle. This may not be the case in some countries, but it’s true in others.
So, if you want to map a traffic_calming as a node in the road line, that’s fine, but the tag should be also applied to areas, like those islands that divide the road in two, like in these cases:
About the function, I believe that the rule of OSM is to map as it is on the ground, not as you want to map to influence function over an object. That is mapping for the render.
The routers and all must adapt to those features, just like anything else. A road with a traffic_calming already has others features, like humps, maxspeed, access, living roads, traffic lights, crossings, etc. You don’t need to transform an island into a point just to give meaning to it.
About the adequate way to tag, I just pointed out that more that 40.000 uses of area=yes shouldn’t be disregarded as it was in this case.
Btw, I just noticed that iD is correcting the traffic_calming=island + area=yes with area:highway=traffic_calming. Shouldn’t it be area:highway=traffic_island?
2 Likes
How does this have anything to do with renderer??? The function of traffic_calming= is traffic-calming. If you apply them to other cases, you diluted it, making it less useful.
For the ground reality, physically it is an island. You don’t need to say it’s “traffic-calming” either. Most commonly, divided roads may use area:highway=traffic_island (ignoring any technical and legal difference between “traffic island” and central reservations), but they are not traffic_calming= , but for high-speed traffic.
A router can’t “adapt” if you add them as unroutable unlinked standalone areas. That’s also against the conceived use of traffic_calming= in the original proposal, and on other traffic_calming= features.
For your new example 1, as I said, the problems are whether =crossing points with crossing:island=yes should get traffic_calming=island , whether this should be different for areas, and how to explicitly show there is a traffic_calming=island on the pair of highway= + oneway=yes road lines.
For new example 2, it’s more complicated on roundabouts. While splitter island deflection could slow down traffic, sharp radial entries promote low-speed more than tangential entries. This is affected by flaring to widen the carriageway for more entry lanes in especially UK.
Thanks for bringing this discussion over to the id-tagging-schema repository:
I don’t want to go on in circles here, but the fact is: if you map something that exists as an area on the ground with a point just to give it meaning or affect the routing algorithms, I consider that a mapping for the render. I agree that it’s difficult to convey meaning to a way from an area or node outside that way (as it happens with traffic signs), but you’re defining specific situations based on the judgement and knowledge you have of your local reality, where for me they’re traffic calming and that’s why they exist on the ground, no matter the particularities of each one. There are numerous cases of these type of islands (even the wiki page has an image with this kind of islands). Are you going to define yourself which ones are traffic calming or not, even though the local legislation calls them that?
Anyway, I can settle for that and I won’t argue against. For me, mapping them as area:highway=traffic_island is just fine. I don’t see the need to consider them traffic_calming at all.
1 Like
Your “fact” is the same as saying drawing roads which exists as areas of roadways in reality, as lines in OSM, is “mapping for the” router. Is this true? As a side note, the better wording is “lying”. adding false info for the purpose of being considered by a software. There are no lies here.
The difference is functionally they are linear. Physically, they are areas. The use of traffic_calming=island + area=yes conflates these two concepts, as traffic_calming= is a functional feature. All other devices are drawn on the linear highway= road.
I don’t see which photo you are referring to in Key:traffic_calming - OpenStreetMap Wiki proper. Yes, File:Trafficcalming-island.jpg - OpenStreetMap Wiki in the Tag:traffic_calming=island - OpenStreetMap Wiki template is traffic-calming, But one of the issues I talked about is the use of crossing:island=yes vs traffic_calming=island and its implications.
What laws defines “traffic-calming islands”? I’m suspecting it’s a mistranslation. If everyone agrees they are traffic islands, using area:highway=traffic_island is the simplest solution reflecting the reality. There’s no need to add more complications.
1 Like