Topics

Hello Menion,

I've always wondered why the search in points sometimes returns results that have nothing to do with the search word or search string.

I just took a closer look and realised that this only happens if an attached photo was used as an icon for the point. If I replace the photo icon with a symbol, the corresponding point is no longer found.

I then exported such a point as a gpx file and looked at it with an editor. And indeed: The photo icon generated by Locus is coded with an exorbitantly inflated cryptic character salad (over 10,000 characters!!!). This even appears twice in the code, once between the tags <sym>...</sym> and again between the tags <locus:icon>...</locus:icon>.

Example:

<sym>image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABLCAYAAADAroEdAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAACAASURBVHic5Zt5jGXZfdc/v3POXd5S79XaVdU93T09S0+7x54x9owdj23i4CWON0jk ... (further >10000 characters)</sym>

<locus:icon>data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABLCAYAAADAroEdAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAACAASURBVHic5Zt5jGXZfdc/v3POXd5S79XaVdU93T09S0+7x54x9owdj23i4CWON0jk ... (further >10000 characters)</locus:icon>.

Even if the string of characters is cryptic and only rarely corresponds to a search string, it makes no sense for the search to include this code. If I search for "heu", for example, the point is found because the code contains hEU (see red font).

Is it even necessary to generate such a long code for the photo icons? And can't it be excluded from the search?

Supplement: This happens both in the official Locus version and in the new My Library version.

With today's update 4.27.1_1158 the search in points works again. Very nice.

However, the search in tracks and points only works correctly and reliable when "search also in descriptions" is deactivated. I can search for strings of any length, including individual characters.

If "search also in descriptions" is active, there are problems and incorrect results. Numerous points or tracks are repeatedly found that do not contain the search string at all, neither in the title nor in any existing descriptions. Even those that do not contain any descriptions at all.
There also seems to be a character limit here: For search strings with at least 4 characters it works correctly more often, but with 3 or fewer characters there are usually many false results. But it is not always clearly reproducible. In any case, the search with "search also in descriptions" is often incorrect.

I haven't used this function before and have now played around with it for the first time. "Close line and fill with colour" can be very practical for certain routes.

The function cannot normally be used together with patterns and/or colouring modes (except plain colour) (why not?). If I select arrows as patterns or altitude as mode, "close line..." is deactivated and vice versa.

Strangely enough, both are suddenly possible if I manually restrict the altitude mode to a certain range.

The altitude range of the example route is 41 - 96 metres. If I limit it to 80 - 96 m in coloring mode altitude, the colouring mode is suddenly displayed and the line is filled. However, this only applies to the areas between the route sections outside the set range. The line filling is therefore only applied to the part of the route for which no colouring mode is displayed. This is confusing to say the least. See screenshots.

In this topic I have already reported problems with the new My Lib database when icons assigned to points or folders are missing.

But there is another problem that affects Locus in general: The created audio coaches can be named individually and you can assign any icons to them.

If you delete or rename the corresponding icon zip folder(s) and then open the audio coach menu, Locus regularly crashes.

You then have no chance of replacing the icons that cannot be found with others. The only way out is to restore the removed/renamed zip folders (you should have backed them up beforehand), only then can you open the menu again and change the icons.

I had recently wondered several times why the calculated time with LoRouter, profile walking/hiking, was often significantly longer, even though I had planned the routes on flat terrain. Sometimes 20-25% longer than the average speed set with the slider.

The only explanation for me is that the surface/trail condition is taken into account to a large extent if it is poor. In some cases, after checking in openStreetMap, I found that large parts of the route were labelled with surface = sand and smoothness = very bad, for example. This didn't always correspond to reality, but of course Locus can't help that. But where the paths were actually bad, you can still walk almost as fast as on normal paths, and by no means 20 or 25% slower. In my opinion, the condition of the path is weighted far too heavily for the calculation. In most cases, 10 % would be more realistic. But I realise that it is not easy to find a generally good factor.

But: in the bicycle profiles, the surface condition is apparently not or hardly taken into account at all! I have planned several routes for testing in different bike modes, the surface of which consists of sand and is labelled with smoothness = horrible. LoRouter calculates the same time as on a smooth tarmac road, i.e. at pretty much exactly the speed I set with the slider.

This is bad, especially as the influence of a poor surface on the time required for cycling is much greater than for walking or hiking. Cycling on sand or on tarmac makes a huge difference!

Take this route as an example: 2 km of flat sandy track (and really bad loose sand) through the pine forest:

https://link.locusmap.app/t/8g4c6s

In the LoRouter walking profile with the average speed set to 4 km/h (navigation commands ON), Locus calculates 39 minutes, which corresponds to 3.1 km/h. (However, we needed considerably less).

The same route is calculated in the LoRouter bicycle Touring profile (set to 14 km/h) with 8 minutes, which corresponds to 15 km/h. And that's on a terrible sandy track!

I have tried it on several routes in flat regions, and the bicycle profile apparently ignores a poor surface. Why?

During my recent vacation, I again noticed some inconsistencies in the track navigation. Specifically, it concerns the recalculation in the event of a deviation from the planned route. It is not entirely clear to me which parameters are used for this.

As soon as I deviate from the planned route (beyond the set value, in my case 100 m), the route is recalculated. The entire route is then given a new name consisting of the date and time of the recalculation (see screenshot 1). In one case, a new track name was even generated, which was completely cryptic and contained the name "brouter" (see screenshot 2), although I created all routes offline with the LoRouter.

Unfortunately, after the recalculation I sometimes got the wrong ETA or time to target again, even if we only made a small detour.

After doing a few tests yesterday, I have the impression that the recalculation is not done with the parameters I used to create the route. Instead, it uses the last set parameters. For example, if I later created a different route with a different average speed.

I first created a test route with an average speed of 2 km/h (slider). Then I created a second route with an average speed of 10 km/h. I then navigated along the first route and deliberately deviated further and further from it. The route was then recalculated every approx. 100 m, which is correct. However, the time to target was calculated shorter and shorter and at some point corresponded to 5, then 7, then 10 km/h. Obviously, the recalculated additional distance is calculated using the last set average speed and not the one that was set when the route was planned. is that right?

In my opinion, it would be better if the recalculation was always based on the speed of the planned route.
As I said, this is my assumption based on my experience and tests. Hence my question, what parameters are used for recalculation during track navigation? I just want to understand how it works.

Translated with DeepL.com (free version)

Two issues with LoPoint photos:

I open My LoPoint photos and see a thumbnail list of my photos.
I click on any photo and see it at display width. The photo cannot be zoomed! And this is a new bug, on my old SG7 with beta 4.25.1.3 the zoom works.

At the bottom left of the bottom panel, the name of the LoPoint and the icon to the left of it are displayed.
If I click on the icon, the detailed view of this LoPoint opens. A narrow map section with its position is displayed in the upper part. At the top right is the round icon with the point and the four arrows (see screenshot).
If I click on it, the map view should open full page with the position of the LoPoint in the centre. At least that was the case in earlier Locus versions and that would be the expected behaviour.

Now it just opens the photo again when I click on the icon, not the map. Only when I close "My LoPoint photos" completely, the map is displayed.

I use the map rotation function very rarely and in these few cases I activate the function with a preset.
So I don't really need the map rotation button (small red arrow next to the map centering button). It's more of a nuisance because I keep touching it accidentally and unintentionally activate the rotation.
Even as a dual centering button, this happens again and again and annoys me.

So it would be nice if you could disable the map rotation button completely.
(I often need the map centering button, however. Unfortunately, the two functions are linked. )

I created a profile with Tasker that automatically activates the location services (GPS) in the smartphone for certain apps. This includes Locus, of course.

What I can't do: If none of these apps are active (not even in the background), the location services should be switched off automatically. This means after actively closing/switching off the apps.

Unfortunately, location services are switched off immediately if none of these apps are running in the foreground. This is of course bad and fatal in the case of active track recording. 😎

Can this be fixed with Tasker? That location services are only switched off when I actively exit Locus (Do you really want to exit) and none of the other apps are active?

Thanks in advance and best regards.

Under controlling > map screen, you can set whether and how panels and buttons should be displayed or hidden.

I have set all panels to auto-hide, hiding timeout is 7 seconds.

If the panels are hidden by double-clicking on the display or after 7 seconds, they remain hidden even when the display is switched off and on again or when switching to another app in the meantime. They are only shown by double-clicking on the display. That's how it should be.

However, as soon as I activate any dashboard, the top panel is shown every time I reactivate the display or switch back to Locus. The other panels (and the buttons set to auto-hide) remain hidden.

I would prefer the top bar to remain hidden like the other panels.

I don't know if this behaviour has been reported before:

When I search for a LoPoint category (e.g. supermarket), the results are displayed on the map as icons (screenshot 1).

If I zoom a little further into the map, more and more LoPoints of other categories are displayed as red square icons: Peaks, churches, other... (screenshots 2 and 3).

(I have set the red icon as the default point icon in the Expert Settings under Points).

Of course you can live with this, the LoPoints you are looking for can be easily distinguished visually from the red icons, but it would make more sense to display only the LoPoints you are looking for.

I have about 20 dashboards, many of them for testing purposes only. In the "Select dashboard" list, the three "last used" dashboards are listed at the top and the others below ("other"). The sorting appears to be primarily alphabetical. However, I have individual dashboards that are always sorted in the wrong alphabetical position. They also remain in the wrong position when I rename them. See screenshots.
That is strange. What could be the reason for this?

Not a bug, but a bit of a nuisance:

I create a route or record a track. This is saved in folder xy and automatically receives the style of the folder. So far so good.

If I want to change the line style of a track later (and don't want to keep the style of the folder), all style properties are first reset to the default style (line red). Only width is retained.
Everything else (patterns, colouring mode, outline) is reset.

If I only want to change a single property, e.g. the type of patterns, I still have to set again everything else.

It would be better if all line properties of the track to be changed were retained in the menu so that I can only change the desired detail.
Maybe optionally with a button "set default style", if someone prefers that.

Screenshot 1: Style of the folder
Screenshot 2: Edit dialogue
Screenshot 3: Use style of the folder deactivated. All properties are reset (except width)

[only]

Hi, I have just discovered this forum section on Tasker. 

I recently installed Tasker for the first time and have already created some useful profiles. So far I have only created a profile for Locus that automatically activates GPS when Locus is running in the foreground. It works fine.

What I would like to have: I have a recording profile "Running" that I have always used for jogging. When I'm jogging, I always switch on flight mode so that I'm not disturbed when I'm out and about. Of course, I forget to do this from time to time and then an incoming message or call annoys me in the middle of the run.

Is there any way to get Tasker to automatically activate flight mode when the recording is started in the Running profile (and only in the Running profile)?

I think I read somewhere on the web that someone has set this up, but I can no longer find the page. ChatGPT has given me instructions, which are unfortunately not useful.

I am an absolute beginner with tasker and am still finding it quite difficult.

Translated with www.DeepL.com/Translator (free version)

I have a default value for the altitude threshold of 3 (I'm quite sure I set this myself in the past). Now I would like to change it permanently to 5, but I don't know how.

After the last update (4.24) and the new features for LoPoints, I tried a few things.

The captions for LoPoints photos can neither be edited after uploading nor added later. In the field, I usually don't have the time or inclination to write a caption, or I make a mistake and want to correct it later. Unfortunately this is not possible, or am I missing something?

[EDIT:]

After I recently had to reinstall Locus, I realised that my audio coaches and quick new points were not included in the backup and I had to create them all again.

I only have a few audio coaches, so that was done quickly. But I have a lot of quick new points for various use cases, so it was a bit of a pain to create them all again.

EDIT: I have just seen in the backup settings that Audio Coach and Quick new points should be included in the backup. The option "Settings" was definitely activated and everything was activated when the backup was imported. However, my audio coaches and quick new points were not there afterwards (all other settings have been restored correctly).

Perhaps there is a problem with the backup function?

I have a request for improvement when creating a new route in the route planner:

I am planning a route. Then, for example, there is a small bridge over a stream that is missing from the OSM map. The route planner doesn't want to take me along it. No problem, I create this section of the route "manually" in drawing mode. Or I want to take a shortcut somewhere cross-country. Here, too, I can insert a manual segment. Wonderful.

But: Whenever I recalculate the entire route ("recalculate all"), the manually drawn segments are ignored and the route is routed via existing paths, which ruins my planning.  See screenshot.

Would it be possible for manually drawn segments to be regarded as "unchangeable" during the recalculation and thus be retained? That would be great!

(If the manual segment cannot be reached in another profile (Car instead of Hike etc.), the orange error message "Routing service can't find the start point..." may appear. Just like when recalculating in car mode if shaping points are on hiking trails.)

[EDIT:]

Since I sometimes have problems with the ETA during (track)navigation in the current version (unrealistic, sometimes nonsensical times are displayed from time to time, usually much too short), I took a look at the planned routes as a gpx file:

The LoRouter generates timestamps when creating a route. Unfortunately, this is now also the case if you create a route without navigation commands. It is completely unclear to me what the purpose of timestamps is for a planned route. Logically, they make sense for a recorded track, but for a planned route?

Are they needed for the navigation commands and if so, why? The time is irrelevant, and they would be unnecessary for a planned route without navigation commands.

Just to calculate a fictitious route time in the planned route? Which is also too short by default (5 km/h or even more is always assumed for "walking", which is definitely too fast). 

No other route planner generates time stamps. Not GraphHopper, not BRouter Web, not openrouteservice.org and not even the Locus web planner. And you can navigate with their tracks without any problems.

If someone can explain this to me briefly and clearly (unfortunately I am not a geoinformatics specialist), I would be grateful. I couldn't find anything useful on the Internet.

It would also be interesting to know how the ETA is calculated during track navigation. All you really need is the current speed, the length of the remaining distance and (if available) the gradients. As I said, the values are sometimes given in an absurdly short form and are therefore not reliable.


EDIT: I just found my posts (in german) in this 3 year old thread. There were already problems back then.
 

Small issue with the navigation commands switches on/off:

I open the route planner and choose p.e. hiking or walking mode. I select "include navigation commands" on. (Important: the last time I planned a route, it was off).
However, the route is initially created without navigation commands. Only "recalculte all" creates navigation commands.
Then I create another route and select "include navigation commands" off. However, the route is created with navigation commands, only "recalculte all" deletes them.

This means that the route planner remembers the last setting, which is not changed simply by ticking "include navigation commands", you first have to recalculate.

LM 4.20.1 Afa

Translated with www.DeepL.com/Translator (free version)