Messages

All locus notifications are active
Permissions for Locus are active except physical activity.
Out of my curiosity, what is "physical activity" in locus for?
Thank you

I think that's for the new (but beta) auto-pause detection.

Hi Menione. Backup files sent to the cloud are too big. The last one has over 0.5 GB. Most of the space is occupied by the track.db (800 MB) file. It is unnecessary to back up routes and points for the Gold version because they are stored in the Webplaner. Would it be too difficult to miss these files for Gold users from autonatic backups?

I strongly oppose leaving out the *.db by default. As an option, ok, but in my view, this is an absolute necessity - you can never rely on online storage service, I want to be able to restore my database even when e.g. Locus Web is down.

UI - I think SET/Recalculate position should be swapped. Typically, bottom right has OK (what you could say "Set" is, and it was there before). In my quick workflow I almost end up recalculating all when I just wanted to change routing profile.

My thought precisely. "Special operation" in the lower right is a recipe for disaster

Yes, it should be by its "Created time" parameter. And well, you know. Waypoints in the app are painful and need a new system for handling them. Old problem ...

I could start again about my hope to at some point being able to create waypoints in the track editor, so they have a datetime. It's one of my biggest annoyances that waypoints created during recording have a timestamp, but when I forget them and want to add them later on, they won't have a timestamp that fits to the track.
Not all waypoints are POIs, like "hut", but things like "put on snowshoes", "removed crampons", etc. For those things, times are of relevance, especially if you use the same trail several times.
Well, I'll keep hoping...

There is more options on how to improve Presets. I'm still playing in my mind with two
- remember state before applying preset and allow restoring the previous state (already used in the navigation!)
- change the whole concept that you will be always in one active! preset (profile) and will just switch between them

I don't think the second option is a great idea: If implemented like that, every change of a setting *must* also change the active preset. That's definitely not what I want: If e.g. I change the map theme, I still want the original preset theme when I next activate it.
Only solution to this, I think would be that every change puts you in "unsaved preset", which you then can save, or discard when activating another preset. That would actually be cool, but I image it being rather complicated to implement.
Currently, I'm very happy with the existing system.

I just noticed a change in the Track Editor (aka "Fine-Tuner"): When clicking on a point, the date/time is not shown anymore in the pop-up. Could you please bring that back, at least the time? I really think it's a big step back, I need the time all the time (no pun intended), e.g. to find out where the rest was in a track. Now I need several clicks for the details for every point! The time only takes 5 characters, so I don't really see any reason to get rid of it...

These no go areas are very important to force the route algorithm not to route through Italien villages. Very dangerous in the Alps.

Off topic, but why are Italian Alpine villages dangerous?

This will not change route length (still 84.4km) but
calculated time dropped to 1:47h. This should not happen bcs route doesn't changed.

Well, technically the time should be at least a few seconds longer, because a waypoint is supposedly a stopping point, so you have to break and afterwards speed up again.
Ok, joke aside, at least I can understand why the result of the underlying algorithm would not be exactly the same. Of course it makes no sense that it's shorter.
(and yeah, I'm working in the train business, where stop-or-no-stop is quite a factor...)

Got two small observations:

• The new "minimized point/track pull-up" is nice, but I would prefer if that flag is "sticky". Let's say I have several tracks close to each other and click one, then click the pull-up title to make it small, to just see the name. Now I click another track, but I get the big pull-up again. It would be nicer if the pull-up stayed minimized while clicking through points and tracks. Once I unselect everything, the flag is cleared, so next time I click something I get the full size again. In short: "When track/point clicked && already a pull-up shown && pull-up minimized => show new pull-up minimized"
• I never before saw this "Show View" function. It's nice, but - at least on HD screens - basically useless, because it's so small. On my screen the >50% transparency part is ca. 3x3mm, and when I'm e.g. on a motorway, which is usually yellow or orange, it's almost invisible. Could you add a %-size selection in settings? Btw, when I long-click the button in Quick Settings and chose "Information", an empty message is displayed.

"_themes" is an ugly name, also having all user content beside each other (themes, vectormaps, srtm...) is good for external backup. Better order, easier to find...

Theme attached.

I agree. It's more complicated to set up automatic backups (e.g. with FolderSync) if data like this (that I want to backup) is in different base directories, together with other data like maps (that are too big for regular backups). Same applies for mapsOnline/custom directory. Why not put all this under "data", and only the actual maps under "maps*" ?

Menion, I was wondering:
You're not the first to suffer under Google restrictions. I know quite some apps that offer a "Google-impaired" version on Google Play, and another without those restriction on their website.
I mean, I'm not an expert on Android development, but if I remember correctly, you can request any Android right from the user if the app is sideloaded. So you could tell the user: "Play version only allows to store map and other extra data in internal app dir. If you need to access data stored anywhere on your system, please install the version from the website (sideload): <link here>".
Wouldn't that be a compromise to appease Google and the power users at the same time?

But it would be up to Menion to always look at int SD mapsVector for themes, even if the maps are on ext SD.
@Menion: what is your judgement, pls. ?

Sounds reasonable, and I additionally think the theme folder name is just a historical, but ugly thing (mapsVector\_themes). I'd even drag them up one level, so that we may have all extra content on one level...

Maps\
MapsOnline\
MapsVector\
MapsVectorThemes\
SRTM\
..

+1
It's always a pain to set up syncs (e.g. with FolderSync) that sync the themes but not the (big) map files.

You are right, Tapio. But a lot of flexibility is lost, isn't it? It is no longer very pleasant.

If I have to decide between performance and still-being-able-to-use-all-my-maps, that's much more than "flexibility". For the first time since I'm active in Locus testing-and-giving-feedback, this could be a make-or-break-moment for me. My outdoor phone (XCover Pro) is neither the fastest nor has the most internal memory. I'm not gonna use my "good" phone for outdoor stuff, so I'm not gonna say it's a no-go, will have to see how it performs, but I'm really anxious...

Menion,
[snip]

I really have to agree with Michael here. I have no problem to open a Help Desc topic, that's not the point. But this is too slow for this important topic. I have friends for whom I am the "Locus guru", but who would never take the time to log in on the help desk or whatever. And they all have big maps on extSd that they can't move to internal.
And I'm still not even sure from the Manual entry: Does Locus even offer to move all data to extSd instead of intSd on first start with new version? The manual is not explicit on this. I'm honestly not willing to try out Beta this time (even though I always do), because this is obviously a one way street. I would be ok if you say "Google forces my hand, for now you'll just have to do it, and you can move to extSd, but next I will implement way to divide big and small data between intSd and extSd". But making this dependent on a lengthy voting process is very disappointing - and potentially p***ing off many users. As Michael says, don't underestimate the amount of users with cheap phones with small internal SD, slapping a big MicroSD into the slot...

"Is it then possible to divide app and data over private directories in internal memory and SD card" - not yet. If there will be bigger interest, I may work on it and this is definitely a doable task.

1000% supported! I have very big non-vector maps (OruxMaps format) on extSd, which won't fit on intSd, but also don't want to take the performance hit to database operations on extSd.
I don't want to spend lifetime getting angry at Google for this change, we few people won't be able to change it. And I don't really care about the actual paths to data (I would care about inability to share this data, but I don't need that, so I'm fine). But if there's any way to make use of the data on int and ext SD at the same time, that would be a big improvement! I would probably wait with updating Locus if you now tell us, you'll tackle this... Thx for considering!