Proposal:Through route

From OpenStreetMap Wiki
Jump to navigation Jump to search
through_route
Proposal status: Rejected (inactive)
Proposed by: pointdee
Rendered as: N/A
Draft started: 2013-04-13
RFC start: 2013-04-29
Vote start: 2013-05-28
Vote end: 2013-06-11


Proposal

This is a proposal for a new relation to describe a routing situation whereby at a junction the way layout is ambiguous or local conditions make it impossible for routing software to reliably determine whether a turn direction is needed. This proposal will remove this by providing the extra information needed at such junctions.

Rationale

Currently any routing software based on OSM data has the limitation that in some circumstances turn directions will not be given when they should be, or will be given when they are not needed. This is obviously frustrating to the end user and creates a bad impression of the data as being incorrect when it is actually correct it is simply that the way layout is such that routing software cannot automatically, reliably determine whether turn directions are necessary at a junction. The proposed through_route relation removes this inaccuracy

Example

Consider this situation. If you are heading north on the A56 and want to continue on the A56 then you need to turn off the main carriageway or you end up on the A682. Currently any routing software based on OSM data will not tell you to make a left turn and consequently you end up travelling on the wrong road to the wrong destination. There are hundreds of similar situations throughout the UK and Western Europe (and presumably globally) ranging from major highways to much smaller residential streets. The term TOTSO to describe this is already used in the UK, Netherlands and Germany (Wikipedia).

It says follow A56 - and if you do that, you will turn off to stay on the right road according to signage.

Tagging

This new relation (type through_route) specifies which 2 ways are the "through route" at a junction i.e. which way local conditions dictate that the way continues. The relation requires 2 ways (no role required) and a node with role = junction. It should only be used at those junctions where the through route cannot be reliably inferred from other information. Using the junction above this would have the following

 A     B
  \    |
   \   |
    \  |
     \ |
      \|C
       |
       |
  A56  |
       |
       D

Route DCB is the through_route yet DCA is the A56 thus the relation would have

key=type, value=through_route

way DC

way CB

node C, role=junction

By tagging the junction in this way routing software can now be made aware that in order to continue on the A58 a left turn is needed and similarly that to proceed onto the A682 no direction is needed as this is the through_route.


This interpretation of 'through route' relates to road number. What if someone else's interpretation of 'through route' means be guided by white paint ?

Other considerations

This proposal is not concerned with priority/yielding/give way or any other similar mechanism it is about alerting routing software to the through_route when this is ambiguous.

I believe that this proposal was originally mentioned on OSM IRC approximately 3 years ago and as a result of this the relation is already currently in use but not documented. The junction mentioned above is an example of the relation in use. Taginfo shows that this relation has seen limited use already but this is most likely to be due to the undocumented nature of the relation. This has no effect on renderers but obviously routing software would need to be made aware of the relation in order for the improvements in routing directions to be realised

Comments

Please use this page for any comments. If possible please give real-world examples of the situation you are describing. They say that a picture paints a thousand words.


Voting

Please use {{vote|yes}} or {{vote|no}} and give your reasons for opposition. Use ~~~~ to sign your user name & date.

  • I approve this proposal I approve this proposal. --AtomMapper (talk) 00:44, 29 May 2013 (UTC)
  • I approve this proposal I approve this proposal. --Pointdee (talk) 17:23, 28 May 2013 (UTC)
  • I approve this proposal I approve this proposal. --Csmale (talk) 17:55, 28 May 2013 (UTC)
  • I approve this proposal I approve this proposal. A couple of minor issues though: I think it might have been better to use 'via' rather than 'junction' as the role for consistency with turn restrictions. I also think we also need a clearer definition of "through route" (and perhaps some photographic examples) to avoid confusion. My interpretation is that it is the route that you would take (usually indicated by the road / lane markings) if you didn't explicitly turn off the main carriageway you were on. Some indication of when it isn't necessary/useful to use the relation would also be helpful (i.e. it doesn't add anything to most junctions where the through route is already implied by the tagging on the radiating road arms). -- Rjw62 (talk) 18:26, 28 May 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Documentation needs to be clearer. Needs photographic examples, or a much more thorough explanation of the problem it's intending to solve, with specifics. Ideally involving the A56 example, which I just don't understand. What instruction would this scheme cause routing software to emit to a driver, and why? Echo what Rjw62 said regarding when not to use this relation. Agree that "via" is better. The voting system is broken and you can treat my "no" as a "yes" if you like, or just treat it as approved right now. However I think the idea expressed here needs to be clarified a lot, otherwise people just won't begin using it. --achadwick (talk) 18:50, 28 May 2013 (UTC)
  • I approve this proposal I approve this proposal. I do agree it seems poorly explained and does need a better explanation. I do understand it from reading: http://gis.19327.n5.nabble.com/New-Proposal-td5759031.html previously and can see the need for this. Rovastar (talk) 20:16, 28 May 2013 (UTC)
  • I approve this proposal I approve this proposal. -- Escada (talk) 05:17, 29 May 2013 (UTC);
  • I approve this proposal I approve this proposal. -- But I agree that a more detailed explanation is needed in the final page. --Viking81 (talk) 07:39, 29 May 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Why you did not try to enhance the existing junction relation ? --Pieren (talk) 08:57, 29 May 2013 (UTC)
  • I oppose this proposal I oppose this proposal. +1 with Pieren. Too much proposals about routing on this wiki and a lack of consistency. -- Fanfouer (talk) 09:21, 29 May 2013 (UTC)
  • I approve this proposal I approve this proposal. Extending junction relation for this is a stupid idea: those are used for different things. But I'm for using via role instead of junction. --Zverik (talk) 11:36, 29 May 2013 (UTC)
You should read the proposals before writing such stupid remarks. A junction is a junction. And here we have a routing problem through a junction. --Pieren (talk) 14:33, 29 May 2013 (UTC)
Pieren, so you propose resurrecting? a long dead proposal from 5 years ago...2008 that hasn't even been even attempted to be RFCd (presumably because it isn't good enough/ready yet/too complex already) to make it bigger and more complex rather than getting this simple change through?
The junction proposal is a different thing and 95% not needed as it most of those junction can be done via existing methods happily. I don't think that would ever get through an approval process anyway - I would not vote for it for one.
'If' you linked to a current active proposal or existing appproved element in the wiki that I would back you but you are not. You are linking to something the doesn't exist and say approve that.
That is not the best way of getting more needed information added to the OSM. Rovastar (talk) 22:52, 29 May 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Multiplication of tagging schemes is not helpfull. +1 for junction use. JB (talk) 15:24, 29 May 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Mapping for the router. When the router knows start and destination it should be clever enough to find its way and tell its user which way to go. I won't do extra mapping for insufficient routing engines. -- malenki 10:18, 1 June 2013 (UTC)
  • I oppose this proposal I oppose this proposal. The proposal has not been thought through at all. The proposed tagging provides near to zero benefits for routing programs. -- Eckhart (talk) 10:33, 1 June 2013 (UTC)
I think *you* should think through and understand the difference between routing and navigation. The routing decision may or may not be influenced by this tagging (possibly a small penalty for turning off at a junction) but the navigation (translating the route into directions for a human to follow) can be made more appropriate and less ambiguous in a way which simply cannot be derived from the geometry alone. --Csmale (talk) 17:41, 1 June 2013 (UTC)
  • I oppose this proposal I oppose this proposal. There is still a problem with connectivity which needs to be solved through a relation. In the example used (A56/A682) there is obvious connectivity, so no relation needed. turn:lanes=* (missing), destination=* (missing) and a trunk_link (missing) will do the job in the example. Please rework the proposal to include non-obvious connectivity --It's so funny (talk) 21:35, 2 June 2013 (UTC)
the possibility of using the lanes tagging has already been discussed and dismissed as it does not fit this case. There are multiple possible destinations in the given example so I don't see how this would work and there is no trunk_link as this is a junction of trunk roads. Thanks --Pointdee (talk) 21:47, 4 June 2013 (UTC). The discussion on lanes has been updated by me. I miss the point why turn:lanes=* and destination=* should not be used in this case. --It's so funny (talk) 21:39, 5 June 2013 (UTC)
  • I oppose this proposal I oppose this proposal. I agree with user malenki. The routing program should be able to figure out which is the correct way to get to the destination. Gilbert54 19:33, 5 June 2013 (UTC)
Do you also not use no_left, no_right_turn etc as essentially the reasoning behind those is the same as the reasoning behind this--Pointdee (talk) 18:26, 6 June 2013 (UTC)
  • I oppose this proposal I oppose this proposal. 4rch (talk) 18:06, 25 June 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Oli-Wan (talk) 16:28, 26 June 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Brycenesbitt (talk) 01:49, 22 July 2013 (UTC) proposal is too confusing as written.
  • I approve this proposal I approve this proposal. I'm currently making use of a few junctions tagged thus, and finding it useful in practice - also useful for routing calculations where the major road gives way to the minor one at a crossroads. --tms13 (talk) 20:01, 20 August 2013 (UTC)
  • I approve this proposal I approve this proposal. Voting is over. Nevertheless I want to give my opinion. This relation is necessary for routers to determine whether to say "turn left/right" or "follow the course of the road". However, I would permit more than 2 road segments in the relation, and it should not contain nodes. Additionally, driving direction should be considered. I suggest "forward", "backward" and unnamed members as in route relations. --Fkv (talk) 09:13, 23 September 2013 (UTC)
  • I oppose this proposal I oppose this proposal. Good idea, but incomplete. Such a relation should indicate for each pair of ways wther it feels like left/right/straight.

Comments on currently in-progress voting

Some of the comments mention that the documentation for the the proposal needs improving. I will try to add to the proposal below.

Some of the comments mention tagging for the router and no benefit to routing engines but really the reasoning behind this proposal is the same as that behind the no_left_turn, no_right_turn etc relations. In a no_right_turn situation how is a routing engine to know that a right turn is not permitted? In a through_route situation at a junction in the road how is a routing engine to know which of the carriageways requires you to turn onto it?

I'm happy to bring this in line with other similar relations and use via instead of junction for the node but was trying to avoid reworking what has already been done Taginfo. Maybe someone with skills greater than mine can update those already in use .

My artwork skills are not as good as some on the wiki but nevertheless consider the junction given above (link) which is involved in routing from Ramsbottom to Huncoat as shown at OSRM. If you follow the directions given at OSRM you will miss the left turn at the junction in the example because as you can see there is no direction to turn left. This means that you will most likely end up in Rawtenstall. The situation on the road is as shown below

Through route.jpg

If you are heading north on the A56 there are two lanes. Both these lanes continue north and become the A682 at the point of the junction. There are no road markings to indicate that the left hand lane is a deceleration lane or that it is to be used exclusively for those turning left. In fact road markings show that the left hand lane is for both straight on and turning left (BingSat). Additionally none of the roads involved are trunk_link roads. In this situation routing software cannot determine that in order to continue on the A56 you need to make a left turn as the software will (incorrectly) determine that the A56 is a continuous carriageway which in reality it is not. Marking the junction with a through_route relation removes this problem.

This is not a fault in the routing software and is not limited to OSM based data as Google also gets the same junction wrong in the same way. The problem is that the situation on the ground cannot be reliably determined just from the way data in a similar way that routing software cannot reliably determine that it is not permitted to use a left/right turn at certain junctions hence the existence of the no_left_turn, no_right_turn etc relations which are accepted and widely used.--Pointdee (talk) 18:41, 6 June 2013 (UTC)