Lane Guidance (PLGA) errors — With Tomtom better?
  • I've been noticing that MapFactor Navigator's PLGA (passive lane guidance assistant, on Android) can be trusted 90% only because at some spot checks it makes either of the various mistake types:
    • mt1: the arrows show confusing/incoherent information or simply wrong information!
    • mt2: the arrows don't show up at all, while other gps navi apps (like TT Go Mobile or Navigon) do show the LGA at that critical street crossing!
    • mt3: the arrows don't reflect what's ahead next next by showing 2 green arrows (not optimal) instead of 1 green arrow (optimal)
    I've encountered such PLGA mistakes in the MFN app often enough, and it would be a full-time job to make a list of all these examples ("debug the extensive code/database") i've come across. It is not my job to find, document, list, and fix all the instances where the PLGA makes mistakes. The bottom line is that i am beginning to lose trust in the software. But i've been wondering from where these PLGA mistakes originate, why the PLGA makes mistakes.

    Is the PLGA 100.0% dependent on the OpenStreetMap (OSM) data AND is the PLGA 100% automatically generated by the software, exclusively and directly based on the OSM data? OR has the PLGA been manually edited by MF programmers, i.e. added, checked, tested, edited?
    Maybe the PLGA does lane guidance errors because of wrong OSM data, OR because of human error by MF programmers. I would like to know! Well, if the former is the case, then the PLGA should make less mistakes with TomTomMap (TTM) data, because all my tests with TomTom software didn't show any PLGA mistakes: i can totally trust the TomTom GO Mobile app! So I've been wondering if the PLGA based on TTM data shows similar mistakes induced by MF editors.

    I don't want to spend 15 or 20EUR, only to find out that i am not gaining a clear advantage over the FREE OSM data. If i learn that the PLGA w/ TTM data has the identical behavior as TomTom's PLGA in the TomTom GO Mobile app, then i would be certainly interested in buying the TTM for MFN. The gain of spending 20EUR for TTM data would be the faultlessness of MFN's PLGA then!

    Side question: How often do you release FREE updates of the TTM data? For how many years do you plan on offering FREE TTM data updates for people who once spent 20EUR on it? Maybe offering TTM data is becoming too cost-ineffective (licensing fees) for the MF company and will be discontinued due to lack of popularity within the MFN user community?

  • 12 Comments sorted by
  • yes, lane assistance is generated from map data

    TomTom maps have no expiry date, updates are charged at approx 50%
    you can update any time in the future, no need to do it with every release.
  • Hi tomas, thx for quick
    Your short answer doesn't fully answer my expansive question, though. Of course, the PLGA has to take data from the map to generate the arrows by way of the MFN main app code. Of course, each appearance of the PLGA can't be coded manually into the MFN main app software; that would be millions of millions of street crossings to be checked and implemented and the manual process would have to be repeated all over again once the map supplier supplies an updated map version.

    Anyway, are you saying that MFN's PLGA+TTM shows correct arrows compared to MFN's PLGA+OSM for a street crossing where the latter shows wrong arrows?

    So basically, who do you think is the main responsible for PLGA mistakes? (MF programmers or OSM data programmers or the MFN main code itself?)

    Let's do 1 simple spot check, I hope you (or someone else with TTM in MFN) could you share ;;) a phone screenshot (MFN's PLGA+TTM) for this example street crossing:
    Coming from the east on Jülicher Straße taking a left onto Heinrichsallee heading south:
    Btw, to whom it may concern: ALGA's do exist but i am not fond of Navigon's ALGA (too small!) nor of Sygic's ALGA (shows mistakes too!). I prefer PLGA's. So far i like TomTom GO Mobile's PLGA best.
  • yes, it is better with TomTom maps
    but I think that it is not wrong with free maps either, it just that straight arrow is to cross B1A -  I have no idea if the next turn left to B1 is missing lane info, or it could be that is not well positioned

    with TT ou get straight on B1A and then left on B1
  • hello tomas,any chance of a simulation screenshot (*.JPG) right before taking the turn left onto Heinrichsallee, with the deepest 3-D zoom-in possible?

    Before i buy TTM for MFN, i really need to see first what i am getting for the money. Try Before Buy.

  • please email support and mark it for my attention
  • email sent, got your reply, thanks.

    now i have seen that TTM data vs. OSM data in MFN produce different sets of arrows for the PLGA, which is promising per se. hmm, there are still differences to the sequence of arrows produced by the TT GO Mobile's PLGA: TT GO Mobile has an excellent and faultless PLGA.

    If MFN's PLGA were as faultless, then i would substitute MFN for TomTom, because TomTom will have cost me 45-60EUR after 3.0yrs of continuous usage!

    Also, their PLGA is slightly animated, you can see it in action in this youtube demo: it sometimes rolls up/down, very minimal animation, primitive but effective. And cool. B-) Maybe MFN programmers could implement such animation too? Should be totally doable.
  • Does the MFN with TTM data also show those blue pseudo-signposts at junctions and exits and other points? And are they the same (as known from MFN with OSM data), and also the same number, or less?
  • TT has more blue signs
  • No way. I must test!! B-)
  • Tomtom blue signs are very often and set perfectly to original signs.
  • Okay i got the TTM data, testing it these days. Maybe even reviewing it and creating a video. My first impressions so far are, re car navigation, that the TTM data does produce improved navigation (compared to navigation with OSM data) with:
    • more, nicer blue signs
    • PGLA does "no more" errors (but does not match TTGM's PGLA arrows and arrow sets identically either)
    • more frequent audio instructions matching the improved PGLA (see mt2)

    mt2 is basically gone, mt1 is minimized (MFN has some idiosyncrasies 8-| ), mt3 is still there because of limitation of MFN software. ( be continued...)

    Edit: yikes I found a systemic bug in the PLGA w/ TTM.... 

  • after hours of testing i've come to the conclusion that i am not as satisfied with MF-TTM (nor MF-OSM) as i could be. could means: if the MF makers agreed and fixed the issue which i am personally having with MF's guidance performance, then i would be satisfied with the app. I would value the app much higher then!

    And imho 'the issue' is not a point which can or should be debated/discussed. It's either you agree and care and fix the issue or you don't agree, don't care, and leave it like that.

    The issue all boils down to how the MF main app software code (short: the MF algorithm) interprets, translates, transforms the TTM data to produce the navigational elements, most notably the PLGA and the voice guidance (VG).

    Luckily we have the FREE TTGM app as perfect reference (TomtomGoMobile). I did tons of testing, and TTGM PLGA+VG were always clear, exact, and correct. Always! This is no wonder, because the TTM data and the TTGM app are developed by the same company.

    In comparison, Sygic uses the same TTM data too. But i noticed that its ALGA sometimes shows wrong information. The Sygic app sometimes produces a wrong ALGA .. at instances where the TTGM PLGA+VG does everything right. Clearly, the Sygic algorithm is flawed. Not by much, though.

    The TTGM app provides beautiful navigation, absolutely flawless, and exploits the TTM data best, without errors. (Only Navigon app provides even more detailed and even correcter(!) lane guidance information wow.)

    Unfortunately MF-TTM produces differing PLGA arrows, differing VG instructions, e.g.
    caseA1. wrong: "carry on straight ahead" wtf, correct: "turn left (=taking a left at a crossroads)"
    caseA2. wrong: "carry on straight ahead", correct: "bear left (=making sure to switch to the left lane because it's the left lane which goes straight)"
    caseA3. wrong: "carry on straight ahead", correct: "keep left (=not switching the initial lane because the lanes to my right will not go straight)". Google Maps even says "then keep left at the fork"!

    Sure, sometimes MF-TTM correctly says "keep left" and "bear left" for having the driver go straight. But in the following video, for example, whenever it says "carry on straight ahead", it is the wrong VG instruction (as can be verified by watching the other video parts of the comparison series):

    Accordingly, the arrows of the PLGA are incorrect too, differing from TTGM PLGA (and also from MF-OSM), as can also be seen from the video.

    I hope that MF uses a different algorithm to interpret TTM data than to interpret OSM data. Be it as it may, the MF-TTM algorithm needs to be fixed in such a way that it produces the same PLGA arrows and VG instructions as the reference does.

    There is no way that, currently with MF3.1, MF-TTM produces better or improved navigation than TTGM, not even equal. In fact, with all the differences (and sometimes real errors like case A1, argh!) MF-TTM produces a factually worse navigation regarding PLGA+VG.

    Summary: TTGM's PLGA+VG is faultless, flawless (and elegant), 100% quality. MF-TTM's PLGA+VG should be at 95% of that quality but it isn't. Because of the flawed MF-TTM algorithm the quality is at 75%. Fast car drivers can't trust MF-TTM for lane guidance, until the quality has gotten up to 95% (the missing 5% can't be reached by MF-TTM because TTGM has a more elegant PLGA combined with the next-maneuver-arrow). I cannot recommend MF-TTM (v3.1) as substitute for TTGM regarding lane guidance performance.

Howdy, Stranger!

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

Login with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter

In this Discussion