[APP] - version 3.50.+ ( 7. 1. 2021 )

[0709]

Round about third exit.

Something weird.

After this roundabout there follows a Right turn. The Icon Right is correctly shown, but the TTS command does not express Right (NL rechts) but repeats the previous turnabout command. Third exit (NL Derde afslag).

I tested other similar situations at local roundabouts but these where all correct.  So is a strange observation that I only noticed on this particular  location so far.

Verstuurd vanaf mijn Mi A2 Lite met Tapatalk

[Menion]

@Henk van der Spek
well, hard to say something here . I do not have the same experience on my own devices and this is a problem ...

@0709
There exist two methods of how to define roundabouts.
1. by one point at the start of the roundabout
2. by point at start and second point at the exit (app default behavior).

Imported GPX is considered as solution no. 2, so the second point is considered to be an "exit" point.

Solution:
- use ""locus:rteSimpleRoundabouts"" , so it should look like

Code Select Expand


            ...
<locus:activity>cycling</locus:activity>
<locus:rteComputeType>8</locus:rteComputeType>
<locus:rteSimpleRoundabouts>true</locus:rteSimpleRoundabouts>
</extensions>


[Menion]

Damn, you are right! You've spent quite a lot of time on testing right? 

Thanks Willy. This is most probably setup from +- the year 2015 where the main router was MapQuest that used this system. With BRouter and also GraphHopper, this setup does not make sense and create incorrect car notifications after roundabouts.

So thanks, will be updated in the next version!

[slarti76]

Noticed some usability problem in Route Planner, probably always been there:
I was planning a round trip and wanted to use a POI again that I already used as part of the route. However, when clicking the POI a second time, I only get the option to change the point type (square, triangle, what-have-you). I think, the three "Add to route" buttons (at start, in the middle, at end) should be here, too.

[Viajero Perdido]

Noticed some usability problem in Route Planner, probably always been there

It's been a UI glitch as long as I can remember.  You can't plan a perfect round trip by using your start node as your finish (it does annoying unexpected stuff), so instead I just zoom in and finish at another empty area nearby.

No, I don't totally understand the route planner.

[joeloc]

Recently updated to Android 11 on a Galaxy S20 FE. The problems with Locus being killed (by the OS I presume) increased a lot since Android 10. I barely have a day now without it silently dying in the background and not recording my track any longer. All the usual stuff (disabling energy saving, background killing, and godknowswhatothercrap) doesn't seem to help much. Neither does running Locus as a service.

Anybody has any clue on what specifically is going on in Android 11 and Locus? Other tasks like AudioPlayers or similar do not get killed at all.

I am out of ideas.

[joeloc]

Don't get me wrong... your track editors UI (with moving points around etc) is truly a piece of art. The performance, however, is beyond ridiculous. Even though running on the fastet phones to date, deleting a single trackpoint takes tens(!) of seconds. Adjusting a couple positions literally forces you to wait A MINUTE for confirmation. Even a Commodore 64 could run circles around that, it simply cannot be right.

I know you blame your "database solution" or whatever for that since years... but seriously... are you absolutely positively sure that there isn't simply a horrible bug hidden somewhere that makes Locus do a silly loop a billion times or some such? I refuse to believe that something as stupendously simple as deleting a point or editing a position can cause a modern phone any trouble at all. And with Locus it's not just trouble, it's pure horror... .

My tracks are not obnoxiously long, usually 2000-5000 points. My database is big, though I can't see what that has to do with it.

[Menion]

@0709
As I see, BRouter correctly reports left/right u-turn. Online GraphHopper on the second side does not support the "u-turn" command at all. At least in the Locus Map implementation > interesting.

So how you get an incorrect left-u-turn for expected nondirectional-u-turn?

@slarti76
good observation, thanks. I'll try to improve this.

@Viajero Perdido
what is the major problem you face with the Route planner?

@joeloc
Android 11 problem: maybe someone will have any experience with this. I use A11 on Pixel 2 for almost a year and never had a problem with battery optimization. There definitely are not any if/else blocks based on the Android 11, so it should be some change in the Samsung A11 version.

Info on this DontKillMyApp web page does not help?

The track editor is a different story. Unfortunately, SQLite database goes a lot down with performance based on its size. I do not know how big(?) your database is, but for example my tracks.db file already has 320MB and I start to feel decreased performance a little bit.

May you write me the minimum steps I may do on my own device to simulate this issue? So I follow exactly what you do. Not sure if the result will be the same with my own DB, but we may try it. I can then measure every step that happens to see a source of troubles ... thanks. And of course, I'm not sure there isn't any problem with my code. There most probably is. I do not consider myself as a good dev. Rather dev with a lot of "luck" 

[michaelbechtold]

Hi Menion,
I am kind of glad about what you feel with your 320 MB track DB ...
That may in the end trigger a solution like a second track DB for "historical" tracks, with the standard DB only holding the latest tracks.
The user should get a button for bulk move - back and forth.
The new sync feature should only work with the current track DB, not the historical one. However, historical tracks shall not be deleted on the server ...
Just some thoughts.
Cheers
Michael

[Menion]

It may be doable, but as a first step, I will definitely try to create a better structure for the data in the database. Offloading content to the second file complicates a lot of existing features, so it's definitely something I hope won't be necessary.

Sync service may help here of course by creating something like an "Online only folder". We will see this year ...

[slarti76]

I am kind of glad about what you feel with your 320 MB track DB ...
That may in the end trigger a solution like a second track DB for "historical" tracks, with the standard DB only holding the latest tracks.

Well, this plays right into my perennial idea for the sync function in LM4 to be able to upload everything, but choose which folders to sync on a certain device. Then the cloud storage would be the complete "archive", and I for example would sync the whole db to my tab, where speed is less important. On my phone, I could just sync just what's currently needed/of interest. And if you need sth from the archive, just select additional folders in sync.

But Menion says he has something like that on his list for the future, but first syncing has to be rolled out and work reliably in its basic iteration. Which I totally understand.

EDIT: Menion already answered along these lines. Will remind him once in a while

[freischneider]

.I have 300MB database. I have no speed problems in normal operation.
1500 Geocach (always displayed)
5000 trails from trail forks (2000 faded in from time to time)
I have an old Samsung S8.
The only thing I notice. If I forget to hide the trails, Locus takes a long time to start. We had already discussed the automatic hiding of certain folders or groups when exiting.
But even if I show it later, it takes 30s. That wouldn't be a problem if I could work with Locus for so long. But during the fade in a bar runs and I can not do anything.
The wish here would be that an entire folder or a group is shown in the background.

[Viajero Perdido]

@Viajero Perdido
what is the major problem you face with the Route planner?

Ah, confusion I guess, pilot error.  I know I can tap a POI (a geocache) and up pops an option to add it to the route, ideal.  So now I want to tap the icon where I started the route, to return to that spot.  Tapping this kind of live point brings up, basically, a dialog for advanced users: a triangle, a box, a bent arrow, and a User Guide link.  Aaagh, back up!

So basically, different behaviour when tapping a live point, depending on the style of point (geocache vs triangle).

I must remember, do not touch triangles, instead hit the "+" button always to add to the route.  And I should finally read that manual, yes.

[joeloc]

My database is 1.4GB. I still can't see how this would affect changing/deleting a single point of a single track so badly, but I know nothing of SQL, let alone its Android implementations. What I do know though, is that if your tracks where simply a doubly linked list like in the good old days of C programming, Locus would likely be orders of magnitude faster :-). And if Locus used GL or Vulcan or whatever it is these days in Android, I could enable 30.000 tracks instead to 30 and still be 60fps.instead of 1fps on zooming :-))

Only very few of my tracks and points are enabled at any one time. I'd love to see more, but unfortunately Locus also gets unbearably slow on startup and zooming then.

I'll upload my zipped database somewhere and email you a link, menion... if you want to give it a try.

[joeloc]

Database size is indeed the issue with editing performance. I deleted mine and imported a single track only: Editing points is super fast, like it should be.

Editing the same points of the same track in a 1GB-Database: Locus spends a full minute on confirmation. Nothing else(!) in the huge database is enabled. I mean... what the heck is going on here? Why do totally unrelated and non-enabled parts in the database slow down any edits to an unimaginable crawl?!

No idea on your SQL stuff really, but that simply cannot be right. Do you maybe run a weird "sql commit" and "compact database" on every single operation?

I really wish there were more power users out there so these things couldn't be ignored for years and years and more years. With a few hundred tracks only, you will never notice anything odd on a fast phone. Obviously, editing tracks will consume orders of magnitude more battery this way. But since people usually edit at home, that won't matter either.

Ps, menion, I PMed you a link to a huge database if you want to check. Couldn't find a recent email address, sorry.