Fastest and shortest path: an example of bad route calculations
  • Vote Up0Vote Down mappermapper
    With test version 2.2.54 (same problem with the stable 2.1.97 version) and osm data,
    when going from 50.6730, 5.5900 to 50.6310, 5.5590,
    with this routing_points.xml file for the steps
    here are the calculated routes:
    - Fastest (16 km, 12 min)
    - Shortest (12 km, 13 min)
    - Fastest with steps (17 km, 17 min)
    - Shortest with steps (7.1 km, 8 min)
    - OSRM (7.1 km, 10 min)
    - Mapzen (16 km, 12 min)
    - Google Maps (7.1 - 7.6 km, 16-19 min)

    The steps have been added to force Mapfactor to use the most logical route.

    From these numbers, it looks like you are using the same algorithm as Mapzen for the fastest route.
    I highly suggest switching to the one used by OSRM.
  • 16 Comments sorted by
  • Vote Up0Vote Down IU0BMPIU0BMP
    Are you using default car settings?
  • Vote Up0Vote Down mappermapper
    Apart from maxspeed=110 km/h, yes.
  • Vote Up0Vote Down tomastomas
    try to enable small local roads
  • Vote Up1Vote Down hvdwolfhvdwolf
    It has been mentioned numerous times in this forum by so many users:  enable small local roads as an app default.
    In that case you won't have these repeating posts where you always mention "try to enable small local roads"
  • Vote Up0Vote Down tomastomas
    I think we would get different posts :-)
  • Vote Up0Vote Down mappermapper
    Indeed, here's the result with small local roads enabled:

    - Fastest (6.4 km, 8 min)

    So, like hvdwolf, I highly suggest enabling by default small local roads, at least for osm.


  • Vote Up0Vote Down hvdwolfhvdwolf
    I checked with OsmAnd and Magic Earth.
    They both calculate the same initial fastest 16.4 km route as Navigator :)
  • Vote Up0Vote Down john_percyjohn_percy
    It does seem to depend on the country whether small local roads are so small and so local that you would never want to use them or if they are a perfectly good part of the road network.
  • Vote Up0Vote Down IU0BMPIU0BMP
    IMO, it also depends on whether the roads are urban or extra urban. In urban areas they tend to be more reliable and usable.
  • Vote Up0Vote Down mappermapper
    One way to fix this would be to do the same as IQ Routes: anonymously record the travel speed, time and day (basically upload gpx traces). And then determine the average speed on each road segment per time and day.

    Of course, that would go against your current business model which seems to be to attract users with a free app and try and convince them to pay for better maps.
    However, as osm data improves, that will be less and less true.
    One way to improve it would be to create partnerships with local businesses which the users would find easily when looking for, say, restaurants.
  • Vote Up0Vote Down hvdwolfhvdwolf
    There is another option: speed penalties (and not for driving too fast). 
    OsmAnd uses that. What it does is calculate a speed penalty in seconds for traffic lights, speed bumps, cross-roads, etc.The most basic form is supported by all nav apps:  motorway ramps having lower priority/speed than the motorway itself.
    OsmAnd is (very) slow in route calculation ánd screen rendering, but I think OsmAnd has the most accurate in-city calculations of all. Sometimes the seemingly longer route (like your fastest route of 16.4 km) is indeed the fastest route as your don't have those traffic lights, cross-roads and the like.
    The fact that nav apps calculate a seemingly faster and shorter route is because they don't take those speed penalties into account.

    I have done multiple tests in cities (my own for example but also in the Hague) with OsmAnd, Navigator, navmii, maps.me and magic earth.  OsmAnd calculates the best route and has the best ETA.
    However, I only use OsmAnd for car navigation "when in doubt" as it is so extremely slow.
  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    "Enable small local roads" is the solution, because MFNF has the highway=unclassified of OSM-database in this group. unclassified are the lowest kind of connecting roads between settlements and if small local roads are disabled, MFN only uses them for the first or last mile between start and target. For me that's a bug in data management and gives strange results driving on countryside. As I often said, unclassified roads should get its own class as lowest kind of connecting roads and such strange routing results would be minimized. I know about the limited number of possible classes, but new sorting would solve that. Please think about.
  • Vote Up0Vote Down mappermapper
    In this case, based on OpenPoiMap, it seems to be highway=residential (to be pasted in User POIs).
  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    I will check it at home. With smartphone it's boring.
  • Vote Up0Vote Down hurdygurdymanhurdygurdyman
    It looks like a mapping problem. Have a look into this overpass-turbo-query:
    All the blue ways are residentials in OSM-Data, The green are tertiary and the orange are unclassified. I guess that the meaniing or "unclassified" as used in OSM is mainly misunderstood here like "I don't know the road-classification". And I also don't believe that all the blue ones are residentials without any connecting function towards higher road classes But this problem should be solved with local knowledge in gathering OSM-data. My first impression three posts before was wrong in this special case. So I apologize to MFN for that here.
  • Vote Up0Vote Down mappermapper
    Since there's a priority setting why not, like already said, enable small local roads as an app default, with a low priority so they're only used when it would be a huge detour to do otherwise.
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