Messages

Definitely long times, hence my request to put a warning into the documentation.

But things get worse than that:
- also connection to linux via file system integration (Nautilus and alike) stop at the /Android/data/.../Locus folder, which is shown empty, although it is not.
- trying to migrate a huge SRTM folder makes Locus die after quite some time.

Has someone tried to use adb file system access to those private folders?

If the latter does not fly, dire times are ahead.
As long as Locus does not provide 1" resolution DEM files, there will be no way - that I know - to make Locus work with better DEMs than Locus download provides.
Also it would be bye-bye to side loading other map files than LoMaps. You could only use map sources that provide Locus-Actions to install with the help of Locus itself.

For 1"-SRTM Menion would need to provide some download feature for Sonny's DEM data e.g. With wild card selection.

Someone has smarter ideas to overcome those limitations?

As of now (late 2021-12-02) today's findings mean: stay away from the latest Locus version for now.
And NEVER EVER deinstall the current version.

@Menion:
I could not wait until next week because I am so curious ...
So I started trying, not on my S10 for daily use, but on the Tab S6 light (64 GB total internal space, large external SD) and found some essential problems.
My plan was to use the private section of internal SD (/Android/data/menion/...) as the main Locus location, then set the external SD for mapsVector and SRTM.
What happens?
1 long start - question: do or postpone
2 offers move
3 LMP loss of access warning
4 selection private - long pause 3 GB free - not enough - cancel
See attached for the situation: need for 1 GB (see external SD option), 3 GB free on internal SD.
Why is that? Most probably because of the SRTM and mapsVector that sit on external SD and require 75 GB in total. So I should have unchecked the two choices, right?

Which brings me to an overall judgement:
1) the steps and explainations are quite OK, but
2) it lacks overview for the user and
3) a plan

And there is a good chance that a user has ONE view of the storage reality, while Locus has another. Recipe for disaster, pain and discussions.

Hence I propose you do not offer the migration immediately, but produce a full storage picture how Locus sees it.
All the elements, with their sizes, and the options how and where to move them. And send this as a mail (share ...)
Something like:

Current Locus storage layout
=======================
Locus main: internalSD/Locus 1 .5 GB
Locus mapsVector: externalSD/LocusMaps/mapsVector 20 GB
Locus mapsVector: externalSD/LocusMaps/SRTM 55 GB

Internal SD capacity total/free: 64 GB / 3 GB
External SD capacity total/free: 256 GB / 151 GB

Next: what should a non-IT person do with a non-trivial situation?
1) understand the picture
2) understand the options

Can people derive that themselves? Hardly, hence they need advise.

A text that explains the options given various scenarios should be added to above report:
1) the total Locus storage fits fully into internalSD: do whatever you want, but internal preferred for data safety and performance reasons
2) current data on externalSD does not fit into internalSD: ...
3) ...
some homework here for all potential cases.

My setup above would need the following actions:
1) /Locus goes to internalSD
2) AT THE SAME TIME (!!!) current SRTM and mapsVector need a choice for their final target (I know you could uncheck both and doe manual stuff later, but that is not good, because it leaves a number of people stranded, in particular as the file managers fail so far)

Also: give warnings about long wait times for steps that take long, and tell users to click "Wait", not abort. Some of the steps 1-4 take unexpectedly long. I trust for a good reason, but people may wonder ...

So far my 2c

Cheers
Michael

I just tried to populate the private mapsVector on private external SD and failed with both, Solid Explorer and x-plore.
You can READ private data on external SD, but I failed writing (copy some file in a test)
That would leave two options:
- take SD out and put it into a PC/MAC/linux box and do the dirty work there
- use adb while connected to one of above
I have done the first, but only read about the second.

Same country, same ideology, same stupidity.

Really COOL, Menion, TXs a lot !!

Related question: if I (need to) put some maps into this external SD private folder, would it still be possible to ADD (via map manager) a folder that is a subfolder of the main Locus structure on internal SD private folder? Solid Explorer, x-plore or adb/PC needed for populating that extra folder with maps, that is understood.

TXs for your quick response, Menion.

As I was not sure about the risks, but had understood well that there is no way back, I avoided betas this time (other than all the betas before since years ...)

I will try on by A11 tablet next week. But let me also understand what below "btw" means in detail:
does this mean that ONLY the mapsvector could be moved to external SD private folder, while the other Locus folders go to the internal SD private folder?
Or did I misunderstand here?

Hi Menion,
can you pls. state your findings clearly re. EXISTING usage of root level map folders on internal and external SD (i.e. no re-install).
The question behind the question is, if an update will screw up the Locus install into unusable because of capacity limits (maps distributed on both, internal and external SD).
You mentioned in one post that the API 30 would tolerate existing access. But for how long?
There is need for clarity before people dare an update ...
TXs and cheers
Michael

Menion, I have tons of large maps on SD card, even on older devices. There is no performance problem using them in higher ZLs (although for sure you can MEASURE a significant difference).
A DATABASE on SD however, I would not even try, because the effect is obvious.

PS: plus over time the track DB alone gets HUGE. So you have quite some data for internal storage to keep performance alove.
Mine has crossed 1 GB last month. And there are people who are more active than I am.

Menion,
I am not sure you understand the risk Locus and Asamm are in.
Pointing to voting is denying intelligence. Why?
Take the max voted topic, and divide it by the number of users you have. How many zeroes behind the dot - before a non-zero digit appears?
In other words: your risk is the unknown, and the invisible. And pointing to a hence meaningless voting is slapping those unseen > 1000000 users in the face.
Now, let's employ some intelligence. Proposing people buy new phone with more capacity - even as a joke - is not. Do you agree?
Another fact is, that most Androids are NOT Pixels. But rather the majority employs external SD card support, to allow for cheaper storage extension. For mass storage eaters like maps, e.g.
Then take Michal's advise (no DBs on SD, please). Put everything together, and employ your own proven intellect.

Menion, that is not what your users can expect from you.
I am the most outspoken on that one - easy as a Locus user of many years and a comp.science person since 40 years.
But you should be scared of the silent mass who is not even aware of the pot. tsunami hitting them.

As a partial remedy you should establish the possibility to have both /Andoid/data locations used. Following Michal's point, the right approach would be to have the app function and performance critical parts on the internal private location, while the mostly readonly data like maps and SRTM and alike are allowed on external SD private folder as well.
Then capacity INSIDE the Locus only world will not bite - users do not have to buy a bigger phone :-)
My other challenges are not met, but for the mass of users above should be safe - and keep peace in the user base. And Asamm ...

Good luck.
Cheers
Michael

@ michaelbechthold.
I agree with you that it is a dirty trick of Google that you cannot even share (large) osm maps which do not contain any sensitive data to be protected. That app developers can't even stand up to the giant means that the fourth realm already exists. Docile and obediently follow what is imposed, no resistance allowed.

That is the sad thing indeed. No resistance. Not even trying. Even giants know fear. And they are able to learn, though slowly. And the populace has to re-learn to speak out and up (I am not endorsing silly Querdenker stuff here).

I read thoughts about rooting. Here things go completely wild. Google pretends to secure privacy. And their failure to think it through properly we are talking about rooting. THAT's a real joke :-)

Although I thank for the mention of linking. I thought about that as well last week. But I hoped that privileged apps like file managers might be able to establish such without rooting ...

Menion, you never really convinced re. below points! So, pls. ask Google via your DEV account those questions:

- how to share a DATABASE of 1GB+ between two compatible apps (they have no right to play LM4 XOR LMP - not their business, it's user's choice)
- how to share double digit data files (non-media!) between apps (like SRTM data or large map files (vector and raster); apps from different developers.

Looking forward to their answer.

To be honest, I would rather not rely on SD card with its "ability" to handle database fast random read/writing, its stability etc. Not long ago I lost all my data on an SD card due to its malfunction and the necessity of formatting.

I appreciate your twofold warning, Michal!

Question to Menion:
I saw that many apps have a /Android/data folder on external SD, BUT their working directory in fact is on internal storage.
Are you able to access BOTH of them simultaneously? E.g. SRTM and large maps on external SD, while databases and other essential objects with high performance and reliability needs are kept on the internal /Android/data storage.

Hmm right. So maybe we should start recommend devices without SD card and bigger internal memory ...

And this is a BAD joke, Menion. In fact not a joke at all.