Proposal talk:Relation:type=route instruction

When you post or reply to an argument, don't forget to sign it by typing ~~~~, this ensures discussions remains understandable. Thanks.

Hmmm, this all looks overly complicated to me. My guess is that most of the information trying to be entered here actually can be derived from the topology. -- Ulfl 18:23, 24 January 2009 (UTC)

I beg to differ here. What difference, topology wise, do you see in the first example I gave. If there's no difference, how can the routing instructions be different ? Pov 18:54, 24 January 2009 (UTC)

Looking at your first example. The one you labeled "take the next exit". It is a road with two lanes and then there is an exit to take. The other one ("stay on the right lane") it is a road with three lanes and only one of the three lanes is going where you want. So those two examples should have no problems and don't need an extra relation. The same is true for your more complicated example, why tag something that can be worked out automaticaly? --Ckruetze 22:45, 24 January 2009 (UTC)

Lets say you're right in the first case, but that still means you have to enter the number of lanes of each and every segment of the ways and be lucky that the topology makes you deduce the right side for the right way. In the second example though, as the number of lane is changing there is no way to compute anything, you still need additional information that this relation provides you. Pov 23:38, 24 January 2009 (UTC)

You are right, the information which lane goes where is needed in the second example. The to_n_directional_sign thing might also be very usefull. There are some 3D Navigation devices out there that display this information, but the to_n""_phonetic_direction is not usefull I think. First of all, how many roads are there that would have a signe saying Paris or Hamburg, do you want to include the IPA thingy on all of them? The second problem is, just because I hear something pronounced in French, doesn't help if I don't speak French, I would need it pronounced in German or English to be usefull for me. I would suggest leaving the pronunciation to the program that wants to do it.--Ckruetze 19:24, 25 January 2009 (UTC)

Well, the IPA thingy is optional but I think it might be a good idea to have it even if we don't use it much. At least because place names often have odds pronunciation and it would avoid tts engines to sound silly :) But it would also make sense for a guiding software to have an option to disable local pronunciation and use the user's language one. My idea here is to avoid limiting ourselves at the beginning to "keep it simple", and later on realize we should have kept those extra features because we miss them.

The examples given are not the best that could be used, as you could split the way to change the number of lanes in the road and get a similar effect. A better example would be on more minor roads where you have a T junction, the general flow of traffic is across the top of the T, however each half of the top of the T has a different name, with the name of one of the halves of the top of the T being the same as the stalk of the T. College road between Crystal Palace and Dulwich (London) is a great double example of this: [1] Smsm1 01:05, 25 January 2009 (UTC)

That's an example of a very unclear situation. Do we need an additional instruction here or not? That totally depends on the routing software using the OSM data, and the difference between the data and the reality. In most cases a router could generate proper instructions. So IMO your example is not better, as I doubt every T crossing needs driving instructions. SvenR 10:49, 25 January 2009 (UTC)

Because not every intersection needs it doesn't mean that no intersection needs it. And some certainly do. Of course most intersections can be deduced from the topology, but some don't and we need additional information that this proposal is (I think) able to provide. Look at GDF, which is the de facto standard for geographic data, routing and topology are stored in two distinct forms because they're two different kind of info.

The whole idea behind this proposal to cover the edge cases. In one 50 mile cycle I found at least 4 t-junctions whereby routing engines would have the problem I explained above. If you could produce some diagrams for this, it would be really useful. I think that it would be good to have lots of different examples, rather than just small variations on one type of junction. See we do need an instruction here, as Smsm1

How is this done in other apps and databases?

I wonder how this is handled in other routing applications and maps? E.g. TomTom seems to base "turn right" or "bear right" on the angle of the road. I would guess it does the lane changing by storing number of lanes, as discussed above. This means it's sometimes wrong or confusing, but works fine maybe 90% of the time.

However, if the GDF standard uses it (see here too), it's probably for good reason and worth adding to OSM somehow. But again, I don't know how GDF implements what this proposal is aiming at. --LeedsTracker 17:50, 3 February 2009 (UTC)

I took some time to read the relevant parts of the GDF spec. GDF doesn't store the information in the same way I propose we do. But here's what it does. First there's two level of data, one for the geometry that precisely describe the ways configuration (for map drawing, gps/way matching) and another one for the routing which only stores a graph of the road junction. In the geometry layer, ways are composed of linear segments with attributes attached to the whole way or only segments with a distance from the start of the way and a length, or points with the distance from the start of the way. Junctions can be (optionally) normal, a mini_roundabout, a bifurcation or a border. Then there can be direction signs along the way. And that's pretty much all there is in terms of directions. Pov 22:14, 3 February 2009 (UTC)

Please make it as similar as type=restriction as possible !!

That means :

• Every instruction will have it's own relation
• Spell out how ambiguities are handled. For example, if ways A and B make a 4 way junction at a mini-roundabout C, there are 16 different maneuvers that may each have it's own instruction.

Lastly, a single maneuver may require multiple realtime instructions, each uttered at a different distance from the junction. -- Nic 18:28, 3 February 2009 (UTC)

I agree it shall be as similar as possible to an existing stucture, but as the restriction system does not work for U-turns, I prefer the relation enforcement schema. --Lulu-Ann 13:16, 3 January 2011 (UTC)

Model lanes instead?

So I see the problem, but I don't think this is necessarily the best way to tackle it. How about concentrating on the physical attributes on the road? So you could use relations on a way that said "from this way, lane 1 goes to this exit ramp" "from the same way, lanes 2 and 3 go to next bit of the motorway". At that point all the directions can be figured out. Your list of possible values is too limited - think of 7-lane wide interstates. Gravitystorm 20:12, 3 February 2009 (UTC)

phonetic direction

I don't think it is a good idea to put phonetic information into a route instruction, because they would have to be copied to all other route instructions with the same target. Considering that the "target" is usually something that can be found on the map, the target could be included as a relation member and any phonetic information be put on the target itself. You'd probably also need phonetic information for different languages, which is another reason why we should try to avoid copypasting -- you'd end up with some instructions translated, others with the same target partly translated... --Tordanik 11:30, 8 February 2009 (UTC)

I think you misunderstood the purpose of the phonetic direction. The goal is not to store sentences that would be a simple copy of the machine readable tag to_n_instruction. It is there to store the pronunciation of the city/landmark names you can see on the signs above/along the road and which is stored in to_n_directional_sign. Hence no need for internationalization. It's useful because oftentimes city names have a "funny" pronunciation that you can't deduce using the rules that generally apply to the language spoken in that country. Pov 14:20, 9 February 2009 (UTC)

I'm just suggesting to put the pronunciation of the city/landmark names onto the cities/landmarks instead of each and every route instruction. The internationalization thing was just an additional remark (a German might prefer the German pronunciation of "London" even when using UK roads). --Tordanik 15:13, 9 February 2009 (UTC)

This raises an interresting point. First, about the pronunciation, while I agree it will be different in different languages, I'm not sure that's what we want. Let met explain. If the direction sign says "London", I wouldn't want it pronounced "londr" in French, just because that's how we French call the city of London. It makes sense in a message like "take the motorway to go to London" for the city's name to be localized, but it doesn't if the instruction is to take a direction according a direction sign. Because in that case you want the name to match what's on the sign. Then there's the problem of duplicating the information. Unfortunately while for some signs we could devise a way of linking to the city place node itself, some signs list several names. In that case I don't image linking to the cities is a practical solution to the problem. Then there's also the problem of multi-lingual countries. I remember while I was driving through Belgium to go to Paris, I had to drive through the French town of Lille. In the north of Belgium, they give directions using the Belgian name of the city while in the south they list it by its French name. There's no way to compute/guess/"compress" that information unfortunately. So while I'm a big proponent of not duplicating info as much as possible, I think this is one of the few cases where there's no other solution. --Pov 21:31, 9 February 2009 (UTC)

Pronouncing "London" as "londr" is probably not a good idea in this case, but I have seen signs in other countries where I wouldn't be able to match the sign to the local pronunciation. An easy example would be "Paris", I don't speak French, but I think in French when you pronounce Paris, I won't be able to hear the "s". The road sign "Paris" ends with an s and whatever the navigation device just told me doesn't sound like anything ending in an "s", so it can't be the same city...

Now try this with even more complicated names in more complicated languages and you see why it won't always help to pronounce something in the local language only.

I have no problem with adding information on how to pronounce something, but please don't add to every single road sign leading to Paris pronunciation information in 50 languages...

Even a relationship isn't needed here. If the road sign has the letters “P a r i s” on it should be possible to look up in another table how to pronounce that in language x. If that table should be in OSM or somewhere else I don't know. Maybe there is already a table like that somewhere on the internet. --Ckruetze 18:56, 10 February 2009 (UTC)

Ok, then we assume that the routing program does it by itself and only reproduce the sign's text. Or shouldn't we leave it in the spec and say that it's up to the routing software programmer/ routing software user to decide if he wants to use it or not? Pov 14:24, 11 February 2009 (UTC)

Is the pronouncitation very important in the case above ? For Paris, I pronounce "Pâri" (I'm french) and for London : "Londre" (the final 's' of Londres is not proonouced). But if my routing engine is set in my language, it would probably make the same mistake than me, the engine will read "Paris", "London" in the database and will pronounce "Parisss" (for an English setting), "London" (for a French setting) in its set language. (OK "London is not very nice to ear). I will ear "Parisss" or "London" in this language and I will read "Paris" or "London" on the sign, whatever is the language. So is it very usefull to ear "prendre la sortie Londres" when the sign indicates "-> London" or "Way out to Pâri" when the sign says "-> Paris".

An other example : I'm unable to read "Tokyo" in Japanees, and whatever is the phonetic in the database, i'm unable to recognize it on the sign. So, how can I manage "way out to Tokyo" when the sign says "-> #@%" ? (sorry, I can't write it in Japanees).

And what about Liège (Belguim) where, on the same road, the name is writen on signs in tree langagues, French, German, Dutch, in few kilometers. The pronouciation will add a fourth way having, maybe, nothing in common with what I could see on the signs FrViPofm 09:17, 6 August 2009 (UTC)

Discussing is nice, search function is better: Proposed features/Phonetics already exists. --Lulu-Ann 12:23, 6 August 2009 (UTC)

Isn't it too complicate ?

I understand the question, am oftenly surprised by nav's messages which come too late for to react. But I'm not sure it's necessary to put those nav'details into the osm database. I thought that this were more a question to nav' programs, to analyze the map <-> where we go.

If I understand rightly this proposition, I would prefer a more general approach to the question. OSM does not stock information of where we want to go, it stocks information of what is. So, "no" please.

But, well, why not help the nav's to make life easier ?

One solution could be, that there were not just a node where we quit a highway or change direction, but that there were a strip of some length, to indicate where changement of lanes becomes important for the driver, or to get out. And leave it to the nav's, to tell the user : When two of such "changement ways" follow one another, speak differently...

This would need a special tag, and implies detailed mapping (nodes at beginning and at end of "out" or "change" lanes), Hereabouts where I live, are mostly rural roads, so I don't need such, but I can imagine situations in big cities, where this might be of importance.

I'm not convinced that the present proposition of relation could resolve the question, am sorry for my bad english, can not explain what I feel, but something sounds basically "wrong" with this relation, it seems contrary to constructive logic.

I fear that it would add new problems, more than it resolves, so I feel "no".

But the question itself remains... Gerhard 3 février 2009, au soir.

Finding examples to defeat the actual way of using lane/jonctions/ways

I'm still not completly sure all 3 examples are not solvable by using lanes number on the way, could anyone provide a counter example where something cannot be sorted out by topologie and/or lane, junction deduction ?

Taking the example n°3 (with A, B and C) possible direction, here is how I'll tag it :

3 case for a driver coming from A :

1) He wants to go to B Software compute the lanes difference between A and B ( 2 less). It finds you need to be on 1 or 2 lane left cars in europe (well, most ;-) ) drive right, and the 2 right lanes will go somewhere else.

2) he wants to go to D Both 2 left lanes keeps going on C because 4-2=2 software propose to stay on 1st or 2nd right lane before junction J1.

It computes that from C to D only one lanes continues (2-1=1) on D. Therefore, it will propose in the end : before J1 stay on 1st or 2nd right lane, after J1 but before J2 go to the left lane. ( With some more clever algos, it should fine the good lane is the 2nd right )

3) he wants to go to E Same way of computing, after J1 and before J2 it will propose to stay on right line, as it "knows" left line keeps is going to D -- whoops I forgot to sign Sletuffe

What happens if right at J2 there starts to be a new lane for ways D so D has suddenly two lanes. In your example 2-2=0 so there wouldn't be anything left for E. I'm sure there is a solution, I just can't think of it. --Ckruetze 11:11, 8 February 2009 (UTC)

If you look at the third example I gave, this is exactly what's happening. The lane number changes and ruins any attempt at computation. Pov 21:58, 9 February 2009 (UTC)

No, I don't think that's the thing I'm talking about. Let me try again. If everything stays as in your picture except from J1 on both B and C have three lanes each. How do you know which lanes to use? You don't know if two lanes go to B and B gets one new lane or if only one lane goes to B and B gets two new lanes. OK, it probably doesn't happen often, and I'm not sure if we need to care for it, but I'm just trying to find a situation where it is not possible without this tag. --Ckruetze 18:37, 10 February 2009 (UTC)

This is not my example, I was referring to the third example in the main page. In the C segment, the number of lanes changes. So while we agree on the cause/resolution we weren't talking about the same example. Or do you disagree ? I'm not sure... --Pov 14:28, 11 February 2009 (UTC)

The assumption that exiting lanes are on the right is incorrect, I know of at least one place where there is an exiting lane on the left: [2] (junction number 9 on A35). I think this can be quite frequent on complex exchangers. You could have one exit on the left, one exit on the right, sudden lane additions and the algorithm would be lost. Mappers should then be very careful that the sum of the lanes in outbound ways is always the same as the lane count of the inbound way at a split. Lane count changes should only occur when there is no split and exits (which do not change the lane count on the main way) should be treated specifically. This would be very impractical and error-prone. --Pshunter 23:18, 11 February 2009 (UTC)

Additional cases where this tag might be useful

Apart from the actual lane information, which might be worked out without this tag, there are other cases where this tag could be used.

I've seen several cases of signs like "In direction of Hamburg use left lane" and that several km away any junction. Just sometimes there is so much traffic that you should get into the correct lane now and not wait for the junction.

Also for a 3D navigation device the road signs could be displayed with this tag. See TomTom (picture 2). Several of the newer commercial car navigation devices display the road signs like they are on motorways. And personally i think that is a very useful information. --Ckruetze 11:17, 8 February 2009 (UTC)

Reverse the logic of the relation

I think this relation should be reversed. it’s not hard to leave a way, but tricky to go somewhere. It should be :

to: way (or node) you want to get to.

from_n: ways (or nodes) being left.

from_n_xxx: information on how to get there.

the _n_instruction tags are not necessary. I can’t find an example where a from_n_lane would not do the trick. For example :

A--------------------------- B---------------------------

  -  -  -  -  -  -  -  - 1-    -  -  -  -  -  -     1  -
                                               \
 ------------ - - - --------  ------------       --------
             \  2   \                     \  2   \

In A, there should be (to 2) from_1_lane=1 and (to 1) from_1_lane=1:2 since the 2 lanes go there. The fact that 2 is an exit should be an additional tag. In B, (to 2) from_1_lane=1, (to 1) from_1_lane=2.

The from and to tags could refer to nodes on the corresponding ways, for example the last node before the intersection and the first node after (or any practical node), thus the relation would be more compact.

Also, I object a second time to storing in the database what a routing device would display or say. This should be left to interpretation of the data by the routing software, because users may tune it. What a user thinks is a slight turn may vary. For example, what if an exit is so long that it can nearly be considered as a lane ? I would be confused to be told «take the next exit» if the exiting lane begun 100m behind and is still reachable 800m ahead. In this case, a way in the from_n role could be used to say that from any point in that way it is possible to go to the location referred by the to role. --Pshunter 23:21, 7 February 2009 (UTC)

Without relation, without splitting the way : a process logic

All those cases are on oneway roads, so the tags can be kind of process instructions, read sequencialy, and we can solve the problems without adding a relation, and even without splitting the ways. In two ways :

• if realy needed, by splitting the way and putting tags on the segment,
• by putting tags on the node and the instruction is valuable until a new tag disvalues it. E.g : on a way tagged 'lane:3' a local node has the tag lane:4 indicating there are now 4 lanes, untill an new tag indicates 'lane:-1'. Remember we are on oneway road and the 4 lanes section can be well known.

I'm following with the second case : without splitting the way.

example 1 : fork

physical

               /------------
              /
   /---------/   -  -  -  - (<- A2)
  /            /
--  -  -  -  -    /---------
                 /
 -  - - - - - - -\     (<- A1)
                  \
--  -  -  -  -     \--------
  \            \  
   \---------\    -  -  -  - (<- A1)
              \
               \------------

logical

                  _________  (way: ref:A2)
__.______________._________  (way: ref:A1)
  
  N1             N2

• The way A1 has the tags lane=2 + ref=A1 ...
• The way A2 has the tags lane=2 + ref=A1 ...
• The node N1 has the tags lane=4 + lanes_3-4:ref=A2 that is valuable until node N2 where starts the way ref:A2
• The node N2 has the tag lane= -1 that is a 'process instruction' saying 'default lane number' (2 on A1, 2 on A2)

The forumula on N1 can be lane_3-4:ref or on a one lane out : left_lane:ref=A2 or left_lane=out or better

A route engine, having computed A1 then A2, will see the instruction : [something_]lane[_number]:ref=A2

Example 2 : in/out side lane

physical

------------------------------

 -  -  -  -  -  -  -  -  -  - 

--/ - - - - - - - - - - - -\--
 /                          \
/a /----------------------\ b\

logical

___._______________________.___
__/                        \___
   N1                      N2

if split

The segment N1-N2 can be tagged lane=3 + right_lane=in,out and a route engine can compute that someone comming from a must change lanes before N2 and someone going to b must change lanes after N1.

without split

• N1 is tagged lane=3 + right_lane=in,out
• N2 is tagged lane= -1

Example 3 : left out lane

physical

    /-------------------------
   /
--/ - - - - - - - - - - - -/--

 -  -  -  -  -  -  -  -  -  - 

------------------------------

logical

                           /
___._______________________.___
   N1                      N2

• N1 (or section N1-N2) has the tags lane=3 + ('left_lane:ref=NN or left_lane=out)
• N2 (if no segmented road) has the tags lane=-1

The computer knows that the driver must change lanes for going to NN

Note : No need of relation nore split, even if split can be a way for tagging segments if we don't follow the process shema. CQFD FrViPofm 13:23, 6 August 2009 (UTC)

Related work

There already exists some work by other people to cover some of the issues set forth by this proposal. I thought it would be interesting to link to these related proposals since some of them also raise other important or crosscutting problems not covered here.

• Lane relation

Lane relation

Add description here

• Lane groups

Lane groups

Although I did not understand how exactly this scheme is supposed to work, it claims one of its goals is «Creating lanes with own geometries, e.g. for detailed mapping of complicated junctions», which is the topic of this proposal.

It also takes lanes for e.g. bicycles or pedestrians in account. Therefore I think this proposal should be extended to make provisions for other transportation modes. Since bicycle lanes often cross streets it could be very useful.

• Modelling complex junctions

Relations/Proposed/Junctions

Proposed_features/Junction

• Destination signs

Relations/Proposed/Destination_Signs