area:highway=* is additionally used to describe the shape of linear features tagged as highway=*.
But traffic_calming=island isn’t a highway=* tag and also it’s already possible to map it as an area, so I don’t really see the point of it in this specific case.
EDIT: By the way, I also found this: Tag:traffic_calming=painted_island… It’s so confusing, also because all these elements aren’t linked to each other in the Wiki. I added a reference to them in the Tag:traffic_calming=island “See also” section.
As far as I can tell, the tag is only being used for islands that are physically raised, but also have an additional painted area around them. This explains why the two carriageways are split at the point of the traffic island.
@ ivanbranco: I just read this discussion. Some comments to your questions:
I use traffic_calming=island together with barrier=kerb (and kerb=* to specify the kind of the kerb like lowered/raised/rolled) already since a longer time.
The wiki page for kerb=* could really be improved IMO (the text is too much focussed on the use for single nodes e.g. on crossing ways). For me, it’s generally a subtag of barrier=kerb to specify the kind of a kerb. The use on single nodes is a special case or only one case.
I also use barrier=kerb + kerb=* on nodes (e.g. of crossing footway), often together with tactile_paving=* to complete it. (Yes – I prefer to use also barrier=kerb PLUS kerb=* on nodes, although it’s not described on the wiki page of kerb=* – but it IS a barrier=kerb, why should it not be tagged in this way? For my feeling, it’s more complete with barrier=kerb.)
The case of a traffic island area with barrier=kerb + kerb=* and crossing footways with nodes tagged with barrier=kerb and kerb=* on the border of the island is quite common for me. Of course, the values of kerb=* should correspond in this case.
The tagging on nodes can be useful for routing applications for disabled people for example (or it can make it easier to issue warnings for such applications exactly on these nodes) and rendering engines can display a special symbol on these nodes. On the other hand, rendering engines (and editors) could use a different rendering of the outline of a traffic island depending on the kerb (or no kerb).
I think, that traffic calming islands (when used for areas/closedways) can be a quite special case of “double feature tagging” or even “triple features tagging” on the same closedway line, if you consider traffic_calming=*, barrier=* and landuse=* as (also) standalone features for ways/closedways. But if you draw separate/duplicated (identical) lines to tag these feature separately, this results in validator warnings (e.g. Osmose).
And some questions are arising. E.g. is it better to use landuse=grass or surface=grass (or even both)? Surface=grass might fit better at first glance, because it “avoids” one “double feature tagging” in the sense mentioned above (and there can also be cases with surface=paving_stones|asphalt|sett…!). But on second glance, there could also be landuse=greenery or landuse=flowerbed or perhaps natural=shrubbery and other values (scrub? wood?) on a traffic calming island (and surface values for these cases are not established). So landuse (or natural) might need to be used anyway … With the side effect, that landuse=grass is rendered on OSM Carto, and surface=grass not – only to mention this, too (and traffic_calming=island areas with no other tags are currently not rendered at all on Carto – not very nice).
As I have experienced, dealing with this type of “double/triple tagging” can potentially be a challenge for editors or rendering engines. The current support in editors (I use JOSM and Vespucci) is perhaps not the best … But it should be possible anyway. I did already enhance the presets and data styling for JOSM and Vespucci for my personal needs. (And I ran into a few obstacles along the way.)
For the question what to tag/draw if there are markings around a (solid) traffic island: I would draw/tag only the solid island, because this is the island, and the paintings around it are additional markings (like other markings on a street). If it’s a painted island, I would also draw the area around the painted part, not any markings around. But I never tagged such an island so far, I tagged (and saw) only solid ones. (Note: for pedestrian crossings, there is a new tag crossing:markings=*, something similar could perhaps also be used/invented for traffic island if micromapping needs to be refined.)
And you’re right … it’s somewhat confusing (specially with the wiki) in such a case and not straightforward, which you might not expect with a traffic island.
Perhaps a proposal covering all these cases and questions wouldn’t be bad for clarification …
Yes, that Wiki page is a mess. I’ve volunteered to improve the page, so I recently started two discussions here to get community feedback and find all the missing uses of barrier=kerb and kerb=* that were not documented in the Wiki: [1], [2]. My summary of what was missing from the Wiki pages is in this post. From reading your comments, I think my understanding aligns with yours. If I’ve missed anything or you have any comments, please let me know in the thread about the Wiki page.
I updated the page for barrier=kerb with the results of those discussions yesterday, and I hope to make the agreed updates to the page for kerb=* in the coming days.
I’m not sure I understood what’s the current situation. traffic_calming=island should be changed with area:highway=traffic_island while for traffic_calming=painted_island there’s still no consensus between area:highway=traffic_island, area:highway=emergency and area:highway=buffer? Is this correct?
Neither! This should not be tagged with traffic_calming=* at all. Mentioned structure does not impose calming the traffic. Use area:highway=traffic_island instead.
traffic_calming=* was meant to be used as nodes or ways ONLY. It was thought to mark roads, or points on roads with features that are designed to slow down traffic. This is reflected in the Wiki as well as in the original proposal (approved).
That means, that traffic_calming=island should be used only to mark traffic islands that somehow make the cars need to slow down. For example by having them to ‘slalom’ around the island (kind of a traffic_calming=chicanes but with just an island in between the lanes). SV Example.
That also means, that areas (and nodes in case of non-traffic-calming-islands) marked using traffic_calming=island are making the tag skunked.
For areas there is area:highway=* tag from inactive proposal, which is still widely used.
for the ‘striped painted islands’ there is area:highway=emergency or area:highway=buffer (no consensus)
I am against usage of traffic_calming=painted_island as it doesn’t make the cars go slower, drivers can go straight through souch features.
for the ‘any island that is made of something different then the road and probably raised’ there is area:highway=traffic_island.
Updated the PLwiki to be coherent with ENwiki (diff)
Added photo of traffic island to the original proposal of area:highway=* (diff)
Changed the name of iD preset, which since Nov 2020 called traffic_calming=island by “Traffic Island” which I think is misleading. Name was changed to “Traffic Calming Island”. (#1074)
OsmAnd has a feature where it warns drivers about incoming traffic_calming=*. Marking non-traffic-calming-islands using this tag leads to false-positive alerts. (source)
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:
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
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?
