Proposal:Tagging for complex junctions or traffic signals that are named
| Tagging for complex junctions or traffic signals that are named | |
|---|---|
| Proposal status: | Canceled (inactive) |
| Proposed by: | sommerluk |
| Rendered as: | Render the name (where appropriate also with an icon for traffic signals) |
| Draft started: | 2014-08-23 |
| RFC start: | 2014-08-24 |
| Vote start: | 2014-09-28 |
| Vote end: | 2014-10-12 |
Introduction
In some countries, people orient themselves in the local area using the names of road junctions (Korea…) or traffic signals/traffic signal systems (Japan…) rather then the names of streets. In other countries (Poland...) some big junctions (usually dual carriageways) are named. While street names also exist, they are not important for orientation.
While this feature is useless in most countries of the world, it is very important in some other countries – even more important than street names!
Expected rendering
For junction names (Korea, Poland), it is expected that the name is rendered (horizontally). For traffic signal names (Japan) it is expected that the name ir rendered (horizontally) together with an icon for the traffic signal.
It is expected that the name is rendered in the middle of the junction.
It is expected that the name is rendered only once for each junction.
Current status of this feature
Simple junctions
This feature is yet implemented with name=* combined with junction=yes and/or highway=traffic_signals – applied on a node! (If both, junction=yes and highway=traffic_signals are present, the name is interpretated as name of the junction.) See “Named spots instead of street names” for details. This tagging is widely used in the concerned countries – particularly Japan and Korea. At openstreetmap.org (openstreetmap-carto) this feature is rendered. The current practice has clear rules for simple intersections: You will tag the node that connects the two ways. This is accepted by the community and works also well for software developers (both rendering engines and routing/turn-to-turn navigatin engines). No change is necessary for simple junctions.
Complex junctions
Junctions can be quite complex, with many lanes, with many separated carriageways and with many traffic signals. Just consider the example at the right. Currently there is no clear tagging rule for this type of junctions. All these traffic signals of a junction together are a “traffic signal system” (=a set of traffic signals that work together). In Japan, this traffic signal system as a whole has a name. But currently it is not defined how to tag correctly this type of junctions or traffic signal systems.
Proposal
For simple situations, the current situation is fine. We should continue with the current practice.
However, we should have also add a tagging for complex junctions/traffic signal systems. It seems reasonable to have the same sort of solution for both junction names and traffic signal system names – in the end it is the same feature. In addition, because this feature is used only in a small part of the world, developers will not probably not invest too much time in it – this is another reason to have the same type of solution for both. We should have a solution that is easy to use for the contibuters of OSM. At the same time, the solution should provide the necessary data for rendering engines and routing/turn-to-turn navigation engines. The solution for complex situations should be well compatible with the yet existing solution for simple situations.
| Named road junctions (e. g. Korea) | Named traffic signals (e. g. Japan) | |
|---|---|---|
| Tagging? | To map complex junctions (Korea) we draw an area (a closed way) around the junction area. The area is tagged with junction=junction_area (and name=*). | To map complex traffic signal systems (Japan) we draw an area (a closed way) around the area that is controlled by the traffic signal system. This area is tagged with highway=traffic_signals_area (and name=*). |
| How to draw the area? | The area shares nodes with the the incoming and outgoing highways and (if applicable) footways, so routing/turn-to-turn navigation engines can determine which highways and (if applicable) footways are concerned. To define clearly what belongs to the area and what does not belong to the area, we require for the shared nodes (shared between the area and the incoming/outgoing highways)
| |
| Layer? | Mostly, there is no need for a layer. In the rare case that there is for example a tunnel (subway or even street) passing below a junction and not belonging to it, these highways would of course not share nodes with the junction area. It may be useful to add layer=* (doing it the same way as for the area as for the affected highways). | |
This is an simple and intuitive approach. It is easy to create this tagging with iD or JOSM. Routing/turn-to-turn navigation engines that want to support this feature can determine clearly which highways are passing through a junction or a traffic signal system.
The usage of the complex tagging scheme (areas) may also be useful without a name. Think of a routing/turn-to-turn navigation engige that can give instructions like “at the second crossroad turn to the right” or “at the fourth traffic signal turn to the left”.
Special case: How to map a different junction name and a different traffic signal (system) name on the same place. This seems to be an academical case rather than a real case on the ground. However, in this situation we can simply draw an independant area (closed way) for the junction; this area is simply drawn around the traffic signal (system) element.
Theroetically, the tagging scheme for highway=traffic_signals_area allows that additionally to the area, the individual traffic signals can be tagged as usual on nodes with highway=traffic_signals. These nodes would be located within the area. (Almost always, the individual traffic signals have the same name as the hole traffic signal system – if so, we do not use a name tag. In the very rare case that the individual traffic signals have a different name, it might be useful so set a name=* tag). We do not forbid this strictly because it makes sense to keep this door open for the future. However, we recommand currently not to do so because we expect one single icon rendering in japanese maps and currently it may be difficult for rendering engines to filter out the duplicates. So best practice for Japan is to use only the area.
Voting
I approve this proposal. --Sommerluk| 14:45, 28 September 2014 (UTC)- I approve this proposal. Although I don't see a reason why this should only be used for named junctions. If - for any reason - one wants to group together all the elements of a junction, why not use an area with junction=junction_area without any additional tag? --Imagic (talk) 15:08, 28 September 2014 (UTC)
- I approve this proposal. A necessary solution to a problem of missing data in Asian maps. --Javbw (talk) 21:33, 28 September 2014 (UTC)
I oppose this proposal. for the named traffic signals. You will always find cases where drawing a simple area will not be possible or easy. A more generic solution would be to create a relation - e.g. type=traffic_signals - grouping the synchronized traffic signals and put the name there. Btw, a proposal already exists. --Pieren (talk) 09:48, 29 September 2014 (UTC)
- It will IMHO become difficult when you want to have named 'junctions' (not traffic signals) in a relation. How could routing/turn-to-turn navigation software use this data? Probably you would have to do something like tagging all “crossing” nodes in order to allow to a routing engine to process the data. And the relation is probably quite difficult to maintain. --Sommerluk| 18:26, 29 September 2014 (UTC)
- "You will always find cases where drawing a simple area will not be possible" - can you provide an example? Mateusz Konieczny (talk) 06:08, 11 October 2014 (UTC)
- I oppose this proposal. What's the point of having two different tags (junction=junction_area and highway=traffic_signals_area) to represent the same thing (a junction of some sort)? A more generalized tagging scheme that could cover all possible use cases, not just those in two Asian countries, would be much more beneficial to the OSM community. --Alester (talk) 17:11, 29 September 2014 (UTC)
- The point is that in one case you have a 'junction' name and in the other case you have a 'traffic signal' name. And we expect also a different rendering (junctions just with their name, while traffic signals have an icon).
- Concerning the usage outside of Asia I agree with you. While the proposal comes from an asian background, it is not restricted to Asia and will work also elsewhere. --Sommerluk| 18:26, 29 September 2014 (UTC)
- I approve this proposal. I think this would be helpful to prevent rendering junction names multiple times. Math1985 (talk) 12:54, 30 September 2014 (UTC)
- I approve this proposal. nyampire (talk) 02:26, 05 October 2014 (UTC)
- I obstain this proposal. I see the need and see the solution working in maps, though it might be important to improve the relationships with other features that are included in and just close by when moveing toward useing it in areas where the junction is over, under or inclosing other features (some junctions in the world are very large). Another issue could be how easy it is to use with software linking logicaly with just the connecting nodes on the "routing ways" (a term for the centre pathing line when the road parts are also described with areas too: in non area parts such as the examples given, read "routing ways" as the normal road lines). It would be good to intergrate this proposal with the other area-highway schemes as they could be used in conjuction.
- A solution could be done by a relationship to unite the joining nodes (on the routing ways), the new junction area given here (needed to help discribe the scope of the labeling with the junction name) and any defined highway areas (or relatable features (like islands and verges)). With such a relationship being added the machine comprehendability is greatly improved for a more automated or data-centric OSM use where the map isn't being rendered for humans to read.--Govanus (talk) 17:48, 6 October 2014 (UTC)
- I oppose this proposal. I really like this proposal, but I just noticed problem: "simple" and "complex" junctions will be tagged differently. Why not use "junction=yes" also for complex ones instead of new junction=junction_area? BTW, I just noticed that some named junctions exist in Poland (in fact, I was trying to mark one). Mateusz Konieczny (talk) 06:07, 11 October 2014 (UTC)
- The first draw was indeed using the same tag for simple and complex junctions. However, during the RFC time, it was discussed on the tagging mailing list that it would be better to have a separate tag (software compatibility, specially quality checkers…). Furthermore it gives the possibility to clearly define that the area in OSM corresponds to the area on the ground, with clear rules how to connect the area with the crossing ways – a concept that is a little different from the concept of the simple junctions.
- Is it even possible to have named junction marked as node (simple) inside complex one marked as an area? Mateusz Konieczny (talk) 20:25, 15 October 2014 (UTC)
- The first draw was indeed using the same tag for simple and complex junctions. However, during the RFC time, it was discussed on the tagging mailing list that it would be better to have a separate tag (software compatibility, specially quality checkers…). Furthermore it gives the possibility to clearly define that the area in OSM corresponds to the area on the ground, with clear rules how to connect the area with the crossing ways – a concept that is a little different from the concept of the simple junctions.
Voting was 5 times “yes” and 3 times “no”. I’ll revise the part for the traffic signals, considering the comments made here and at the mailing list. A new proposal will follow. Leaving this proposal here as “Canceled”. Sommerluk (talk) 20:25, 21 November 2014 (UTC)