Remaining issues with tapping routes

[sonora]

Carry over from #14698:

1. It still seems unclear where exactly you have to tap on a route to get it selected. It seems that maybe you have to hit a displayed route shield, or an actual route point? Or is there a timing issue, that maybe some indexing takes place after panning during which tapping a route is flaky or may have no effect?
2. There are issues with some routes still not showing, but this seems perhaps only under certain circumstances or devices. The effect is that tapping them briefly shows the "Loading data..." toast, but this aborts with no subsequent context menu shown. Examples are https://www.openstreetmap.org/relation/3762491("Relation: Goldsteig 4: Neuhaus - Letzau/Oberhöll") and https://www.openstreetmap.org/relation/7323772 ("Relation: Trausnitz - ?? 1").
3. Possibly related to (2.): Special characters in the OSM relation name may be the root cause of (2), see above. In any case, even on devices where (2) is not an issue, Relation "Goldsteig 4: Neuhaus - Letzau/Oberhöll"is in OsmAnd displayed truncated to just "Oberhöll". (see screenshot at https://github.com/osmandapp/OsmAnd/issues/14698#issuecomment-1194425825)

[scaidermern]

I already reported 1) in #14241. Tapping on route shields also doesn't work reliably (even after the alleged fix).

There is also a 4th issue: If multiple routes overlap then only one of them will get selected (the one that gets rendered, I guess). It is not possible to select the other routes.

[vshcherb]

Looks more like 3 independent issue or a discussion then

1. You need to hit on road shields 2-3. Strange, attaching screenshots cause it works in my case

Screenshots

 

4. All routes on the same way should be suggested in the list. I've tested on (https://www.openstreetmap.org/relation/7323772#map=16/49.5175/12.2728, https://www.openstreetmap.org/relation/3762491#map=13/49.7371/12.2458) works ok.

[scaidermern]

4. All routes on the same way should be suggested in the list. I've tested on (https://www.openstreetmap.org/relation/7323772#map=16/49.5175/12.2728, https://www.openstreetmap.org/relation/3762491#map=13/49.7371/12.2458) works ok.

At some places more than one route shield is visible when routes overlap. Tapping on these individual route shields opens individual routes.

At other places only one route shield is visible when routes overlap. Here, only one route can be opened via tapping. One example for this is 51.54561,12.96754 where Jakobsweg Frankfurt/Oder - Leipzig and Torgau-Taura-Jägereiche overlap. Only the first one is visible and can be tapped.

[scaidermern]

   2-3. Strange, attaching screenshots cause it works in my case

No, it doesn't. The name of the relation of your first screenshot is "Goldsteig 4: Neuhaus - Letzau/Oberhöll" but OsmAnd displays only "Oberhöll".

The same applies to the route Jakobsweg Frankfurt/Oder - Leipzig from my previous comment where OsmAnd shortens the name to "Oder - Leipzig".

[sonora]

• [ ] Possible issue (4) I cannot confirm. I do get a selection offered ok if a tap could mean several (overlapping) routes (and once the tap is really accepted). There is a problem though if also a recorded track is displayed in the vicinity, then this one is often preferred and selected directly without interim selection dialog.

• [ ] But I guess it could be due to (1), the recorded tracks are just caught by taps much more reliably than OSM relations. Maybe it can also happen that a track catches one OSM route but not a second overlapping one, in which case the selection dialog may be omitted?

  • [ ] Regarding issue (3), yes, Victor's second screenshot reproduces it for the "slash truncates the name" case. Seems that maybe question marks are no issue then,

  • [ ] but I still wonder under which circumstsnces my Issue (2) occurs.

[vshcherb]

I've created separate issue that we've reproduced and going to fix - https://github.com/osmandapp/OsmAnd/issues/14953. Probably it will affect others.

[sonora]

Regarding sub-Issue (2): Could it matter if you use openGL or legacy-core (I use the latter)?

[vshcherb]

It could matter of course.

[sonora]

In the field I have a hard time testing both. Is there a way to compile an apk which would use legacy-core or openGL at runtime based on the setting we have in the dev plugin? So far my impression is we have only apks where the decision is made already at compilation time?

[vshcherb]

Nope - https://download.osmand.net/latest-night-build/OsmAnd-opengl-arm64-nightly.apk has both!

[vshcherb]

Released version 3.2.7 - also has both

[sonora]

Right, thanks. I have verified that the 3 issues reported above slso occur using OpenGL arrmv7.

And I just notice I misspoke above: My question is that I use both armv7 and armv64 devices, and I was wondering if we have "Fat" builds for OpenGL? I have tried to build "assembleAndroidFullOpenglFatDebug", but it ended up as a >300MB apk, guess I make some mistake. (Hence so far for testing OpenGL I always use armv7 compilations regardless of hardware...)

[vshcherb]

assembleAndroidFullOpenglFatDebug - 300 MB - correct so we build opengl only for arm to have size up to 170MB

[sonora]

With #14953 essentially addressing sub-issue (1), I think here we should now focus on (2), i.e. why tapping some routes briefly produces the "Loading data..." toast but then nothing happens. (Still not fixed in 2022-08-23 nightly.)

Here is another one of these: https://www.openstreetmap.org/relation/7323851. While its title also contains a question mark, that may actually not be the underlying root cause.

[vshcherb]

Issue 2. Can't confirm.

Details


[vshcherb]

As I see for now this issue is not addresable yet cause the cased are not reproducible for now

[sonora]

Interesting why this would be configuration-specific... I have this on all my devices, it seems.

Here a few more examples: https://www.openstreetmap.org/relation/7933 https://www.openstreetmap.org/relation/2746884

And they both have a ":" in their name, which brings up back to my special character theory... 😉

[sonora]

After testing more occurrences, it most definitely looks like the occurrence of special characters like colons (:), double quot marks (") and question marks seem to cause the issue...

[sonora]

@vshcherb Here is a respective logcat, when tapping on https://www.openstreetmap.org/relation/7323851:

08-27 07:55:06.804 3052 17104 E net.osmand: GPXUtilities Error saving gpx
08-27 07:55:06.804 3052 17104 E net.osmand: java.io.FileNotFoundException: /storage/9C33-6BBD/osmand/temp/Trausnitztalsperre (Rundweg?).gpx: open failed: EPERM (Operation not permitted)
08-27 07:55:06.804 3052 17104 E net.osmand:     at libcore.io.IoBridge.open(IoBridge.java:492) 08-27 07:55:06.804 3052 17104 E net.osmand:  at java.io.FileOutputStream.<init>(FileOutputStream.java:236)

So OsmAnd is trying to save the tapped hiking route as a temporary gpx file in a temp folder, and that fails due to the '?' in the attempted file name, right?

I suppose we have to extend our Algorithms by a method

public static String convertToPermittedFileName(String name) {
    name = name.replace ("\"", "~");
    name = name.replace ("*", "~");
    name = name.replace ("/", "~");
    name = name.replace (":", "~");
    name = name.replace ("<", "~");
    name = name.replace (">", "~");
    name = name.replace ("?", "~");
    name = name.replace ("\\", "~");
    name = name.replace ("|", "~");
    return name;
}

(should work for all likely file systems, I use a removable external SD card) and call it before such file save operations?

[scaidermern]

Java has replaceAll(), allowing to replace all invalid characters withing a single function call.

[sonora]

This fixes (2) and (3): https://github.com/osmandapp/OsmAnd/pull/15167

[vshcherb]

Tapping doesn't work yet if you tap in the middle of very long way segment, going to be fixed separately.

[sonora]

Yes, exactly. That seems what was described here as (1) and then also at #14953.

[vshcherb]

WIP - https://github.com/osmandapp/OsmAnd/pull/15205

[sonora]

https://github.com/osmandapp/OsmAnd/pull/15205 seems to have fixed things or at least improved tremendously. I have the following observations still, not sure if this is by design or still under investigation:

(a) Initial dead time: It appears that when you pan the map to a new area, it takes some seconds in the background before taps on route symbols trigger a route selection. (I suppose there is some route detection/indexing going on in the background, invisible to the user?) Before that time, you may not get any response at all, which is why some users unaware of this may still perceive things as unreliable.

(b) Overly broad route selection: It looks like we have some sort of "symbol tap radius", within which you have to tap on a route symbol to actually trigger a route selection. But once it is accepted, the routes provided for selection are not just the ones traversing under the tapped route symbol (or within its tap radius), but also include all which traverse in some distance (maybe all on the respective map tile or on the map portion currently visible on the screen, not sure).

I personally can live with both (a) and (b), but maybe there are some ideas how to mitigate both effects, particularly behavior (a)?

[sonora]

After updating all respective maps it appears as if (a) may have become much less of an issue, almost like the presence of old maps had some adverse impact on things.

So probably we can close this now..