search

osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.65k stars 1.02k forks source link

GPX POI vocal indications too early #10416

Closed OTVB67130 closed 3 years ago

OTVB67130 commented 3 years ago

Dear All,,

I'm using Osmand 3.8.4 on Android 10. I use GPX file containing GPX points prepared on "Google My Maps" (MKL file converted into GPX file with kml2gpx.com).

I tested several ways, but I get always the same problem. The vocal indication when you are passing on a GPX point is always arround 1 km too early, even if the other normal navigation indications are ok.

I recorded my problem to describe it to you more precisly. From what I learnt on some Osmand forums, my problem seem to come from the Osman application itself ?

Precise description (you can try to re-simulate my situation):

I took the GPX « C10_du_champ_du_feu_au_promont.gpx » and tested Osmand on a specific part that you can see on the picture « Gpx track tested.jpeg ».

I set the Osmand configuration on my bike profile to announce GPX points only and with a normal delay (you can see that on the 2 screenshots enclosed « Osmand parameter 1.jpeg » & « Osmand parameter 2.jpeg »). In addition to that, you can use my profil export « À vélo.osf » to be sure.

I then launch Osmand on this sepcific test part. You can hear what Osmand indicates on this video : https://youtu.be/PqVvgTTmtrY

On the picture « Issue description.jpeg » you can read step by step the vocal guidances, and realize that Osmand is indicating directions correctly (some meters before turning left or right), but is still announcing that you’re passing at the GPX point (included originally in the imported GPX file) 1 km before you’re really passing it.

Can you help us on this specific problem?

Kind regards,

Raphael Gugumus Gpx track tested Issue description Osmand parameter 1 Osmand parameter 2

sonora commented 3 years ago

@vshcherb I remember it as follows, and think this is not difficult to fix. But before putting this in a sprint we need to decide first what we want:

We are adding the candidates for to-be-announced points of type WAYPOINTS, POI, and FAVORITES to the candidate list once they are closer than 2 times LONG_ANNOUNCE_RADIUS, i.e. 1400m.

But then we have no additional distance filtering for them (other than e.g. for alarms, where we have additional thresholds), meaning they will be announced immediately. I think this is the issue being reported here.

What would be good thresholds? Please note that POIs and FAVORITES may not be on the route at all, but off to the side. WAYPOINTS may only be on the route if it used the corresponding GPX track for its calculation.

So either we lower the threshold in general, at the risk of now missing points bypassed at some distance, or we introduce code to find out if the points are on the route, and if not, where the closest distance to the route is (at that point may be the best time to announce them).

OTVB67130 commented 3 years ago

"But then we have no additional distance filtering for them (other than e.g. for alarms, where we have additional thresholds), meaning they will be announced immediately. I think this is the issue being reported here."

@sonora Thankyou, you summerized perfectly the issue I have here 👍

In my exemple 90% of the POI are on the the route, and 10% nearby. In My example you can perhaps see on the right of the route POI "Hôtel-restaurant Mont Champ du Feu" at 850 m as the crow flies. This one was never announced (see Youtube video : https://youtu.be/PqVvgTTmtrY).

Thanks for you help, Kind regards,

vshcherb commented 3 years ago

I think we need to fix the setting Arrival announcement, so it's applicable not only to the final destination but also to Waypoints / POI and intermediate points.

sonora commented 3 years ago

That's not too hard, but it is largely a solution for 10386.

A solution for this issue here involves specifying the answers to what I raise above about what good thresholds should be, and how to handle points located on the route vs. off the route to the side.

sonora commented 3 years ago

I propose we can do it as follows:

Code refs:

OTVB67130 commented 3 years ago

Thankyou all for your work :+1:

Concerning the proposition of @sonora, our wishes would be to separate the announcement of GPX points that are manually integrated to the GPX before beeing open by OSMAND and POI that are integrated in OSMAND maps.

As Sonora wrote it, in the country side, there are not so much POI (restaurants, supermarkets, touristic points etc...), but in the middle of a city if every points at less then 50 m of the route is announced, OSMAND could turn crazy ^^.

The specific GPX points that we are manually setting on the GPX route, are for our users, the priority when they will run this way.

So, would it be possible to treat GPX points separatly from OSMAND maps POI, so that we garantee GPX points proper announcement and when we want it (for example in the country side) add the POI annoucement?

Thanks,

Kind regards,

Raphaël.

sonora commented 3 years ago

@Paraklius The separation already exists, under Navigation settings / Voice prompts you can separately activate/deactivate "Track points (=GPX)", "Favorites nearby", and "Nearby POI".

OTVB67130 commented 3 years ago

@sonora oh yes sorry, I knew it, but suddenly forget it 😁.

Thanks^^ Just to let us better prepare our next use of Osmand in summer 2021, what is the usually delay for this kind of OSMAND correction?

Thankyou all 😊

sonora commented 3 years ago

@Chumva @vshcherb While we are at it: Here is my old table of how things were supposed to be: https://github.com/osmandapp/docs/blob/main/content/development/specs-algorithms-debugging/voice-prompt-triggering.md. I will update as we do the research here. I have just done the simulation for the Bicycle profile and it seems there are several more issues, it appears we get also Alarms much too early. (I received a stop sign alert about >1000 meters out ...). Cannot currently rule out that we have regression glitch in the code somehow.

vshcherb commented 3 years ago

@sonora we need to update table cause (add new column default speed) cause now it fully depends on default speed specified in settings! So if user changes it it will change as well. So now application mode doesn't matter by only default speed matther, though for different app modes default speed by default is different ;-)

vshcherb commented 3 years ago

To clarify, I find no ARRIVAL_DISTANCE_FACTOR.set statement in our code at all (other than the generic initialization to 1f), am I overlooking something?

sonora commented 3 years ago

See solutuon proposed here https://github.com/osmandapp/OsmAnd/issues/10386#issuecomment-752351492, this would be fixed as part of that solution.

OTVB67130 commented 3 years ago

Hi all,

Thanks for your work on this issus #10416. This will correct our own major issue with Osmand.

I'm not used to the normal problem solving procedure, but if I understood well the process, this problem could be solved in the 4.0 android Osmand version (part of the 4.0 milestone)?

Kind regards,

Raphaël.

vshcherb commented 3 years ago

Well this issue was deeply tested using in latest version and observed behavior that announcements are happened in the radius 100-150m of the waypoint. Here you could find how actually the distances are calculated based on the application profile image

OTVB67130 commented 3 years ago

Ohh😊 that's wonderfull!! I did'nt check this parameter. Your right, tested, works perfectly!

Thanks all for your work.

Osmand becomes definitly our first advised gpx application for touristic cycling in our tourism office in France.

After the covid crisis, please come visit us if you spend holydays in Europe/France : https://www.bruchevalley.com/en/

Kind regards,

Raphael GUGUMUS