Messages

It´s already a SVG version, but as far I remember, there was a small bug in Locus, that growed up all symbols in the past more than today. This bug is solved since a few versions, so that the base size of the  SVGs is now too small.
For that, all symbols (base size) have to be revised.

Sorry, I had not checked if the theme is already using SVGs. So it's not a problem of screen density, but rather a newer version of Locus. This makes sense, because there was only Android 2.3 available for my old phone, which restricted the Locus version to 3.5 or so. So when starting to use the new phone, I essentially had a "new" screen density, as well as a new Locus version in use.

Can you please make a screenshot, comparing my last screenshot in first post? Please sarch for "Zinnowitz" (Usedom). Zoom 15. Than I can imagine how it looks for you.

Sure! btw: I actually know the island of Usedom from some vacation trips :-)



Please don't mind the Strava overlay (green speckles) visible in some parts of the image, I had forgotten to disable it befor taking the screenshot.

I´m "always" working on my private theme version but still today it´s not good enough.  Perhaps one day I can offer an update.

Yeah, I know this situation, it's the same with my Brouter Mountainbike Routing Profile.

Hi,

thanks for this great theme! I use it all the time when mountainbiking, because it's the only theme I found which shows the paths and tracks in reasonable thickness to be recognized on the screen when the phone is mounted to the handlebar! Also, the mtb:scale - coloring is very helpful!

However, I recently switched from my old Motorola Milestone II (265 ppi) to a Sony Z1 Compact (342 ppi) smartphone. The ways are still visible very good with this theme, but the symbols are very tiny!
Of course, there is an option in Locus to scale the symbols, but this also scales the personal POI's symbols, which are already big enough for me.

So the question is: are there plans to make a version of this theme for higher screen densities? Maybe a SVG version? Would a SVG-version automatically scale the symbols to the "right" size?

greets,
zossebart

I too was never successfull with correct direction showing on the bike handlebar. With my Sony Z1 compact I experience 3 different scenarios:

1. phone simply mounted on the handlebar: compass seems to work reasonable.
2. phone mounted and magnetic charging adapter attached to the phone (I use it in order to keep the phone waterproof because no flaps have to be opened): compass direction only moves slowly, not useable.
3. phone mounted and charging over the magnetic adapter ongoing (switched on external battery pack): compass shows wrong direction, not useable.

I guess there is nothing Locus can do about it (other than using gps based orientation) 

Eigentlich will man ja auch mehr als nur Richtungsaenderungen, man will ja auch Oberflächen ( "in 100m links ab auf den Splittweg")
Und da könnt Ihr mir aber helfen, mir da auf die Sprünge zu helfen, welche Standards/Protokolle/Konventionen es schon gibt und was funktioniert und was nicht.

Leider habe ich da auch keine Ahnung 
Heißt das, dass hier jede Karten-App ihr eigenes Süppchen kocht? D.h., hast du momentan für Locus, OSMAnd und Orux jeweils die Daten-Übergabe anders implementiert?
Wie funktioniert das denn z.b., wenn MapQuest als (online) Router verwendet wird? Ich hätte gedacht, dass es da irgendeinen Standard gibt.

Ich persönlich bräuchte auf dem MTB auch nur die einfachsten Anweisungen wie links/rechts und vielleicht noch Gefahrenstelle (z.B. Bahnübergang), da es hoffentlich in Zukunft in Locus die Möglichkeit geben wird, sich das über Beeps signalisieren zu lassen. Aber das ist ja dann Sache der Navi-App, wie es die Hinweise an den User signalisiert...

Hallo!

Ich nutze Locus und Brouter für MTB-Touren (bastel dazu auch an einem Profil).
Das funktioniert schon ganz gut mit dem Locus-Algorithmus zum Instructions generieren. Das ist sicher auch ganz hilfreich bei heruntergeladenen Tracks, die keine Anweisungen enthalten.
Viel besser wäre aber natürlich, wenn BRouter korrekte Abbiegehinweise direkt auf dem Phone generieren würde. Dann gäbe es die Anweisungen (voice hints) wirklich nur an den wichtigen Stellen (z.B. Kreuzungen) und nicht auch bei Kurven usw.
Das wäre erstens weniger verwirrend und würde zweitens auch Akku sparen, weil das Display nicht unnötig aktiviert wird. Klar kann man die Anzahl der von Locus generierten Anweisungen auf low stellen, aber da fehlen mir dann manchmal wieder welche, ich finde das eigentlich nur auf medium einigermaßen nutzbar.
In gewissem Sinne ist der MTB-Einsatz schon ähnlich dem Auto-Navi, obwohl man sich häufig im Wald bewegt. Wir brauchen an Wegkreuzungen präzise Anweisungen über den weiteren Weg, sonst soll sich das "Navi" ruhig verhalten (bedeutet einfach weiter dem Weg folgen).
Ich persönlich würde mich deshalb sehr über eine Implementierung von "voice hints" in Brouter freuen.
Vielleicht wäre diese Diskussion aber besser in der Brouter Google Group aufgehoben?

Gruß,
zossebart

Ah! thanks for the fast answer! It works as aspected now!

Thanks again for this very nice and helpful app!

Hi,

is there a way to restrict the public intents to Locus Pro (excluding Locus Free/Testing)?

I use the public intent "locus.api.andoid.ACTION_TRACK_RECORD_START" to start track recording from tasker when my phone is attached to the bike handlebar (triggered by NFC).
Unfortunately, the intend starts track recording in Locus Pro, as well as in Locus Free at the same time (I keep Locus Free installed in order to get the testing versions).
Is there a way to only trigger Locus Pro with the intent?
I am aware that Locus is able to directly start track recording by NFC, but I have some other tasks attached to the event (mounting of the phone on the handlebar) (e.g. enable silent mode of the phone), for which I need tasker.

Thanks,
zossebart

Bei unübersichtlichen Kreuzungen mit mehreren Abzweigungen (kommt bei uns öfter an größeren Wegkreuzungen im Wald vor) haben mir die Abbiegepfeile direkt auf dem Navi-Track schon öfters geholfen, da die reine Navi-Anweisung (z.B. biege links ab) da nicht immer ganz eindeutig ist. Natürlich sieht man diese Information theoretisch auch am Track selbst (der sich ja normalerweise recht deutlich von der restlichen Karte abhebt), aber mit den Pfeilen ist es meiner Meinung nach noch eindeutiger und schneller zu erfassen.

Zur Info: ich nutze die Navi-Funktion hauptsächlich auf dem Mountainbike (auch im Gelände). Da ich dort aber mit geringerer Geschwindigkeit als z.B. mit einem Motorrad unterwegs bin, nutze ich eher größere Zoomlevel.

Ich kann mir aber vorstellen, dass die Pfeile in deinem Anwendungsfall bei kleineren Zoomleveln eher zu Verwirrung führen. Vielleicht sollten diese je nach Zoomlevel automatisch ein- bzw. ausblendbar gemacht werden?

I would also like to thank you for introducing myTourBook to us! Great application for analyzing the Tracks recorded by Locus on the big screen!

Hi,
I played around a little bit with the new functionality in "route & measure" in the testing version 2.17.4.3. This works great! With the automatic recalculations we have a very handy tool for route creation now!
Deleting a point in the middle of the route is great, but even better is the ability to add an additional point between two existing points with the little red dots! Thank you very much for this feature! I hope we get the functionality in the "normal" version soon.

I also tried the new grouping function for POIs. Also very handy! Thanks!

i would also like to have this feature!
Maybe make the function of the waypoint-button in the recording panel switcheable between "normal POI" and "quick POI"?

Ich weiß nur nicht, ob es ggf noch Einstellungen in Locus oder gpsbabel gibt, die die irrelevanten Infos weglassen.

Ich hatte das Problem mit den ellenlangen Strings in JOSM auch schon. Hab dann rausgefunden, dass ich das vermeiden kann, wenn ich beim Exportieren nicht das Häckchen bei "Formatierte Beschreibung eingeben" setze. Damit erscheint dann auch in JOSM nur der tatsächliche Text.

Siehe auch hier: http://docs.locusmap.eu/doku.php/manual:export_dialog ("Export generated description").

Allerdings hab ich das nur beim Export als GPX mit Waypoints getestet. Ob das in deinem Fall auch funktioniert, weiß ich nicht.

Thanks menion! Updated the map from store and now it works!

hmm you see it only a green? not colorized? I saw this also on one of my devices, but I leaved. Hmm time to check it.

Exactly, it's all green. How is this intended to work? Is this some special map with integrated theme? Otherwise, the coloring would be according to the currently selected theme, right?
I see the green map on my Motorola Milestone 2 (Android 2.3) as well as on an androvm (Android 4.1).

And about colorizing ... I'll think about it. It's not so hard to do it, but problem is, that if I set for example elevation "0" to fully green, 2000 to fully brown and since 4000 fully white, then when you zoom in during some hike, then you'll for almost all time see just one color, because change of elevation during one trip will be quite low compare to needed change to change color (not sure if what I wrote make sense in my English, hope yes)

Yes, it makes sense to me. That's a good point. You would see the gradient in low zoomlevels only (which should already be possible with your world map download (which doesn't work for me yet)).

So it needs to check how other more robust applications do this. I'm sure it will be some combination of current elevation and also gradient, maybe some shading. I'll add this to my to-do list on long winter nights

Yes, this would require a somewhat "intelligent" algorithm which adepts to the currently visible area on the screen. Thanks for considering this! But only if you are really bored during this long winter nights ;-)

Ok, thanks for the reply (on a sunday!).

Zooming out shows sort of a world map, but it's not so nice looking as in the picture. But never mind, I understand that here are other priorities in the development of this great app than color gradients on hills.