how to make turn lanes in osm appear in mapfactor free?
  • Vote Up1Vote Down jose1711jose1711
    hello, is there a planned support for turn lanes in OSM? the reason i am asking is that there are several ways how to map turnlanes and i'd like to choose the right one. thanks, jose
  • 57 Comments sorted by
  • Vote Up2Vote Down mdxmdx
    thank you all :-). Officially we may start to work on this in January, but starting with planet-121205, which could be available on Friday, we will extract new tags ("turn" and "destination") and try some experiments. Navigator requires at least two segment paths (i.e. entering and leaving crossing) so even Version 0 will require some kind of testing junction connectivity and angles. As soon as you could see lanes in OSM data I will let you know in this thread (also problems/issues as we encounter them).

    thanks

       Martin
  • Vote Up1Vote Down jose1711jose1711
    hello hurdygurdyman,
    you said that lanes proposal is approved so i wonder if we're not wittnessing a vicious circle here. osm community is not motivated enough to add more lane-related data without a working implementation and developers (such as mapfactor) do not bother because they see lack of data. i wonder if mapfactor could be the first one to say 'hey folks, we DO support lanes proposal for major European cities in a pilot phase (easy because of data and osm contributors density and generally very good bing coverage)'  - add data and you'll see how it works..
    cheers,
    jose
  • Vote Up1Vote Down Its_so_funnyIts_so_funny
    I strongly believe OSM is quite far in implementing tagging for both flavours of implementing a lane assistant, (1) the arrows showing the correct lanes to drive in and (2) the display of destination signs. Compliments to Mapfactor to participate in this discussion. As described by Jose1711 your support is needed to prevent a vicious circle.
     
    OSM wiki page on lane assist
     
    Lane assist (arrow view)
    As described by hurdygurdyman tagging for a lane assistant (arrow view)  is already agreed upon by the OSM community in the :lanes tag. Because of the approved lanes tagging it's predecessor tagging proposal, the page http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension/ProposalPreVoting#Lane_connectivity  is outdated.

    Also the turn tag is important for a lane assistant. That's also an approved one, including turn:lanes.

    I think that one feature for a lane assistant is missing at the moment (correct me if there's more than one). And that is mapping a solid line on the road. E.g. a road can have three lanes (lanes=3), but if there's a solid line, a router would have to know that. This proposal has been made to deal with that situation. 

    Question 1: which approved tag is missing at the moment to implement a lane assistant, besides the change:lanes tag?

    Lane assist (destination sign view)
    For destination sign view the approved destination and destination:lanes tags are needed. Besides that, a proposal is being made at the moment to tag destination details as they can be seen on the destination signs.

    Question 2: which approved tag is missing at the moment to implement a destination sign view, besides the destination details? 
    Question 3: on a motorway/trunk the easiest tagging would be to use destination only on the ways directly after (and not before) the motorway junction as can be seen in this example. Is this good enough to implement a destination sign view?
    Question 4: the destination signs at the exits of motorways and trunks always show an exit number. Can Mapfactor get this exit number by using the motorway_junction ref or does the exit way need to be tagged with the exit number? (note: left/right situations exist in real life)
  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    Hallo jose1711,
    I think that there will be no real chance to support lanes and turn lanes in Navigator Free, until there is no mainly accepted way to map them. As far as I know there is just one scheme allready approved since March 2012:
    http://wiki.openstreetmap.org/wiki/Lanes
    http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension
    Also I know that there are several ideas in work to help routing-engines using OSM at complex junctions. but until now there's no mainly accepted scheme or proposal. I hope there will be a commitment in community as soon as possible and we'll get a mapper-friendly scheme, to gather all the needed data for turn lane informations.
  • Vote Up0Vote Down mdxmdx
    Hello Jose, Hurdygurdyman, Johan and others,
    I am glad that the approved scheme contains "turn:lanes" tag, so it is clear which set of arrows should be shown to the driver.
    The next information we need to extract is which lanes are allowed for given route, i.e. if we have a list of
    ways which lane is allowed for the driver and which is not. This I suppose is in the proposed scheme, with relations.
    I am not very sure about "Note that you will only need the relation if the connectivity is not obvious!" in
    http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension/ProposalPreVoting#Lane_connectivity
    I am also not sure which type is used 'type'='turnlanes:turns' or 'type'='connectivity'?

    Interesting is the 'destination:lanes', but again we would need some kind of connectivity without matching consequent parts of roads.
    thanks
       Martin

  • Vote Up0Vote Down jose1711jose1711
    hello mdx, i think we should not discuss the proposal until it successfully passes voting. anyway, i do see the possibility to restrcit the driver from using a lane within the already approved scheme. for rightmost bus-only lane we could for instance do:
    bus:lanes=yes|yes|official. for lanes banned for everybody, access:lanes=yes|yes|no should do. i do not currently see a need for making things more difficult using relations.
  • Vote Up0Vote Down mdxmdx
    OK - I was a little bit more thinking about "obvious connectivity" ... that's something we could start even with already approved scheme. If the list of "turn:lanes" contains the same number of unique directions (I ignore U-turn for the moment) as is number of ways going from the end of incoming way then it is "obvious" (note, that you have to know the geometry of all ways in order to properly assign it). In this case it is probably not a good idea to add extra relations and inflate the data.

    Maybe one more question if I got the description of "turn:lanes[:forward|:backward]" right.
    1) if way is long going through several junctions it would have to be split
    2) turn:lanes and turn:lanes:forward represent the same directions on the last node of a way
    correct?
  • Vote Up0Vote Down jose1711jose1711
    1) yes, obviously. same as a driver expects a new road sign after crossing each junction there will be a new section that describes changed lanes situation
    2) to me turn:lanes and turn:lanes:forward is equal. i'd only use turn:lanes:forward when really needed (that is: when there's also turn:lanes:backward on the same osm-way element)
  • Vote Up0Vote Down jose1711jose1711
    ad2) okay, turn:lanes = turn:lanes:forward only for oneway road. if you have a through-traffic you definitely want to either say :forward or :backward, otherwise you're describing ways in both directions and one tag and this is really not something you want to do.
  • Vote Up0Vote Down imagicimagic
    Hi to all,

    I was pointed to this discussion to provide some help. I wrote the lanes proposal and most certainly are the one who mapped the most :lanes tags up to now (this hopefully changes soon).

    The goal of the lanes extension was to provide enough information to enable a lane assistant. As you already recognised the proposal was cut down before voting to ensure a positive outcome of the vote. The missing parts should be put in separate proposals in the near future. The next step would be the connectivity relation - I hope I got the time to write it in the next weeks.

    A few comments to the discussion up to now:
    * obvious connections vs. connectivity relation: the relation should be necessary as rarely as possible, because relations are not well accepted throughout the community. Therefore I want to define a minimum set of "obvious" connections that do not need a relation. This set obviously would never be complete but I want to make the data consumers aware of the fact that they need to handle this somehow. This is of course quite tricky on the implementation side but the other way around (i.e. every connectivity had to be mapped) would simply not work as much too less useful data would be provided IMO. It would help a lot if I could get some feedback from the consumers what they think what is a "obvious" connection.

    * the relation type=turnlanes is something completely different. I doubt that it will succeed on the long run.

    * Jose already answered this, but some more details: xxx:lanes specifies the values of ALL lanes of the road, starting with the leftmost and ending right, where "left" and "right" is viewed in the direction of the OSM-way. xxx:lanes:forward only provides values for lanes running in the same direction as the OSM-way, xxx:lanes:backward for the opposite direction. You have to be aware that "left" in backward direction is "right" in forward direction. This sounds more tricky than it is, it simply means: view the lanes in driving direction. This also means that you usually have to use :forward/:backward in case of a two-way road.

    Some additional topics you might be interested:
    * the proposed extensions to the destination key provides you with detailed information about the direction a road is heading. Please have a look at the proposal for destination:ref, destination:sign and destination:country.
    * the proposed key change inform you about allowed/forbidden lane changes. Very useful on complex junctions especially if used together with turn:lanes .

    I can provide you with some examples. Especially the destination subkeys are already in use.

    Some explanations can be found here: http://wiki.openstreetmap.org/wiki/User:Imagic/LaneMapping#Examples_with_aerial_images

    Hope this helps a little. Feedback is always welcome.

    Regards,
    Martin
  • Vote Up0Vote Down imagicimagic
    Two examples:

    A motorway exit where also the junction with the primary has some lane tagging:
    http://www.openstreetmap.org/?lat=47.98915&lon=16.27907&zoom=17&layers=M


    A motorway interchange where besides the lane tags also a lot of destination tags are present:
    http://www.openstreetmap.org/?lat=47.33715&lon=15.01&zoom=17&layers=M

    Let me know if you need some more examples.
  • Vote Up0Vote Down jose1711jose1711
    @mdx: did imagic and i explain it well enough for you to say that no information is missing for a pilot implementation phase? :-) if anything, i can help with testing and adding more lane-related tags in bratislava (bing, norc.sk and local survey is available as data source)
  • Vote Up0Vote Down mdxmdx
    p.s. maybe the first question - is there any tag which has to be associated to the way when "lanes-scheme" is used? Something like "there has to be number of lanes lanes=5", for example? The reason I am asking is to minimize number of queries to given object. At the moment I suppose tag "highway" is MUST HAVE. Later we will have probably whole coding words like "turn:lanes:forward", so I am just curious ...
    thanks
       Martin

  • Vote Up0Vote Down imagicimagic
    If you need some good testing field for the destination-key have a look at the motorway A1 in Austria from Alland to the border of Germany (in this direction). I added there a lot of destination tags lately. In the other direction, i.e. eastwards, I only have information up to Salzburg and this is not yet tagged.

    And I want to make you aware of one pitfall: the key lanes specifies the number of lanes available for motorized(!) traffic, while any :lanes-extended key describes properties of all(!) lanes, e.g. including cyclelanes. So for example you could have something like this:
    oneway=yes
    lanes=2
    turn:lanes=through|right|right

    In such a case there should be additional tags describing the type of the lanes, e.g.
    vehicle:lanes=yes|yes|no
    bicycle:lanes=yes|yes|designated

    Hope this helps,
    Martin
  • Vote Up0Vote Down imagicimagic
    And I have another question: which destination keys will you support? Only destination or also its (proposed) subkeys? Also the :lanes-extended tags like destination:lanes? The reason I ask this is that up to now I used destination:lanes very rarely even if I got the needed information. If you tell me that you will support the extended tags I'll make a rerun through all my photos and add the extended tags ;-)
  • Vote Up0Vote Down jose1711jose1711
    hi mdx,
    to me, presence of lanes key does not automatically imply there is also a turn:lanes key and we want to show the driver how the turn lanes look like anyway, right? plus some additional info like access, maxspeed etc. the way processing should look like could be as follows:
    - change turn:lanes keys to turn:lanes:forward on all oneways
    - mark all ways with turn:lanes:(forward|backward)
    - process the marked ways and extract additional info if available, such as: vehicle:lanes:(forward|backward), maxspeed:lanes:(forward|backward) etc


  • Vote Up0Vote Down mdxmdx
    @imagic - destination and lanes are different data for us. In commercial data you would see destination in "signposts" (blue squares with texts and icons/pictogram) and lanes are the red/green arrows. So from the data source point of view it is not necessary to link destination to lane. For both we need list of ways you have to pass assigned to lane index/signpost(destination), but the direct link lane=destination is not necessary [unless lanes would better describe the list of ways and destination could be easily assigned to lane].

    So far only luxembourg_osm is imported, but 'lanes' are not frequently used there:
    mysql> select tag_key, count(*) from osm_lane group by tag_key;
    +--------------------+----------+
    | tag_key            | count(*) |
    +--------------------+----------+
    | lanes              |      988 |
    | lanes:backward     |        2 |
    | lanes:forward      |       14 |
    | lanes:psv          |       13 |
    | lanes:psv:backward |       17 |
    | lanes:psv:forward  |        9 |
    +--------------------+----------+

    Austria should be imported next week so we will see what could be the next step.
    thanks
       Martin
  • Vote Up0Vote Down jose1711jose1711
    > So far only luxembourg_osm is imported, but 'lanes' are not frequently used there:

    mysql> select tag_key, count from osm_lane group by tag_key;

    hi martin, does it mean that i should be able to see lanes info as soon as i download the latest luxembourg map? is gps required or i will see the info even during simulation? thank you, jose
  • Vote Up0Vote Down mdxmdx
    no, sorry - this is only "data collection phase"
  • Vote Up0Vote Down mdxmdx
    FYI the import of germany_osm_north looks more promising:
    mysql> select tag_key, count(*) from osm_lane group by tag_key;
    +-----------------------+----------+
    | tag_key               | count(*) |
    +-----------------------+----------+
    | access:lanes          |       38 |
    | access:lanes:backward |        3 |
    | access:lanes:forward  |        3 |
    | destination:lanes     |       31 |
    | lanes                 |    29558 |
    | lanes:backward        |      250 |
    | lanes:bus             |        1 |
    | lanes:change          |        5 |
    | lanes:change:backward |        3 |
    | lanes:change:forward  |        4 |
    | lanes:exit            |        2 |
    | lanes:forward         |      270 |
    | maxspeed:lanes        |        4 |
    | turn:lanes            |      650 |
    | turn:lanes:backward   |      122 |
    | turn:lanes:forward    |       95 |
    +-----------------------+----------+

    There are 95 cases "turn:lanes:forward" to study "obvious cases" for version 0, i.e. version without relations.
    mysql> select * from osm_lane where tag_key = "turn:lanes:forward" limit 10;
    +-----------+------------+-----------+--------------------+----------------------------+
    | way       | node_from  | node_to   | tag_key            | tag_value                  |
    +-----------+------------+-----------+--------------------+----------------------------+
    | 190589744 |    9352599 | 275605867 | turn:lanes:forward | left|                      |
    | 190589745 | 2012357316 | 294141741 | turn:lanes:forward | left|                      |
    | 190589749 | 2012357317 |   9352601 | turn:lanes:forward | left|                      |
    | 190589750 | 1316113136 |   9352599 | turn:lanes:forward | left|                      |
    |   4417860 |  311103003 |  27045570 | turn:lanes:forward | left|through               |
    |  31829546 |  324367821 |  29838180 | turn:lanes:forward | left|through               |
    |  40807582 |  496148239 |  29838167 | turn:lanes:forward | left|none                  |
    |  61882890 |  311103006 |  27045570 | turn:lanes:forward | left;through|through;right |
    |  61882896 |   27045578 | 311103003 | turn:lanes:forward | left;through|right         |
    |  81125070 |   29003979 |  29003949 | turn:lanes:forward | left|through               |
    +-----------+------------+-----------+--------------------+----------------------------+

    For the first example I picked Berliner Allee http://www.openstreetmap.org/browse/way/81125070, where you can turn left or continue stright on. This looks like "obvious case" even the number of ways sharing node 29003949 is bigger than 1(incomming)+2(left|through). So should be this also "implicit restriction" no right turn?

    A bit strange value is for me "left|" and "left|none" ... ??
  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    Hi Martin,
    maybe I can clear it :-/
    Your example "Berliner Allee" seems to be gathered incomplete. Please compare with this.
    There are more lanes at the "Fuchsbäumer Weg" and also http://www.openstreetmap.org/browse/way/192270665 seems to be incomplete gathered. So there should be more "turn:lanes:*=*" at this junction.

    You're right with the implicit restriction "no right turn" if there's "turn:lanes:*=left|through".
    "left|" meens the same as "left|none": The right lane has no driving restriction marked on it.
    HTH
    Michael
  • Vote Up0Vote Down mdxmdx
    Hi Michael,
    I am not sure I like "none" much ... but I understand, and if there is no sign on the street it should be mapped as empty sub-string or "none". I suppose that "no driving restriction" in combination "left|none" means that right lane does not allow left turn, correct?

    I filtered out ways with condition, where number of presented directions + 1 is equal to number of ways sharing that single junction node, and from original 95 (germany_north_osm, turn:lanes:forward) I got 37. What is the plan with not matching tags like "to_left" or "straight", for example
    189307647 88043916 to_left|straight;to_right
    or
    190417294 1640544008 left|straight;right
    Is 'through'== 'straight' generally accepted or 'straight' should be ignored/replaced soon?
    thanks
      Martin

  • Vote Up0Vote Down jose1711jose1711
    hi martin,

    "none" was invented solely for the purpose of easier legibility - it's not much easier for human brain to understand "left|none|none|none" than "left|||". i *believe* "none" in the real world basically means through-traffic only but i am not a driver so someone eligible should answer this one.

    i believe "to_left" is an error (thus should be left unprocessed). it should've been either "merge_to_left" or "left" as per http://wiki.openstreetmap.org/wiki/Key:turn. straight was never defined, should be replaced by through in osm. anyway, it makes sense to replace it by through in your preprocessing.

    cheers, jose
  • Vote Up0Vote Down Its_so_funnyIts_so_funny

    Generally accepted is this page: http://wiki.openstreetmap.org/wiki/Key:turn:lanes. It states this about 'none': "there are no turn indications on this lane. Used especially for better readability in case of many lanes".

    So that means there are no arrows in this lane.

     

  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    Hi Martin,

    following the Wiki "straight", "to_left" and "to_right" is mapped wrong. I corrected some and wrote a mail to the mapper.

    Also I found out, that something's wrong on the wiki-page http://wiki.openstreetmap.org/wiki/Key:turn:lanes .

    The signs for "sharp_left" and "sharp_right" shown there mean "pass_left" and "pass_right" in Germany.

    http://verkehrszeichen.kfz-auskunft.de/verkehrszeichen_vorschriftzeichen.html#verkehrszeichen_vorbeifahrt



    Further above you wrote about "left|none". "none" means, that there is no restriction-sign on, at or above the road for that lane. So in theory it is allowed to turn left from that lane too

    :-/
  • Vote Up0Vote Down mdxmdx
    just short status info - after restriction of "turn:lanes:forward" and rejection of unknown direction tags I've got only 22 valid cases in germany_north_osm, i.e not much. I checked also austria_osm and there the original had 524 tagged ways with "turn:lanes:forward" and even the simplest case passed 265 junctions. I could not resist and it is available for download now (earlymaps in Android 0.13.x). After few more tests I would replace older Austria OSM version which is in queue for "stable" now.
  • Vote Up0Vote Down jose1711jose1711
    > The signs for "sharp_left" and "sharp_right" shown there mean "pass_left" and "pass_right" in Germany.

    as a matter of fact, those sings have the pass right/left meaning also in slovakia (and i believe also in czech republic - martin could maybe check that) - i wonder how i could've missed that.

    > I could not resist and it is available for download now (earlymaps in Android 0.13.x).

    ok, so this means you extracted the data from turn:lanes:* tags and turned them into additional turn restrictions? how far is the implementation of turn lanes indication?

  • Vote Up0Vote Down mdxmdx
    @jose1711 - austria_osm_121218.mca - extracted are only simple cases of "turn:lanes:forward" ways and you will see it in the lanes indication. There are no (new/additional) turn restrictions.
  • Vote Up0Vote Down apmonapmon
    Great to hear the implementation of turn lane indication is progressing nicely in Mapfactor! One of the best ways to increase the usage of tagging in OSM, is to provide a good implementation of the tagging schema in a popular application. As it gives mappers a new motivation to collect the information.

    So once mapfactor "fully" supports turn lane tagging, it would be great if you could announce that to the various OSM lists and hopefully that will encourage people to rapidly expand and improve the coverage in OSM.

    Does this also work in the simulation of the windows version? I'd love to try this out, and again I'd suspect that would be a nice visualisation to help motivate people to tag turn lanes.

    I am wondering though why you chose to restrict yourself to turn:lanes:forward to begin with. Given that turn lanes are possibly most useful on large roads that are commonly split by direction, the use of turn:lanes in combination with oneway=yes is probably more common than turn:lanes:forward.

    Indeed worldwide there are 6481 osm ways that contain "turn:lanes" but only 1987 with "turn:lanes:forward"  (and 1353 with "turn:lanes:backward)


  • Vote Up0Vote Down jose1711jose1711
    hey apmon, it's good to see you back. how about the new gpsmid? any plans to support lanes-tag too? :-)
  • Vote Up0Vote Down Its_so_funnyIts_so_funny

    <There are no (new/additional) turn restrictions.>

    That sounds logical, I hope you keep it that way. The lane tagging in OSM is not meant to replace the tagging of turn restrictions.

  • Vote Up0Vote Down mdxmdx
    austria_osm_121218 is on "stable" download now so you should be able to download it with standard Setup Utility or Android Downloader 0.12.x. You can use simulation to test/see lanes. Two examples with more lines are for example way 109529871  (47.083293, 15.415535) or way 135698117 (47.055428, 15.416786). Note, that lane assistant is visible only on that particular way ...

    Regarding question "why 'turn:lanes:forward' first" ... well it looked like that there were no ambiguous details like what happens if you do not have "oneway=yes" in "turn:lanes" or the order for "turn:lanes:backward". Also our lanes processing is not quite straightforward ... so that's why I wanted something "simple" :) and we can add other cases/combinations later on.

    Thanks & let me know if you find any problem
       Martin


  • Vote Up0Vote Down apmonapmon
    Nice! I tried it out in version 12.0.7 for windows. In simulation I successfully saw the lane assist when navigating down Glacisstrasse and it showed me the 4 lanes 1 left, two through and one right turn lane.

    However, when turning left or right at that intersection, it did something I didn't expect. It started showing the lane assist a little while before reaching the intersection, which is fine. But it indicated one should travel on the two through lanes, not on the lane for the turn. Only about half a second before the actual turn, did it switch to indicate to use the correct turn lane, which is obviously to late to still react if actually driving.

    I haven't yet tried out any other roads with lane assist to check if it happens there as well, or if it has anything to do with the length of the osm way which actually contains the turn:lanes:forward tag.



    As on high resolution Bing imagery one can often see the turn lane painting on the road, it should be relatively easy to add turn:lanes tagging via remote "armchair" mapping. In your experience, what type of road or intersection benefits most from having lane assist?

    On a small two lane road with a single turn lane my guess would be that lane assist doesn't add too much, as the local environment while driving is clear enough to not need the assist. So it is probably mostly complicated motorway or primary junctions that would benefit most. Any further tips on what type of junctions to focus on when doing some armchair mapping?
      




  • Vote Up0Vote Down mdxmdx
    OK, thanks - it looks like a bug in Navigator (maps in this area seems to be OK). Note, I put there wrong coordinate, i.e. I was testing different example.
    thanks
       Martin
  • Vote Up0Vote Down imagicimagic
    Nice to see the progress here!

    @mdx: Regarding your comment about "destination:lanes" : this is used very rarely and I guess it will also be that way in the future. The advantage over a simple "destination" can be seen in this example: http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Destination
    But obviously this would be only useful on e.g. large motorway interchanges.

    Another example which would strongly benefit from a lane assist would be here: http://osrm.at/1VR
    There are three exits very near to each other. If the navigational device simply tells you to stay right a few hundred meters ahead you are usually completely lost if you should take the 2nd or 3rd exit. (I know that from painful experience ;-) )


    @apmon:
    Quote: "As on high resolution Bing imagery one can often see the turn lane painting on the road, it should be relatively easy to add turn:lanes tagging via remote "armchair" mapping. In your experience, what type of road or intersection benefits most from having lane assist?

    On a small two lane road with a single turn lane my guess would be that lane assist doesn't add too much, as the local environment while driving is clear enough to not need the assist. So it is probably mostly complicated motorway or primary junctions that would benefit most. Any further tips on what type of junctions to focus on when doing some armchair mapping?"

    I started with motorways and now finished about 70% of them in Austria. In my experience they benefit the most for a simple reason: if you turn wrong on a junction within a city you just reverse at the next junction; if you take the wrong exit on a motorway it might result in detour of a few kilometres (or more). So in my opinion it would be best to start with motorway interchanges. When you at it you might also want to consider this: http://wiki.openstreetmap.org/wiki/Proposed_features/change . Example can be found here: http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Motorway_No_Lane_Changing

    Besides motorways it would be best to concentrate on large junctions. But as they are quite often a hell to map you definitively want to start with motorways ;-)

    regards,
    Martin


  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    Hi you Martins,
    in general it's ok that lane-restrictions should be shown on motorway or trunk. But I dont confirm with the opinion, that its not really necessary inside of (bigger) towns. As a stranger there it can be very stressful to find the right lane, if there's a lot of trouble on the road or you're in a foreign country with strange signs. Looking over the border to Ireland I found this secondary-junction as one small example for necessity of lane-assistance. And I know that there are a lot of others. I think, that three or more lanes in one direction warrant lane-mapping and lane-assistance anywhere. But to start with motorway or trunk is a good first goal for experiments.

  • Vote Up0Vote Down imagicimagic
    I didn't say it was unnecessary in towns - I just said that you get the most benefit on motorways and that they are much easier to tag than junctions in town. I completely agree with you that junctions in town also need lane-assistance. As you wrote: for the start motorways are a good first goal.
  • Vote Up0Vote Down mdxmdx
    @apmon - the issue with Glacisstraße ... there are two links: 158583911 followed by 109529871. Both have 'turn:lanes:forward = left|through|through|right' and both ending nodes 20929591 and 20929485 have degree 4 (i.e. number of connected ways with tag 'highway'). So what you see in Navigator is something like for bike ... the first node is go through and turn right is on the second. So there is a need for narrower set of allowed tags. At the moment it behaves "as expected" (which is good and bad news at the same time ;).
    thanks
       Martin
  • Vote Up0Vote Down jose1711jose1711
    so the only solution would be for MF to glue the same segments together, right?
  • Vote Up0Vote Down Its_so_funnyIts_so_funny

    <So there is a need for narrower set of allowed tags. At the moment it behaves "as expected">

    It behaves correct, when riding a bike which is possible on the Glacisstraße. However, when the profile in Mapfactor is set to "Car" highways which are not allowed for cars, like footways and cycleways, should be ignored. In my opinion automatically, and not by setting other tags at the Glacisstraße.

    So the question might also be (i'm not a programmer though :-) ): how could Mapfactor know that node 20929591 has degree 2 when the 'Car" profile is being used? And degree 2 should -for lane assist purposes-  behave the same as no degree, e.g. 'glued together' OSM ways.

    My conclusion is that the tagging applied in this case (by OSM user: species) should be enough to support lane assist. Please correct me if i'm wrong.

    Johan

  • Vote Up0Vote Down mdxmdx
    I think that tagging is correct, but what I wanted to say is, that it is not quite clear that the lanes do not end there. All 4 lanes are in both cases for cars, right? I would focus on car navigation first (there is no support for different lanes for bikes in Navigator now). So the next step would be to reject node 20929591 as "division point" (or some kind of glue as jose1711 wrote) and as user you would get the info from the main junction 20929485.
    So is it simpler to list all allowed tag 'highway' values for cars or blacklist is better?
    thanks
      Martin
  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    As far as I know arrows on a street in Germany correlate to the next highway-junction. A cyclelane has it's own arrows.

    The Glacisstraße is splitted at node 20929591 because the mapper meens to tag some meters of the road with foot=no, because there is no sidewalk on the right side, where the Leonhardstraße comes in. For me it looks like an unlucky kind of micromapping.

    So in this (and any similar) case the lane assist should correlate to the junction at node 20929485.

    Michael
    :-/
  • Vote Up0Vote Down jose1711jose1711
    i wonder what happens if router calculates 'turn right at next junction', but the way is (incorrectly) tagged as lanes = 2; turn:lanes:forward = through|through. will MF display the lane info anyway (displaying both arrows as grey)? thanks, jose
  • Vote Up0Vote Down Its_so_funnyIts_so_funny

    <So is it simpler to list all allowed tag 'highway' values for cars or blacklist is better?>

    I think a whitelist would be simpler

  • Vote Up0Vote Down jose1711jose1711
    > i wonder what happens if router calculates 'turn right at next junction', but the way is (incorrectly)

    this could be a real-world example: http://binged.it/Va3EW4
  • Vote Up0Vote Down mdxmdx
    @jose1711 - if there is no matching sequence of ways the lane assistant will be not shown. I.e. if you navigate to the parking lot from the image you will not see the lanes.
  • Vote Up0Vote Down apmonapmon
    Way splitting might be a problem in general for routing and is becoming increasingly prevalent with the data complexity growing. Any property change (e.g. a change in speed limit or a cycle route splits off) requires a splitting of the way and starting to map turn lanes is just going to fracture roads even further. So it is probably necessary to merge road segments together again during pre/post-processing. 

    I would suspect a white list would be more useful/easier, especially as each routing profile presumably needs to have a white list of routable ways anyway to not send a car down e.g. a cycle way or hiking trail.
  • Vote Up0Vote Down imagicimagic
    Just found (and tagged) another example that desperately needs a lane assist: http://osrm.at/1ZG

    Depending on which road you have to follow at the second(!) junction you have to be on rightmost lane or the lane left to it before(!) the first(!) junction. Lane changing is forbidden even before the first junction so you are either at the correct lane there or you're lost (or you ignore the solid line).
  • Vote Up0Vote Down mdxmdx
    status info January 2013 (planet-130102.osm.bz2) - all states are now computed with simple version "Austria Dec2012 experiment". There is no filtering of road types yet. Note, that even simple tag key/value collection failed in Turkey (processing is fixed now) due to invalid encoding of tag-key - way 4476153 and way 23044346

    edit:
    the update is postponed to Feb 2013 (due to integration bug)
  • Vote Up0Vote Down Its_so_funnyIts_so_funny
    @mdx: Could you please give an update on the present status of implementing turn lanes?
Add a Comment

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Categories

In this Discussion