Show traffic lights on map
  • It would be nice to have an option to show traffic lights on map (just a simple, small icon). It helps to compare map position with reality, especially when there are many intersections.
  • 28 Comments sorted by
  • Please find in the following link a zip file with 5 mca files with traffic lights (Traffic signals).

    I quickly added CZ, DE, GB, NL and PL for the persons in this conversation. They are not searchable, as that is simply not possible with the OSM options as they only have an OSM id. They are only displayed as such on the map.

  • Yes,I can. I wrote a script to do that and shared that via this thread. Last year I also delivered mca files for 6 countries for the users who where then active in this thread.
    And because I restarted this thread I also rewrote my shell script into a python script just this afternoon to make it windows / linux / MacOS/X  cross-compatible.
    See my github

    But that's not the point at all. I don't care as such for a nice red-orange-green icon on my screen.

    It would be much better to have them integrated in the maps. And as soon as you have them in the map you can also speed penalties to them if they are on your route.
    This will make calculation of "in city" route duration times much more precise and realistic. The fact that Navigator does not take speed penalties into account makes that the route duration times are sometimes half of what they should be.
    Next to that: Navigator sometimes calculates wrong routes inside cities because only based on speed and distance the route is faster, but in reality it is not.
    However, some other Nav apps use the traffic signs on the route and therefore calculate another route that might look a little longer and slower, but in reality is (much) faster due to the fact that it contains less traffic signs (or other speed regulating options like bumps).

    It is not only the traffic signs though. In a city with much cross-roads and roundabouts, which also reduce average speed, Navigator simply calculates the fastest route without taking into acount all those "speed reducers" while sometimes a "short route around" without all those crossroads (and traffic signs) is both faster and more relaxed to drive.

    On long "out of town" drives these speed penalty options only have minor impact.
  • OK, that's fair.
    I fully understand that you get more requests then resources allow for.

    But to manage user expectations it is better to make clear statements about what users can expect and what not :P

    That's why I sometimes repeatedly ask for a "statement" about a feature request.

  • I never said it was easy :)
    When implementing "speed penalties" you have to take the following into account:
    - traffic signs
    - cross roads
    - roundabouts
    - All traffic_calming options like bumps, humps, chokers and the like
    - border crossings
    - gates
    - and when going into details: road smoothness, which is an additional tag for highway. In some countries the shortest road can also be the worst road. Taking road smoothness into account (even if it is an user selectable option) would improve it as well.

    But it will make Navigator a much better route planner within cities and for road smoothness also outside cities, even though that is less of a problem in Western-Europe.
    As mentioned: on long drive outside towns speed penalties don't make a big difference.

    Not being part of the team :) I would suggest a scrum approach: small steps at a time. You have already all crossroads and roundabouts in the maps. Use these for speed penalties. Simply calculate another 10-15 seconds.
    Then add traffic_signals and add 30 seconds or so.
    Etcetera, etcetera.

    Edit: Note that taking the reduced speeds for motorway exits and the like is also a form of a speed penalty.
    So it might not be too difficult but it requires quite some work in the if-then-else functions for all situations, and I assume it takes some modifications of your maps.
  • It would only make sense, if most of traffic lights are available in OSM data. I guess they are not, only just a few.
  • That depends where you are. In the Netherlands the coverage is very high.
    So for me that would definitely be an improvement.
  • In my home town there lots of traffic lights mapped.
  • Extract traffic lights from OSM Data and convert it to mca POI, isn't it?
  • Yes, that would do it for displaying them on the map, but it won't help for more accurate calculation of the route with regard of the time necessary.
    Note also that with mca files of more than 100.000 entries it get's very slow. The  "external" poi mca files have definitely a less optimized structure.

    You can easily extract them with osmconvert/osmfilter on the osm.pbf files.
  • It is the first, small step, hope there will be the next.
  • Thank You, it works and looks nicely!
  • For those that are interested: Below is the bash script I use.


    # bash file to extract traffic signals from osm files
    # version 0.1, Harry van der Wolf, 20150416
    # requirements: wget, gpsbabel, osmconvert, osmfilter

    region="europe"    # or north-america, asia, south-america, africa, australia-oceania, central-america
    countries="germany france poland netherlands belgium luxembourg denmark sweden norway czech-republic italy switzersland austria portugal"
    # test country

    for country in $countries
      printf "Processing $country\n\n"
      printf "downloading $country\n"
      wget$region/$country-latest.osm.pbf -O $country-latest.osm.pbf
      printf "Converting $country to .o5m format\n"
      osmconvert -v $country-latest.osm.pbf --drop-author --out-o5m > $country-latest.o5m
      printf "Filtering the traffic signals out of $country\n"
      # on any pc/server with more than 2GB memory remove the --hash-memory=400-50-2 parameter
      osmfilter $country-latest.o5m  --hash-memory=400-50-2 --parameter-file=traffic_signals.txt  > $country-latest.osm
      printf "run gpsbabel on our $country filtered osm file to convert to gpx\n"
      gpsbabel -i osm -f $country-latest.osm -o gpx -F $country-latest.gpx
      printf "Remove some unneccessary lines\n"
      cat $country-latest.gpx | grep -v "cmt" | grep -v "desc" > $country-TrafficSignals.gpx
      printf "Removing our downloaded files and intermediate files to clean up"
      rm $country-latest.o* $country-latest.gpx

    printf "You should now have your gpx file(s) ready. Run them through digger"

    And the link to the traffic_lights image/icon I created from an open source image and made transparent (background). I simply loaded the gpx in digger with standard settings (based on the icon size) and didn't specify anything in the name, note or map page.

    Edit: And of course the link to the filter textfile traffic_signals.txt

    You can play with it for your own country.
  • This feature request was raised in April. Can someone from Mapfactor please indicate whether this feature request will be implemented and if so when (approximately)?
  • I didn't yet say thank you @hvdwolf although I use the signals files since months. So thank you now!!!
  • Reminder: This feature request was raised in April. Can someone from Mapfactor please indicate whether this feature request will be implemented and if so when (approximately)?
  • Can someone from MapFactor please given an answer to this question? I'm asking for a statement, not a complete implementation. The "radio silence" is a bit annoying.
    To me there is a simple set of options:
    1. No, we will not implement it.
    2. Yes, we will implement it in version x.y.z somewhere in Quarter X in 201y
    3. Maybe, we are currently investigating options and possibilities
    4. Maybe, but due to our current workload or priorities (GLES, windows phone 8/10, HUD) we will postpone analysis to early/mid/late 201x 
    5. Something else ?????
    Please communicate!
  • One year? @hvdwolf delivered the files within two days?
  • MCAs created by digger are called imports and there is limit for navigator to use maximum 6 imports.
  • Lubos is right about the digger MCAs. They are less optimized. When such an mca contains too many entries it is getting slow as well. I think the Navigator MCAs are indexed and the digger MCAs are not. I notice it as well with those wikipedia/wikivoyage mca files I have been working on. They become very slow.

    On the other hand: a traffic light is actually not a POI. You can treat them more like the "external" speed cam MCA files coming with Navigator. 
    Either you can implement the traffic lights as POI in the general mca files or as some road tag in the mca files.

    With regard to POI icons: Should that really take so long? I used to be heavily involved in another open source nav app and it was relatively easy to add another POI there. 
    One or a few svg/png files to add to the assets. 
    An xml file linking the icon to the osm object, 
    and an extra case/switch statement coded into the relevant java file.
  • attempt number 100.123.567
    @mdx: Can you please reply? Is it yes, no, maybe?
  • public holiday today, please be patient
  • @tomas:

    Almost a year later. Can you say whether this is on the wishlist for implementation?
  • not that I know off
    can you import them?
  • OK, point taken, problem is that we have cannot do everything and have to make priorities
    I will bring it up at our next meeting - please note that I cannot say when/if it will be done
  • actually, thinking about it, incorporating traffic lights to routing may not be as easy as it sounds

Howdy, Stranger!

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

In this Discussion