Topics

I'd already posted this on the helpdesk, but posts like that tend to get lost in the mix there, or perhaps there aren't that many beer drinkers there. 

If it's not too much trouble, it would be great if beer gardens could also be displayed as LoPoints (armenity=biergarten). I think they're just as important for outdoor activities as bars or cafés, which are also LoPoints. Besides, you'd expect that from a Czech app  ...   

Cheers!

First of all: this isn't a new issue, and this isn't meant to be a bug report. Just a question to clarify something.

Yesterday, I used Locus for the first time in ages whilst cycling. I'd enabled track recording and map rotation so that the map would face in the direction of travel. It works fine as long as you don't stop. But when I do stop, the map ALWAYS rotates by 180°, so it's pointing exactly in the direction I came from. 

I've tried various settings, including the automatic GPS/hardware compass switch. In that case, the map still rotates by exactly 180° when I stop; only after several seconds does it respond to the compass and align itself more or less correctly. I've tried different speeds as the threshold for the switch, but always get the same result: First a rotation against the last direction of travel, then alignment with the compass after a few seconds. A bit odd.

I'd understand if the map rotated randomly, but it's odd that it always rotates exactly 180°. Is there a reason for this 180° rotation? Can it be turned off? Of course, it would be nice if the map continued to face 'straight ahead' even when I stop.

Today, I wanted to add photos as attachments to several points. Once again, I noticed that this is quite cumbersome and requires a lot of clicks:

1. I create a point.

2. I open it, select edit and then attach file.

3. I select "Select photo" . (BTW: Now it depends: if I select a photo directly from the system gallery, a copy of the photo is created under menion.android.locus/data/media/photo. However, if I select the photo from my gallery app, a link to the photo's storage location is set, e.g. ... /DCIM.)

4. Now I have to choose whether the photo should be used as an icon.

5. Now I want to add a description. To do this, I have to click on the pencil icon on the photo. The text input field opens. However, I cannot write my text straight away, but have to click on the pencil icon to the right of it again. (Why??)

6. Now I write the description and click on the tick.

7. Now I have to save it, but the save button is hidden by the text input field.

8. I first have to swipe away the text input field before I can finally save it.

This should be much easier:

When I select a photo, the text input field could appear directly below it, where I can write directly if necessary or leave it blank. The save button could be there immediately so that I can save the photo straight away, regardless of whether I enter a description or not.
Similarly, the selection field (photo as icon or not) could be displayed in the same dialogue box and retain the last selected status permanently until I change it.

Everything in one dialogue box would save a lot of clicks.

Is there any chance that the Track Gallery will be introduced in the foreseeable future? It was available in a beta version last summer, but despite very positive feedback, it was not included in the release versions.  All fotos taken during recording were listed for all recorded tracks, regardless of where they were stored on the device. 

I therefore still use beta 4.30.1.8 on my main device, as I don't want to miss out on the Track Gallery. It has so many advantages!

The Track Gallery was discussed here ff.:
https://forum.locusmap.eu/index.php?msg=79301

The reason why it was ultimately not retained was explained here:
https://forum.locusmap.eu/index.php?msg=79590

"... it will collide with the planned 'Sync of attachments'. So they should come, but later in a slightly different style." Is there a schedule? I probably can't use an old beta forever...

Or would it be helpful to post this as an idea/question in the helpdesk?

I have had this problem several times in recent months on different devices. After importing a complete backup (everything checked), the quick points are initially missing. I then have to reinstall the backup and select only the settings, and only then are the quick points transferred. But unfortunately, this is faulty: the folder assignments are then all incorrect. I have to redo them for each individual quick point. Since I have quite a lot of them, this is annoying.

[here in the helpdesk]

I don't need a GIS tool, but sometimes it's useful to be able to draw and save an area (polygon). This can also be easily done with Locus Map by creating a track around the desired area with the route planner and activating "Close line and fill area with colour" under line style. See screenshot. Sufficient for my purposes.

Unfortunately, the track information panel still displays the information about the track (track distance, elevation chart, etc.), which is pointless in this case. Not even the area that I can display in the route planner, at least while I'm setting up, can be displayed permanently in the track info panel. I would at least consider this to be very desirable. I have to click several times each time to calculate the area using the tool function, which is then only displayed for that moment. As a workaround, I write this manually in the track name, but this is not an ideal solution.

I would like to take this opportunity to ask whether there are plans to make the track info panel configurable at some point. I have already posted this here in the helpdesk as an idea and I am quite surprised that there was hardly any response. I can't imagine that this wouldn't be useful for other users.

There is a problem with the round info arrow pointing to a found LoPoint when moving the map screen.

Easy to reproduce:

Search with the global search any location. City, restaurant, mountain, it doesn't matter.

Select the location from the results list. The map jumps there and the LoPoint icon is displayed (white with a blue border). The info panel for the point also appears at the bottom of the screen. See screenshot 1.

Move this down so that it disappears. The LoPoint icon remains. Correct.

Now move the map until the LoPoint is outside. A round indicator with an arrow and distance to the LoPoint appears at the edge of the screen. Correct. See screenshot 2.

Move the map back to the LoPoint. I would now like to remove the LoPoint icon. I select "clear map screen" and confirm. The LoPoint icon disappears. Perfect.

But: when I now move the map, this round information marker with arrow and distance to the removed LoPoint continues to appear permanently. It is not possible to get rid of it, except by closing and restarting Locus. Somehow the search result seems to remain in the cache.

In the case of points, the point label can be displayed when you touch the point with the cursor (on hover).

However, the track label can only be displayed permanently (simple or complex) or not at all. On hover would be nice here too.

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?