Both Navigator 14 and Android Navigator get stuck when computing certain routes
  • I am trying to find a pedestrian route from Paris to Rome. 

    Usually, even long pedestrian routes as this one take less than a minute to be computed, unless a "no route" message appears (which is also fast). 
    But here, it is different: the application gets stuck. I waited 20 minutes on MFN 14 (PC, Windows) and roughly 5 minutes on MFN Android (latest version, on a Galaxy S5), chosing to wait for the application to finish its job each time the Android ANR dialog box was appearing.

    I'm using OSM data. The issue can be reproduced from any street of Paris to any street of Rome in pedestrian mode (by car that's all fine). In terms of maps I have the latest version of the whole France, Switzerland, Italy and Vatican City.

    When trying on the OSM website, GraphHooper manages to find a route. I don't know whether this is due to some edits made recently on OSM and that would not yet be included in the MFN maps. Anyway,this wouldn't explain why the app gets stuck instead of displaying "no route": 

    Do you have any idea of what is happening?

    Thanks a lot!
  • 25 Comments sorted by
  • Most probably you have neighbor countries around it. If you walk from Paris through Swiss to Rome and it can't calculate a route for whatever reason, it does try to find a round "around" the non-routable part. If you do have the maps from France, Germany, Austria, Croatia, etc., MNF will most probably try to find a pedestrian route via a big D-tour. As pedestrian roads might not always connect to each other (or at least not in the map data), it might try to find an even bigger D-tour and at a certain moment it crashes, because it can't expand any further probably because it is trying via Bulgary, Turkey, Greece, etc and you don't have the maps.

    At least that once happened to me: My map collection varies a lot. sometimes I have a lot of maps, because I test a lot and sometimes you need a map from a country because some user mentions an error for a country I don't have a map for. But every now and then I clean up and only install my countries map and the neighbors. I wanted to calculate a route from the Netherlands to Austria, but I didn't have Germany and neither France or Swiss (for the D-tour calcualtion). That was the moment MNF also crashed as it ran out of calcualtion options.
    I fully agree that MNF should "gracefully" mention that it can can't calculate a route and not due to memory or other issues simply crash.
  • Strange.. maybe it was not available in all languages.. I use the English version even if I'm Italian (and I live in Rome - all roads lead to Rome, that is why it takes MFN a lot of time to calculate, hihi)
  • When you switch from GraphHopper to MapQuest, you can't find a route as well. So, it is not only MapFactor.

    But, do you really want to walk all the way from Paris to Rome by feet? I hope, you have good shoes ;-)

  • Actually, I do have good shoes :)
    But this one is not for me, it's for relatives who do have even better shoes than I have.

    Regarding the algorithm, finding no route is OK. Well, actually it isn't, but this is tied to the data, not to the app. What I don't get is why the app gets stuck instead of saying that no route could be found. 
  • My sister has a plan to walk from Zittau to the French atlantic coast. She has done a couple of stages until Glauchau in the past years and she will continue later this months for a couple of days and continue later. I tried to route that way with MFN but without success.
  • Hi,

    I did further testing after this discussion:

    - I first tried a ~500Kms pedestrian route from Milan to the south of France, just to determine whether the app was freezing as well. This shown me that it doesn't, but the computation was really slow (something like 2 or 3 minutes under MFN 14 on a dual core i7, current maps). I was about to kill the process when the route suddently appeared.

    - This gave me the idea to retry Paris-Rome (which is the one I actually need), but leaving the app as much time as it wanted. It eventually worked, and took something in between 25-45 minutes to achieve. (I wasn't in front of my computer all the time).

    So the app doesn't freeze as it initially looked like, but takes incredibly long to compute this route. This is probably data-related as I can compute in a couple of seconds some 500 kms pedestrian routes in other places.

    This is workable on PC. When you're ready to walk for weeks, you are not considering half an hour as a long time. However, this is not workable on an Android phone or tablet due to the ANR ("application not responding") error it engenders.

    So these two questions:

    - is it possible to optimize the route computation algorithm in a way it wouldn't take that long?

    - and if not, is there any way to prevent the ANR error from occuring under Android by moving this computation routine from the main thread (called "UI thread" in Android terminology) to a dedicated thread in a way this would not be perceived as a ANR by the system? (The answer here is yes for sure ^^ An AsyncTask or any similar Thread-based thing would do it perfectly)

    Thanks a lot!

  • pedestrian mode takes all links (except motorways) in to calculation and on long distance it will be millions - how many combinations is that?
  • Well, it's ok if anybody wants to walk from Paris to Rome or other very long distance routes. But imho it's senseless, even for cars, to want to compute the whole route in one piece. I mean why don't you cut it in sensible parts, which shouldn't be an obstacle at all because people have to take breaks and even overnight stops so it doesn't really matter if you have to start a new route now and then.

    But the main reason why I think you should do that is that anytime that person deviates from the precomputed long route the route will be recomputed from your present position to the end of the trip. Which invariably can take a long time, what maybe is not acceptable when you are at a critical point and have to make a decision which way to go. With a route broken up in day or a few days trip-pieces that will only mean recomputation until the next foreseen break.

  • @tomas

    This may answers the first question even though you should ask your dev team first, if not done already: you can often gain quite a lot of computation time spending a pretty reasonable effort. (Google Navigation does it in less than 3 seconds on my mobile phone, but knows less pedestrian routes. I'm not asking it to be that fast anyway). I guess you are using a bidirectional A* algorithm to compute the route?

    And regardless something can be done on that side or not, please consider the second point.This one is not costly for sure and would solve a bug (an ANR is actually a bug).

  • as I said, mdx is away, he could answer it, but I think that Google breaks it in parts, sort of invisible waypoints if you like
    second point I cannot answer (I think it is in another thread), I can only say that I did not get error message in 35 minutes of calculating route
  • @tomas

    Thanks for this. The second issue occurs on Android only, not on a PC.
    But reading you the best is probably to wait for @mdx to come back. This is not urgent.

    Have a nice week-end
  • I tried on Android only, Note 2, Android 4.3 v1.6.19
  • And you didn't have an Application Not Reponding dialog box proposing to kill the app and send a report while computing the route for half an hour? (It appears after 30 sec of unresponsiveness normally)
  • I talked about this with Martin half year ago and he said that there is memory limit of roads which can be loaded. Pedestrian routing on long track is slow because navigator still loads and unloads data.
  • @lubos

    Makes complete sense, thanks. 
    At least if we can get rid of the ANR by having the routing routine executed in a dedicated thread it would be fine. 

    The nice to have is it to be fast, but the actual need is it not to engender this ANR issue.
  • @tomas

    How strange. 
    I see we are not running the same version of MFN, which may explain:

    - I'm running Android 4.4.4 on a Galaxy S5, and my version of MFN is 1.5.22 (free version, nice donation made however :) ). According to Google Play Store, it is up-to-date.

    - You are running the v1.6.19 on a older version of Android, 

    How can this be? Are you using a pre-release in which case the bug may have been fixed in it? Or is there any issue with the release plan under Android 4.4.4 or Galaxy S5?

  • latest version is always on our forum, it will be released next week

    it could be related to 4.4.4, but I cannot say

  • Good to know!

    I'll wait for the next update on Google Play, and I'll report on this forum thread right after. The bug might have been fixed, according to what you said earlier.

    Cheers :)
  • @tomas

    I finally decided not to wait and to install the 1.6.19 available on

    - The ANR issue has been solved, the UI thread is no longer stuck when computing the route. That's great.

    - Paris-Rome pedestrian route takes ~20 minutes and ~6% battery to compute (Galaxy S5), which is workable. Faster would be better as a nice to have, but that's sufficient for my needs and better than MFN 14 on my dual core i7 using the same maps.

    Nice job, thanks!
  • By the way, 1.6.19 has been available on Google Play since June 4.
  • @IU0BMP Surprisingly, Google Play was still considering my 1.5.22 up-to-date this morning (hence wasn't proposing to update). Maybe the 1.6.19 is not yet available for all Android versions or devices? (Android 4.4.4, Galaxy S5)
  • New app versions are not rolled out at the same time to all Google users. It's not Navigator specific that user A sees version X, and user B sees version Y on Google Play. Even for days.
  • @IU0BMP :) :)

    @chattiewoman Yes, that's true too. Anyway, it's installed now.

Howdy, Stranger!


In this Discussion