Current road display sometimes shows opposite carriageway

[polarbearing]

Current road display was behaving more stable in NB 2016-08-25, compared to #2962.

However, sometimes it shows the details of the opposite carriageway, see screenshot which should read direction Dresden/Schönefeld. Effectively it jumped between the correct and the opposite one.

GPS alone is often not precise enough to fix onto a particular lane. Thus, IMHO the current road display could profit from:

• directional analysis of the movement, and correlate with oneway directions
• connectivity analysis, thus assuming a transition to the next connected highway segment with high probability, while jumping to an unconnected is unlikely. This might also make the geocoding more fluent with increasing road fragmentation.

[homersimpsons]

Note that for connectivity analysis, this shouldn't happen just after a GPS fix, because it is often not the right position, and this could lock you on the wrong way.

[polarbearing]

Yes, but that's why I mentioned directional analysis first. And I did not say lock something, I said it has the higher probability.

Location is always a probability game, even GPS is based on probabilities. And there is a small probability that I change roads by driving over an unmapped link, or driving offroad.

It should be possible to feed all these parameters (GPS, DOP, direction, speed, road segment connectivity) into a Bayesian network, however that might not be feasible within OsmAnd. But some simple directional analysis should, which is useful for other features such as :forward and :backward attributes.

[vshcherb]

It still strange the bearing has right value, so I'm curious too. I suspect that method `public List<GeocodingResult> GeocodingUtilities.reverseGeocodingSearch(RoutingContext ctx, double lat, double lon) throws IOException { doesn't take parameter like bearing and probably doesn't take extra parameter of CAR mode to check direction of the road.

[raindropsfromsky]

I have faced this situation very frequently, and for very long.

That's why I suggested manual positioning of the location pointer (long-press on the blue circle, and move it to the correct place). After that let OsmAnd snap it to that road.

[raindropsfromsky]

In my case, it does not jump to the opposite side of the carriageway, but keeps traveling on a parallel road (e.g. it shows the position on the service road while I am on the main road, or vice versa).

[sonora]

@vshcherb : Yes, I concur: The method performs a pure distance analysis and returns the nearest segments, sorted by distance. Bearing is not considered here. And neither do we seem to have any post-processing evaluating if a segment found perhaps has a oneway tag opposite to the current bearing, which could serve as a criterion to exclude it as a valid reverse geocoding result.

Frankly, I am not sure if it is worth to implement a check like this. From what I see the only situation which could benefit from this is on motorways or trunk roads, in the non-routing case (routing case should be fine anyway, I guess). I personally use motorways a lot, and do not very often observe the issue. It will depend on which lanes you use, and also on how good your device GPS is.

By introducing this check, we would make the assumption that a driver sticks to the traffic rules and use this to determining his position. A plausible but not necessarily reliable assumption. As a side effect, we would e.g. then tell a driver accidentally entering a motorway in the illegal direction (i.e. opposite to the driving direction) that he is progressing just fine, towards (possibly) exactly the direction he originally wanted. (Vs. as we have it now he sees the information indicating the true destination tag of the segment he is on, if only his GPS reception is good enough, or the lanes are separated far enough, ~50 yards separation is quite common in the western US).

I am not entirely against this, but I personally do rather see ambiguous or switching information where data is inconclusive than a consistent but wrong indication derived from uncertain assumptions. But I agree my opinion here will not be shared by everybody. :)

[raindropsfromsky]

Am I the only user having the problem that OsmAnd shows my position on the wrong road (which runs parallel to the actual road), leading to wrong directions??

[sonora]

Narayan, what are your <hdop> tag values when you observe this? I do typically have 2.3 - 3.0 outdoors, and 4.0 to occasionally 6.0 inside my car, and that works fine for me. Recording a track and inspecting it will show the value. Potential issues could be lots of high-rise buildings in the vicinity (also trees, fog, smog), to much shielding (inside a steel bus, truck), or a potential device issue (I used to have a test device which was just awful, got it replaced and it worked fine).

[raindropsfromsky]

I have no idea how to check the HDOP values.

I recorded the track and loaded it in the OsmAnd, but it does not show any HDOP display. (Or did you mean that it will show the offset between the actual and recorded locations?)

Anyhow, I recorded a GPX track without moving from my seat.

• Initially I had a dummy route, and selected "snap to road" option.
• Later I turned off the route, and took the screenshot again.

The results are enclosed.

I could see that-

• The GPS visibility from my 4th floor window is good.
• The roads are accurately mapped in OSM
• OsmAnd shows my position on the opposite side of the road
  This is true in both "Browse" mode and "Navigate" mode.
  because of that, OsmAnd gives me wrong directions.

Note that the original bug reports that OsmAnd locks to the opposite road (as indeed happened in my case too). But in many other cases, the offset value falls on a parallel road that is in the same direction.

The user can't do anything.

That's why I suggest that he should be allowed to manually shift the current location marker.

[vshcherb]

Agree it is quite hard to implement and causes a big change and it is not the most important use case cause it is not using navigation. So I will keep it as Nice to Have

[sonora]

Narayan, your hdop values look fairly sub-standard, I would even say pretty awful (looks like they may exceed 20 or so). I suspect either very unfavorable reception conditions (could be lots of reflections) or a hardware issue. Check the numerical vales by looking at a recorded track with a text editor or viewer, as I said, we include hdop tags as reported by your chipset in the recorded GPX files.

[sonora]

No further action planned.