Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#567 closed defect/bug (invalid)

make navigation more resilient

Reported by: mvglasow Owned by: KaZeR
Priority: major Milestone:
Component: core Version: git master
Severity: Keywords:
Cc:

Description

I just passed through the area at http://www.openstreetmap.org/?lat=45.83935&lon=9.03657&zoom=17&layers=B000FTF on the highway, eastbound lane. Shortly before, I had set Navit (build 3134, WinCE) to a destination in Milan, just off the highway.

I was in a tailback in front of the border, thus moving slowly. As I passed the point just east of the border where a local road goes underneath the highway, Navit determined that my position was on that road, just in the middle between the two highway lanes, and instructed me to turn around if possible. Shortly after, Navit went into an undefined state: I got the Today screen of Windows CE, but the top bar kept showing the top portion of the Navit screen, and the PDA remained in that state.

A later analysis of OSM data revealed that neither the highway nor the local road had any layering information, thus making it look almost like a level crossing - except for the fact that the ways do not have any points in common.

Now there are several improvements that can be derived from this:

First, GPS augmentation in Navit: The GPS signal is somewhat crude by design and may be a few meters off (the error is expressed by the DOP values, and even a low DOP does not guarantee an accurate reading as errors due to reflectors might go unnoticed). A first approach to coping with that is "snap to roads". This mechanism reaches its limits when multiple roads are in "range". Here, we will need some more information. In the present case it might have helped to consider history information: if prior readings made it somewhat certain that the vehicle was following one particular road, then only those roads that can be reached from there are eligible for the "snap to roads" feature. That is: if the vehicle is traveling towards a bridge, it is highly unlikely that in the next moment it is following the road going underneath that bridge - it is almost certainly crossing the bridge. Admittedly, GPS augmentation is a huge chapter and one could write a paper or even a book on this - if I get around to it, I might write down some ideas and make that available.

In the present case, the ambiguous OSM data presented a further problem: at a level crossing, all roads typically have identical tunnel/bridge/layer tagging (or lack thereof) but there is one point to which all ways connect; over-/underpasses are tagged with bridge/tunnel or a layer tag. To identify a spot as either one or the other would require some heuristics - for instance, if one of the roads is tagged as highway=motorway, then it is most likely not a level crossing as all roads reaching a motorway either begin or end there. (Except for the cases in which an access ramp and an exit ramp immediately following it are one single way, but these would be tagged as motorway_link and would thus be identifiable.)

Second, as a conclusion of the above, it might be a good idea for conversion tools (osm2navit, planet extractor) to do some validation on the data and, where possible, fix obvious errors. In the case of the ambiguous crossing, a heuristic might have concluded that the section must be either an overpass or an underpass but not a level crossing, and re-tagged it accordingly in the output file. (It would only have eliminated the possibility of a level crossing, leaving the decision between overpass and underpass open, but I guess just assuming one of the two would not break that much. Or we could introduce a new point and tag it as something like "junction=no" to tell Navit just that there is no way to get from one road to the other.)

Third, exception handling. I'm not sure what exactly happened inside Navit after that point, but even undefined situations should be handled in a graceful manner, allowing normal continuation of the program. Maybe we could borrow something from the way Delphi does exception handling: the window message loop is enclosed in a try block; if an exception occurs in the code for handling a particular message, the exception handling code is executed and then execution continues with the next message. (Since almost all code in a Delphi app typically goes inside some event handlers called from inside the message loop, it is hard to get a Delphi app to crash - the only remaining risk is that some data may be botched internally due to the exception and further errors result from this.)

Change History (5)

comment:1 Changed 10 years ago by kazer

Wow. That's quite an interesting tickets, more interesting than a stack trace with no comments :) Thank you for taking the time to think and write something so constructive.

About GPS augmentation, as you said, one could write a book on the subject. The thing is that even with heuristics (should it be for the GPS signal or map enhancing), we wouldn't be able to solve every cases (see for example the #17 about speed and bearing). My point being that if we trust only the datas (GPS signal, map datas) then, given the unprecise nature of the GPS, in some case we will be wrong. Now, if we try to enhance those inputs by guessing, depending of the context, we will solve some cases, but probably worsen others. So, it's definitely not an easy topic (it's not about the technical issues, it's about the choices to make).

About your 3rd point, here, no discussion. Navit should definitely behave better than that.

Ticket is open for discussion.

comment:2 Changed 10 years ago by mvglasow (2)

The "undefined state" with the WinCE Home screen reappearing but a piece of the Navit screen remaining where the task bar should be appeared to be a crash of Navit. I used a version which contains some fixes described in ticket #554; the taskbar behavior may be related to that and official SVN builds may behave differently.

Since this ticket basically handles three issues, I am considering splitting it into one ticket for each issue so we can track each separately. Any veto on that? (Links will be included here, of course.)

comment:3 Changed 10 years ago by kazer

  • Resolution set to invalid
  • Status changed from new to closed

No veto about splitting : it's definitely better to have a ticket per issue, so i will close this one, and you are free to open 3 different tickets, and post their ids below for reference.

comment:4 Changed 10 years ago by mvglasow (2)

Opened ticket #602 for exception handling/crash prevention and recovery. More to follow...

comment:5 Changed 10 years ago by mvglasow (2)

Ticket #603 for GPS augmentation...

Note: See TracTickets for help on using tickets.