Messages

Sorry to bring this up again here. Menion had correctly moved it to this thread:
https://forum.locusmap.eu/index.php?topic=8378.0
But it is simply not addressed there. I would therefore like to remind you of this again here.
I would be very happy if this option were integrated into the web planner. Thank you.

Die Erklärung is einfach. Der Weg, der von der Max-von-Eyth-Straße zum Friedhof führt, ist laut OSM ein Pfad und nicht für Autos erlaubt. Der Router kann dich also nur zum nächstgelegenen für Autos erreichbaren Punkt (nördlich oder südlich des Friedhofs) führen.

Setzt du dein Ziel auf den Friedhof oder dessen Eingang, dann liegt der nächste erreichbare Punkt auf der  Autobahn und der Router führt dich dorthin. Setzt du ihn soweit auf den Pfad, dass die Max-von-Eyth-Straße näher liegt, führt dich der der Router auf diese Straße.

Wenn du einen Zielpunkt per Klick in die Karte setzt und dieser mit dem gewählten Modus (Rad, Auto, zu Fuß usw) nicht erreichbar ist, wird dich jeder Router zum nächstgelegenen Punkt auf einem Weg/einer Straße führen, der so erreichbar ist. Auch zu Fuß kannst du dich nicht mitten auf eine Wiese routen lassen, wenn dort kein Weg ist.

Eine Möglichkeit ist: Statt Kick in die Karte den entsprechenden POI als Ziel wählen oder die Adresse des Friedhofs als Ziel wählen.

In deinem Fall reicht es, die Benutzung von Autobahnen beim Routing abzuwählen. Das kannst du auch in Locus machen:
Planungsmodus, dort z. B. Auto/schnell wählen, im Menü das Zahhnradsymbol anklicken und dort "Autobahnen vermeiden" aktivieren. Siehe screenshots:

Bei Abweichung von der Route gibt es die automatische Neuberechnung. Problem ist wenn du noch nicht am Abweichenden Ziel angelangt bist, dann führt es dich immer wieder zurück zur Route. Das ist nervig. Bei sehr kurzen Abweichungen ist das ok. Aber ich glaube du kannst es auch manuell aktivieren.

Das ist kein Problem, du kannst in den Einstellungen unter "Navigation" genau einstellen, ob du eine Routenneuberechnung haben willst und wenn ja, ob mit Endpunkt- oder Streckenpriorität. Bei letzter kannst du sogar die Abweichung angegeben, ab der neu berechnet werden soll.
Und in den erweiterten Einstellungen gibt es noch mehr Optionen dazu.

@brandkannen: wenn du nur zu einem Zielpunkt hin navigieren willst, brauchst du gar keine Route zu erstellen, sondern kannst dich direkt dahin navigieren lassen. Das wird dann bei Neuberechnungen stets mit Endpunkt-Priorität gemacht.

Ziel in der Karte anklicken (oder die Cursorposition als Ziel nehmen) , Navi-Icon anklicken, Modus auswählen (Gehen, wandern, Rad usw.), bestätigen und los geht's. GPS muss natürlich eingeschaltet sein. 🙂

Die AFA Versionen stellt Menion auf Google Drive bereit. Die Links findest du unter seinem Profil.

Wenn du mit der vorgegebenen Verzeichnisstruktur leben kannst und zurecht kommst, brauchst du die AFA Version nicht.

AFA = all file access

Mit der AFA Version kann Locus auf alle Ordner/Verzeichnisse zugreifen. Deine Karten, Fotos, srtm- und sonstigen Dateien müssen also nicht zwingend in den von Android zugelassenen/zugewiesenen Verzeichnissen gespeichert werden.

I just installed LM 4.18.2 and tested sharing POIs from the Google Maps app to Locus. Should be improved in this version.

Now a search list is displayed in Locus, which is mostly unhelpful.

Example: I click on a public toilet in Google Maps and share it with Locus. There, I am now shown a list with countless public toilets instead of the shared one.

Another example: I share the Kleistdenkmal (monument of Kleist) in Berlin, nearby Wannsee. Locus now shows in the list only the Kleistdenkmal in Saxony, 167 km away from the shared monument...

If I long click on the POI and then share it, it shows up correctly on the map in Locus.

I can confirm this.
However, if you use Google Maps in the browser, it works.

Sorry for the objection, but your problem is not one. If Youtube shows you advertising, it has nothing to do with Locus.
And you don't have to click on the link. I have never even noticed the video, although I have often downloaded articles from the Locus store.

Inzwischen habe ich mich mal genauer mit den Presets befasst und ja, hier scheinen diese tatsächlich hilfreich zu sein. Die Möglichkeiten waren mir in der umfassenden Form bisher nicht bekannt.

Habe eins für OAM angelegt mit dem passend eingestellten Elevate Theme und ein zweites für LoMaps mit dem gewünschten internen Theme. Damit ist der schnelle Kartenwechsel inkl. Thenenwechsel möglich. Mal sehen, ob sich das so im Alltag bewährt.

Danke für eure Anregung diesbzgl.!

@ Gerhard: For me, the number of points was also not correct at first. After I have switched off all (with the new brush icon) and then have shown again several points, the number is now correct for me.

For me, the new solution is fine so far. The "brush" icon is clear enough.

Temporarily hidden tracks or points can always be recognised by the red icon at the top right of the map and can be shown there.

Very interesting! I came across this discussion by chance only a week ago.

I myself had noticed only a few weeks ago that Locus suddenly caused very high battery consumption, always when navigation and/or track recording was running. On day trips, a power bank had to be connected after only 3-4 hours.

Now we were hiking in the Liberec area (Czech Republic) for about 2 weeks. Very beautiful area by the way! Every day with track navigation along planned routes and track recording. Strangely enough, there were days when the battery lasted through the day without any problems, but on other days it was already empty after a few hours.

After reading this discussion I remembered that in March I had downloaded the 1" files of the elevation data (24.7 MB each) for the whole of Germany from Sonny, which coincides with the beginning of the high battery consumption.

These were not available for the Czech Republic, where I still have the small 3" files (2.7 MB). 

Now the region west of Liberec is still covered by the Sonny file N50E14.hgt, while those from the city and further east are covered by the 3" file N50E15.hgt. And indeed, it was the tours in the west (Ještěd Mountains, etc.) where the battery consumption was extremely high. In the eastern Jizera Mountains, the battery lasted the whole day.

I would never have thought that this could be the cause without these posts on the forum. I then replaced all the 1" files with the small 3" files and the battery consumption was normal again. Even with another hike in the N50E14 range. 😊


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

...
What does this value do? It specifies a minimal change in the altitude when computing elevation up/down sums.
...

I find this new feature quite interesting. Whereas "minimal change in the altitude" is relative - moving the slider by a few metres can result in significant differences in elevation up/down sums.

I have tried a lower value (3 m) for tracks in flatter terrain and a higher value (5 m or more) in mountainous terrain - but in the end the function shows well how difficult the calculation of realistic elevation gain/loss is. Good solution to put the function in the Expert Settings. Thanks for the update!

Hello Menion,

once again on this topic. I had some time to look into it over the weekend and found some inconsistencies and, in my opinion, a bug.

First of all, thanks for the update 4.15.2 (impoved computation of uphill/downhill distance) - this is more realistic now.

I am still not completely happy with the new calculation of the elevations. In my opinion, ignoring elevation differences of up to 5 metres is too strict. In relatively flat regions such as Berlin and the surrounding area, too many actually existing inclines and declines are calculated out, and the result is then not very realistic. If I go on a cycling or jogging tour and have several short but distinctive inclines, which clearly require effort when running and can also be seen in the altitude graph, and the result then shows 0 metres of altitude, this is not ideal. 

In addition, there are sometimes strange results that make no sense from a purely mathematical point of view: A recorded track shows "Min altitude" 30 m, "Max. altitude" 66 m (a difference of 36 m), but only 30 m elevation gain is displayed. (Screenshot 1 and 2.) So 6 metres of altitude are "swallowed".

Then I noticed a faulty behaviour in the Track Analyzer, which might be a bug. A track section selected with the analyzer always shows exactly the same value for elevation gain and loss, even if it only goes uphill or downhill (screenshot 3 and 4). This can be reproduced everywhere.

With the latest update to 4.13.2, the manual backup works again. And without rd5 files.
Thank you and Merry Christmas!