Messages

There are problems with the "navigate to" function in the current beta 4.22.2.1

Mode "walk" or "hike", "Include navigation commands" off. (Which, as you know, I prefer and have therefore mostly deactivated).

I select a destination (point, POI, screen centre). Then I click "navigate to". The route is calculated and displayed on the map. I click on the navigation icon in the top bar. The navigation starts. "Time to target"/ETA is reasonably plausible.

But: There are no navigation instructions! The Next turn panel only shows the destination and the distance to it. "Itenrary" is emty, only lists the target.

Now I click on "Recalculate". Navigation instructions are now created. In addition, a time to target of approx. 6 or 7 minutes is displayed, which is absurd.
But: Only the first few instructions for a small section at the start of the entire route are calculated. After that, the display in the Next turn panel jumps directly to the target. "Itenrary" also only lists these first few instructions, the last instruction shows the remaining long distance to the destination.

See screenshots 1 - 4

This is absolutely reproducible for targets from a distance of approx. 1 km or more. Regardless of whether the destination is 1, 5 or 20 km away, initially no navigation commands are created at all, after the manual recalculation a time to target of approx. 6 minutes is always specified and only the first few instructions are created.

If I then start walking anyway, the absurdly short time to target of approx. 6 minutes is initially counted down as normal. At some point, at around 3 minutes, Lokus "realises" that there is not nearly enough time for the remaining distance and slows down the countdown drastically. Every 5 - 10 real seconds, the time to target is reduced by one second, or it stops/freezes completely.

This was never the case before. Not even in the current stable version 4.22.2. Navigation commands are always generated for the entire route, even if the "Include navigation commands" option is deactivated. Anything else would make no sense.

In addition, the beta version crashes from time to time, but I have not yet been able to find a reproducible reason.

Gesendet von meinem SM-G973F mit Tapatalk

You're right, freischneider.

I also correct on OSM. But many things are mapped correctly and you still want to walk differently. For example, crossing a road, even if there is no "official" pedestrian crossing. Or going off road.

Because of the lack of navigation instructions for manual segments: This is another reason why I prefer to create my routes without navigation instructions.
Track navigation then generates very reliable and precise navigation instructions based on the track geometry. Therefore, instructions are also given for manual segments, there is no difference for the geometry.

Only the complete recalculation of the route destroys the manual segments.

Gesendet von meinem SM-G973F mit Tapatalk

But I noticed adding an attachment (jpg file) to a point doesn't work.

I can't confirm this. No problems when adding a photo to a point. Works as always.

Thx - "Completely new image gallery" - where?

I think it's about attached photos for points. Previously, they were displayed large when clicked, but not fullscreen. But in the new beta.

Another issue: In the new beta, the LoRouter profiles are displayed mixed up, mostly in English and partly in German. (Language setting German). Previously they were all in German.
See screenshot.

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.)

@Menion: Thank you very much, that sounds good. Then I hope that when I change the device and insert the old SD card, all photo attachments will be displayed in the points again. I'm not planning to do this at the moment, but it will probably have to be done in a year or two at the latest.

In the past, I have had problems a few times after reinstalling Locus and importing the backup (photos in my points were no longer displayed), but I can't remember whether I had changed anything in the directory structure. 

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

@col: Include photos/videos in auto backup is not a good solution. The backup file would quickly become gigantic.

If you store your attached photos/videos exclusively in the Locus subfolders "photos" and "video", you can back them up yourself and copy them back again. See Menion's answer.

However, if you select photos as attachments that are stored somewhere on the device or the sd card, a link is created. I always do this because I have saved my photos in a well-organised folder structure of my own. These photos are then stored in the points as a link.

Unfortunately, this is almost impossible to save and I dread the day when I need a new smartphone and have to link all the photos again individually. But I also don't want to copy all the attached photos to the Locus subfolder "photos".
Unfortunately, I can't think of a simple solution. As long as I use the old sd card in a new/different smartphone, I hope that the links are still correct and the photos are still displayed. I don't know whether this will work reliably. But that's my problem.

@0709: I sent you a message.



Gesendet von meinem SM-G973F mit Tapatalk

... The main reason was to display the time-based chart for planned routes. ...

Generally, is there any problem with timestamps stored within the trackpoints?

ETA during navigation ... I know it is not perfect and I really do not want to explain (again) full complex logic
behind this now. Anyway, it is not as easy as "distance / average speed". Computed time currently considers routing profile, surface, elevation etc. What should be improved, is automatic updating of this time by user performance during the ride. At least this. ...

Time-based chart: I understand, but as I said, this is not very helpful if the time is always given too low. 5 km/h is too fast. And when I plan a route up a steep hill, the time is usually given as about 20% less than I actually need. I have compared it with many of the tracks I have recorded and I am not particularly slow. The basic speed used should be lower (4.2 - 4.5 km/h when walking) or, even better, individually adjustable.

ETA during navigation: sorry and thanks for your patience. At least you agree that there is room for improvement here.
We mainly hike and walk in flat or slightly hilly areas without difficult terrain, so a simple time/distance calculation would be sufficient. (Perhaps this could be set as an option in the settings.)
Unfortunately, the remaining time for track navigation is often unreliable and then usually much too short. It would therefore be really nice if user performance could be better taken into account when travelling in future.

Gesendet von meinem SM-G973F mit Tapatalk

Thank you Menion. I agree, "navigate to" and "plan route to" should remain separate as it is.

"Quick navigation button" would be nice.

Timer/countdown: I'm not convinced. I want to navigate immediately (quick button is enough and ideal) or modificate the computed route without "time pressure" - don't want to start unintentionally because I was distracred or too slow when checking the route. 

Quick save button at the top: that already exists (?).

Gesendet von meinem SM-G973F mit Tapatalk

I confirm that the opening of the white list is not fluid, first a small part of the list appears, then with a minimal but visible delay (approx. 200 ms) the rest.

Second issue: Confirmed. I case of only two items deleting the destination reduces the list and only the start entry is visible. However, you can select a new destination on the map and the list will open correctly again. But sometimes the truncated list covers the blue buttons (+ and -) and then you have to restart the route planner.

If you set several points and delete the last one, the list is correctly reduced by one entry. Only the penultimate (second) entry has the problem.

[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.
 

You can still do this. Simply start the route planner directly instead of "Navigate to", then you can select the starting point on the map.

Ok, there is still room for improvement. As Menion wrote here:

"Of course, work on the planner is not yet finished ..."

But I would be more in favour of three options, as I also find the previous option 1 sensible:

1. Navigate directly to (last settings for mode etc. are used) - then the navigation starts immediately
2. Navigate to (as it currently works)
3. Plan route to

For me, this is duplicate and makes no sense. If I want a different start, I can simply change the entered location.

Ok I understand. Maybe you're right.

However, it is then somewhat more complicated to set the start when the GPS is off or there is no signal.

I therefore find the selection option (plan route to / navigate to) somewhat better.

But that's a matter of opinion and taste.

Gesendet von meinem SM-G973F mit Tapatalk