Re: [APP] - version 3.35.+ ( 7. 12. 2018 )

[Menion]

balloni, are you sure that you perfectly understand how presets works?

I'll try it simply:
- every preset has predefined list of supported settings (settings that change)
- by activating preset, all these settings are applied
- ... and that's all

What happens to you is that one preset change these two options "on". And they just stay "on" because of no other preset set it "off".
Better?

Understand your use-case. You need a) create a preset that simply turn any extra settings "off" or b) set these two lines "off" in all other presets. Hm ...

[Menion]

New Beta version 3.35.2.6 RC is out.

If you find the time, give a try to improved "search for tracks" and also sorting tracks in the folders.
Hope it will work fine and search time won't be so terrible. Thanks

[balloni55]

balloni, are you sure that you perfectly understand how presets works?

you described it well thanks, but I remember that I also stumbled some time ago

Question,
wouldn´t it be more understandable and simpler for user if there is one "master setting" as a basis for all presets with complete available preset content and user select/deselect/modify each preset?

[Andrew Heard]

3.35.2.6: Sorting: 157 tracks, sort by Closest, 34s on new tablet. Sort by Distance to Start is <1s but sort by Distance to End is ~10s. On mid range Samsung phone, 173 tracks, sort by Closest 23s, sort by Distance to End 4s. I don't mind because I'd rarely sort by anything but creation date. But more concerning - if currently sorted by Closest, then when display turned off then on again, the sort (Loading...) is performed again. Can this be avoided?

Search in Data Manager: nice feature. It doesn't appear results are in any useful sorted order?

[Menion]

@balloni55
not sure if "master present" will be more logical to be true. It will still need an explanation. Also, you may simply do such "master preset". I never found an ideal system.

@Andrew Heard
hmm, I've expected shorter times. Most probably your track database is huge.
Good point with repeated sorting after return to list ... I'll look at it, thanks.

[erfi]

3.35.2.6: Route planner don't work correct. I can't choose with a finger tab a visible waypoint to route.

[Andrew Heard]

Most probably your track database is huge.

@menion - ahh yes it's not just searching in current folder. Is there a simple way to check # tracks?

[michaelbechtold]

3.35.2.6: Sorting: 157 tracks, sort by Closest, 34s on new tablet....

My times are massively higher, as I have tons of data from recent years.
Questions to Menion:
- did you introduce the bounding boxes for tracks that we discussed months ago (min/max in each dimension, as part of the track data model) ?
- computing the distance of a point to any bounding box rectangle (representing a track) is a simple formula rather than traversing 1000s of points
- if you then limit the number of items for the result (like your "first 10, 25, 100, ... or so in other places of Locus) the search will be really fast, as you get the right "candidates" cheaply.

Maybe you do such already, but the high amount of tracks is still killing. In particular as there are no restrictions to a folder or so, right ?

TXs and cheers
Michael

[Menion]

@erfi
thanks, I'll look at it.

@Andrew Heard
search in the current folder is currently not possible

@michaelbechtold
no, nothing like this is done. It was the first quick attempt which gave for me 300 MB database times below 10 seconds. Interesting that your times are so much higher. Maybe database handling in Android 9 is so much faster? Anyway as I do it now, seems this is not the correct way. Other possibilities require an update in the database and a lot more work. Hmm, shame ...

[Tapio]

Half related: I have never exactly looked at it - Does Locus ever do database compacting or will it stay bloated, if, say, I delete all entries?

[michaelbechtold]

PS: even if compressed: my tracks-DB is 800 MB meanwhile. So I'd prefer to have a read-only version (with older data, or whatever selection criteria) on external SD, while the "active" tracks-DB would stay where it is.
This would imply that there is a Locus copy job from the active to the secondary one.
Any thoughts ?
TXs and cheers
Michael

[Andrew Heard]

search in the current folder is currently not possible

@menion - I think this is where there is confusion for the user (or at least me) - a simple sort is performed purely within the current folder, but your new advanced sorting methods are across all folders. I can appreciate it will take a lot of time to sort all tracks across all folders, something not possible before now, but the user shouldn't have to incur this time cost if the current folder only has a smaller number of tracks.

[lor74cas]

search in the current folder is currently not possible

@menion - I think this is where there is confusion for the user (or at least me) - a simple sort is performed purely within the current folder, but your new advanced sorting methods are across all folders. I can appreciate it will take a lot of time to sort all tracks across all folders, something not possible before now, but the user shouldn't have to incur this time cost if the current folder only has a smaller number of tracks.

In folders there is:
sort for current folder
filter for current folder

In / of data manager there is a filter for all track folders

In this way you can filter all folders or one folder, slow or quick but all depends on how many tracks do you have in the folder.

[Tapio]

Oh, seems like Menion has got a lot of work to do.  Both on database side and UI. E.g., as for the UI, as a user I espect searching for tracks/points to (also) be accessible via the data manager - not necessarily I go to the general search page, where it currently resides.

So does Locus do database maintainance? Like, compacting?

[Menion]

New version with search V2 in preparation, give me day or two, thanks .

And @tapio, no, no optimization on the database is done in app. SQLite re-use empty spaces in DB after removing content, so some kind of "VACUUM" should not be needed. I have tested it on my maybe 5 year old DB and the result was > size reduced from 250 MB to 240 MB and DB benchmark: no result.