Messages

[@slarti76]

@slarti76
not exactly overlooked. I wanted to answer later and forget. Thanks for the reminder!
As I see in the code, this was modified at 31. 10. 2022 and it works as it should: the second part of the route should have time of this first trackpoint. Anyway, there is the condition when this is applied: "Created time" of the original route is identical to the first trackpoint. Is this your case? Otherwise app considers the original route time more important than trackpoint times and preserves it.

Thx for the answer, that condition actually makes a lot of sense. And it explains it: I did delete points at the beginning of the track before doing the split - then the condition was not met anymore.

Thinking about it, probably the best solution would be the additional option to sort by "track start date/time". I would even say that in 99% of the cases that's what the user actually wants when selecting "created by". Why would you sort a self-recorded track and an imported track differently, just because the imported track has a later creation date, even if it's chronologically ealier?
Is adding that sort criteria feasible?
Of course, the workaround is to always *first* split a track before doing any other editing - but obviously I hope you agree with me that "Track start time" is a good thing to add

Little weird observation in my recent holidays:
I split a track A into A1 and A2. Then both tracks had the same creation date/time (I think we discussed this a while ago, before that both parts got the current DT as new creation dates). Now when I sort the folder by "Created", it shows

• A1
• A2

- correct!

But when I reverse sorting, it still shows

• A1
• A2

- not really correct, as the second part of the original track is surely after the first part and thus should be shown before in the reversed list.
I assume, as both tracks have exactly the same created date/time, Locus then reverts to alphabetic sorting as "tie-breaker", which keeps A1 before A2.

Proposal:
As we agree that it's not helpful to set the Created DT of split tracks to the current DT, why not set the DT of the second part to its first trackpoint?

Hi Menion
Don't wanna be annoying, but you answered a lot of posts, but no reaction to this - overlooked, perhaps? Thx!

I think we discussed this a while ago

Yes (search for "split"), we did, you did, I thought it's all sorted 😁.

Yeah, there's always a special case to be overlooked 

Little weird observation in my recent holidays:
I split a track A into A1 and A2. Then both tracks had the same creation date/time (I think we discussed this a while ago, before that both parts got the current DT as new creation dates). Now when I sort the folder by "Created", it shows

• A1
• A2

- correct!

But when I reverse sorting, it still shows

• A1
• A2

- not really correct, as the second part of the original track is surely after the first part and thus should be shown before in the reversed list.
I assume, as both tracks have exactly the same created date/time, Locus then reverts to alphabetic sorting as "tie-breaker", which keeps A1 before A2.

Proposal:
As we agree that it's not helpful to set the Created DT of split tracks to the current DT, why not set the DT of the second part to its first trackpoint?

In the news it says:

"more accurate contour lines – in the new LoMaps we generate more detailed drawn contour lines from 1" height data, while maintaining the volume of map files. We have completed Europe so far, but the machines are running at full speed, so you can look forward to further additions soon."

Does this work for existing (already downloaded) HGT files or do they need to be downloaded again? If so, does Locus do that automatically? Or is it a map feature independent of teh HGT files?

... after examing all settings I saw that the text size was set to 0.
Change to 100 produces a better result:

That's what you call a better result? 

I do see the complexity in combining all searches together, and I can live with having to select different search "means". But one major bother, that should be not too difficult to change is this:
Everytime the search scope is changed, there's a new, empty input field. Why not prefill with the search term already entered in another search? All the time I start typing into a search field before realizing I have the wrong search - then I change it and have to start from scratch (unless I thought of that and copy-pasted the term, which of course is also a bother).

PS: I just realized that this works between internal point and track search, but that's the only place I found.

[Problem with SRTM/HGT:]

Problem with SRTM/HGT:
I downloaded some 1" elevation data from here: http://viewfinderpanoramas.org/dem1d.html
...

Go for Sonny's LIDAR DTMs instead. Much better than SRTM.

Thx, seems to work with that. Still perhaps worth looking into whether the (other) data is buggy or Locus...

PC browser goes to GD folder from Aug 2nd, version 4.18.0, not 4.18.1, even on PC.
Or do you have a MAGIC link instead :-) ?

Sorry, my bad, didn't see it's about the .1

I'm missing the 4.18.1 AFA on GD, Menion.

Me too ...
The link is present, but doesn't work.

Had the same problem on phone, but worked on PC browser *headscratch*

[Problem with SRTM/HGT:]

Problem with SRTM/HGT:
I downloaded some 1" elevation data from here: http://viewfinderpanoramas.org/dem1d.html
To my surprise, suddenly the deepest canyons of our planet are in Northern Italy, and the Swiss lakes have the deepest trenches - have a look at the screenshots...

(I did clear all temp/cache data before turning on map shading again, so shoudln't be a caching artefact - also obvious from the -21753m altitude shown in att1)

whatever you do for iOS should not screw the 100000s of users from whom you make your living.

Locus on Apple/iOS??? When did I miss that? Definitely can't find it...

What about then at least adding support for PlusCode? That can be copied from Maps with one tap and surely be parsed by Locus search without ambiguity?!

@slarti76 - thanks, hadn't used +codes before. Still slower (many more taps) than direct "share" of a point from my testing:

• drag POI details down a few times
• tap on "See all"
• tap on +code (very little visual feedback BTW)
• switch back to LM4
• open Search (maybe side panel button)
• paste clipboard (maybe more steps here)

Yeah, agreed, but
a) if we don't have another always-working solution,
b) surely no problem with parsing (well-defined as far as I understand)
c) at least last two steps could be improved if Locus adds a PlusCode support by automatically inserting clipboard content in search field (if it parses as PlusCode).
Heck, Locus could parse the clipboard when opening the search and automatically switch to PlusCode if it parses.

Honestly, I'm a little diappointed how the missing ability to correctly share positions from Google is waved away here. Menion et al should be aware that this is an ability that is absolutely crucial for "normal" users. OSM is nice and well, but let's face it, GMaps will always be more up-to-date. Rarely anyone relies on OSM POIs alone, so we all search stuff in GMaps all the time and want to easily enter the points in Locus. This is not something to just say "hasn't been working for a while, so what?"...

Hi guys, sharing points from Google Maps does not work for years as I know. Somewhere in 2021 maybe even later, they changed the format and the information app receives can no longer be simply converted to any text or coordinates.

What about then at least adding support for PlusCode? That can be copied from Maps with one tap and surely be parsed by Locus search without ambiguity?!

The altitude threshold is, after using "Update elevation", correctly set to a value of 3m. It is an intent. This method completely changes elevation values so the app set the threshold to get the expected result. The previous value is no longer valid.

I respectfully disagree: The Altitude threshold is part of the track settings, so a mere "recalculate" shouldn't change that. As far as I see it, "Update elevation" is needed when you recorded a track with GPS altitude values and want to switch to SRT-based values. Or you have newer SRT files. Why would that mean that you want your threshold to be reset?
I mean, it's OK, can live with that, just don't think it's intuitive to change settings from the settings dialog as a side-effect of some other function - no other track menu function has such a side-effect...