Messages

When creating a new point (by long tap), the folder for that point defaults to the folder of the last point CLICKED. That's wrong, it should default to the folder of the last point ENTERED.

Viewing points and entering points are two very different things. I have plenty visible point folders, yet during a trip, I always want to add points to a single folder for that trip.

I am pretty sure this worked properly before. The change/bug must have been introduced lately. Please fix, I keep creating points in random folders just because I view stuff in-between.

Regarding hiding of UI elements to prevent Burnin: Latest beta makes everything disappear nicely, except the red track recording button. I configured it to hide as well, but it doesn't.

The copyright button also cannot be be hidden. 50% will only delay the damage, not fix it.

You will also need to improve search. It should work simultaneously in addresses and points.

I completely agree. Locus search is pure usability horror from last century. A proper search is ONE SINGLE TEXT FIELD that simply searches EVERYTHING at once and shows results as they come in.

Making me decide in advance on where I want to search is just wrong on every level imaginable.

Anything else serious?

Buddy tracking... sharing points & tracks with buddy... basically anything that's needed when you travel with a friend. These things pretty much remain in the same sad state since multiple years now, no fixes, no enhancements, no nothing. I've kind of given up on the topic, but since you asked... that's one point where Locus is seriously lacking.

Btw... downloading openandromaps internally in Locus has always been about 5-10 times(!) slower than downloading the same file directly in a web browser (1000 mbit line). Some less than ideal http download code? Minimalistic buffer sizes?

You cannot view this attachment.

With Locus I can reach about 1MB per second. With Chrome or Brave, download speed is closer to 10MB per second.

I think they are exaggerating a bit here. Why do they always have the screen on ? Normally they are hiking or biking and look at the path. On Locus you look only if you need information. So the screen can stay off 70% of the time.

Exaggerating? I can assure you the permanently burnt in locus on our screens is very real, on multiple phones meanwhile. And Locus is not even configured to be always on, I'd estimate around 3-4 hours total at full brightness each day (on bicycle handlebars). That's apparently enough to kill displays in less than a year. Affected so far: Samsung Galaxy S10+, S20FE, S22Ultra. Next in line waiting for Locus tattoo: S23Ultra.

Obviously this is a "power user scenario" that won't affect too many people. But why kill displays if you don't have to? Software counter measures (ui pixel shifting) should be rather simple.

Alternatively, should Locus warn people with a huge red alert when your screen on time exceeds 2 hours for the day? "DEAR USER, PLEASE TURN ME OFF, YOU'RE USING ME WRONG" :-)

[@joeloc]

@joeloc

hmm nice main menu in display. And what you suggest? With Locus Map 4 you may hide everything except "Copyright" button. But this one will be in the next app version semi-transparent, so at least a little smaller problem.

I don't know a perfect solution... but Locus is responsible for destroying amoled displays for a long time now. It has by definition by far the longest screen on time at the brightest setting of any app. Putting some more thoughts into this is overdue.

Auto hiding the menu bars is obvious... but what about other elements? Like track recording icon? GPS icon? Scale?

Maybe a little transparency for these (80%?) could help, without causing too much usability trouble? A better but more complex solution might be to shift the whole UI around SLIGHTLY by a few pixels every day. Half a millimeter or something is hardly recognizable but will go a long way in protecting displays.

You cannot view this attachment.

Another Locus Burnin victim... not a cheap "S20FE" this time but last year's flagship phone Samsung Galaxy S22 Ultra. Not even one year old and not even mine, so you cannot blame it on extreme power user habits :-).

How many more phones to destroy until you realize Locus has a problem? Obviously other apps would burn in as well, but it's LOCUS that is visible all the time at full brightness. That's the job of an outdoor navigation app after all, isn't it?

So what's going to happen? My gf is scared to use Locus on her brand new S23ultra now... and she is right... Locus is a phone killer :-(

You cannot view this attachment.

You cannot view this attachment. 

Remember just a few months ago when I complained about the silly and utterly useless super high contrast copyright button and risks for burnin?

You cannot view this attachment.
It now found its way to my screen permanently and gets brighter every day. Thank you, Locus BURNIN. If I weren't up for a new phone anyway, I'd be quite pissed off now.

I know I am a mega power user with 5+x hours locus screen on time at full brightness each day, but I can almost guarantee that you will destroy more displays pretty soon unless you finally do something about it.

Menion... could you please please pretty please consider accepting XML files for "open with..." and "share" with Locus?

I am meanwhile completely fed up with explaining people where to put their custom maps and overlays... it's simply beyond the ability of a normal user, especially now that Locus has to hide its home directory in funky places, not easily accessible by your default file explorer.

The Strava Heatmap nowadays is THE SINGLE MOST IMPORTANT TOOL for mountain bike navigation and beats any OSM tagging hands down all over the world. But getting it into Locus requires some kind of advanced super knowledge at the moment. How great would it be if you could simply click on the XML attachment here, choose open with / share with Locus, and simply be offered to import the contents (if any).

Locus should not only accept custom map definition XML files, but also any other type of file that it deals with: database backups... cursor definitions... dashboards... god knows what... zipped or unzipped. Just parse whatever you're given and present the user with reasonable choices on what do to with it.

Thanks.

Since a few versions, Locus has this hickup where it overwrites the last point when I add another one.

Right now for example, while I am planning a new trip, I scroll around the map and add new waypoints whenever something looks interesting to me. Every new point silently overwrites and deletes the last one I added. This drives me absolutely crazy.

It doesn't happen all the time,  but when it happens, it keeps happening. Restarting Locus or using another folder for points might fix it for a while, but the problem will come back.

Maybe re-check your SQL commands? It sounds like something super silly really... like that bug when deleting points in the editor took minutes instead of milliseconds.

edit: also, sometimes I add a new point and its state is set to invisible right away.

Is cloud sync actually supposed to work? I just tried it for the very first time and it remains at 1% forever.

@joeloc - maybe just 1% for a longer than expected time - I experienced similar behavior with the initial bulk upload - have a look at & maybe vote or comment on my suggestion https://help.locusmap.eu/topic/26282-provide-more-info-while-performing-cloud-sync. I use manual cloud sync & it's a great facility, but would like to see more details during progress, and finer grained update of the progress bar.

More details and progress updates are absolutely required, especially when performance is that miniscule. I have no patience for staring at a never changing 1% number. And since there is no network traffic worth mentioning during that time, I simply abort.

Is cloud sync actually supposed to work? I just tried it for the very first time and it remains at 1% forever. Internet monitoring shows a few bytes(!) per second upload speed. What's it doing... uploading every single track point in a single http request?

My database is only around 1GB currently and if I upload eg a Locus backup zip (800mb) directly to some random ftp server, it does 5Mb/second and finishes in a few minutes. I assume Locus should be about as fast when doing its sync stuff?

I guess this is primarily an Android issue? or could zero (or defined setting threshold) satellites be an indication to auto-pause?

Funky track messup point clouds when having breaks inside has always been a problem for Locus. It's bad on my S20FE, it's super horrible on my GFs S22Ultra.

Obviously it's mainly Androids fault to supply bogus data, but Locus could also try fixing this more thoroughly. For example, your recording profile could contain a max speed setting above which points would just be dropped. So if in one second my position moves more than eg 30m, don't record it because it must be a bogus indoor crap point.

regarding copyright button: at least make it 60% visible only... and just 10% after I clicked and read it once for a specific map. that would still satisfy your moral obligation to map creators and stop destroying your users phones.

bright white pixels on an amoled displayed at 1000 nits 8 hours a day is one of the worst things you can do to your phone. solution: just don't!

map itself is not problem since it is always different. the rest of your statically placed and always visible UI is not 100% white as far as I can tell. But yes, it is a problem too. And not a theoretical one mind you, I have Locus UI burnin on 3 phones already.

no, this will not happen to casual users.

yes, this will happen to power users who spend their locus life in bright sunshine every day.