Messages

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.

we already have this done if you download from locus store world vector map and zoom to level 1-5, then areas will be colored by defined range of color. But I'm not sure if this is useful also for common maps.

I tried that, but the downloaded map didn't work. There is no additional map under VectorMaps. If I try to add the map manually, I find the downloaded _world.zip, but when selecting it, there is an error popup saying "there is a problem with _world.zip"

As I think about it, much better should be some coloring by altitude change (gradient), then by altitude value itself

This also sounds interesting! Do you plan to implement it?

Hi,

I hope I can reuse this thread. If not, please split it into a new one.

The hillshade-rendering with offline srtm-data works very well for me. Thanks for implementing it!

Would it also be possible to implement something similar to OpenCycleMap, which has hillshading as well as "height coloring" (don't know the right word for it). I mean the tinting of the terrain depending on it's height.

For example http://www.openstreetmap.org/#map=11/43.1413/-4.7403&layers=C.
The color of the tips of the mountains is almost white, while lower regions are brown/green. Would something similar be possible in locus? That would be so nice! :-)

Thanks,
zossebart 

In der Zwischenzeit werd ich mal an einem Brouter-Profil basteln, welches besser meinen Anforderungen entspricht...

Kann ich gerne machen. Wäre das im Locus-Forum ok, obwohl es sich ja um was Brouter-spezifisches handelt?

Wir hätten hier nichts dagegen, aber gegenüber Arndt, dem Entwickler von brouter wäre es fair wenn Du es hier reinstellen und erklären würdest:
https://groups.google.com/forum/#!forum/osm-android-bikerouting

Genau deshalb meine Frage, ob das hier überhaupt rein passt. Ich würde das bei Google Groups reinstellen und hier verlinken. Ich weiß aber auch noch nicht wann ich mal so richtig dazu komme. Aber bis zum Frühjahr wird sich schon mal Zeit dafür finden...

Meine Vorlieben für die Routenberechnung wären:
- Vermeidung von Hauptverkehrsstraßen, bevorzugte Nutzung von Wald/Feldwegen (auch wenn das einen Umweg bedeuten würde, ich will in die Natur!)
- wenn Routing durch Städte/Dörfer nötig, Bevorzugung von highway=residential o.ä.
- keine Nutzung von CycleRouten, da diese oft auch auf Hauptverkehrsstraßen verlaufen

Bisher passt da noch kein Standard-Profil so richtig. Die Trekking-Profile routen mir alle noch zu sehr über Straßen. Das shortest-Profil kommt meinem Geschmack oftmals noch am nächsten, aber das kann auch daran liegen, dass es in meiner Gegend viele Wald/Feldwege gibt und der kürzeste Weg deshalb oft über solche führt.

Ich denke Brouter bietet da mit seinen editierbaren Profilen genug Möglichkeiten, um das Ergebnis zu tunen.

Prima, sehe ich ganz genauso und sowas hätte ich demgemäß auch gerne.

Hast du schonmal in die Richtung was gemacht/probiert? Ich hatte nur mal kurz ein bissel rumgebastelt, aber ohne das gewünschte Ergebnis...

Das Guiding führt Dich auf den Dir momentan nächsten Punkt auf der Originalstrecke zurück. Nächster Punkt heisst, daß der Punkt noch nicht "verbraucht" wurde, ein Punkt wird nur einmal vom Locusnavigationsalgorithmus angefahren. Nächster Punkt heisst ebenfalls, daß es um die kürzeste Verbindung (Luftlinie!) zwischen Dir und der Strecke geht, fährst Du also parallel zur Originalstrecke, so zeigt das Guiding immer seitlich nach vorne.
Wenn Du Deinen Track mit mehreren Zwischenzielen (Locusfunktion "Route and Measure" geplant hast, so würde Dich nach meinem Verständnis das neu berechnete Routing direkt zu Deinem Endziel bringen, die ursprünglichen Zwischenziele also ignorieren da sie im Track nicht ausgezeichnet sondern nur normale Trkpoints sind (bin mir aber nicht sicher, da ich das noch nie ausprobiert habe). Das Guiding hingegen würde also zwischendurch durchaus mal auf Deine Zwischenziele zeigen.

Ok, ich verstehe. Unter der Berücksichtigung von Zwischenzielen muß man die Neuberechnung natürlich anders bewerten. Das von dir beschriebene Verhalten ist ja im Prinzip das, was ich jetzt auch schon mit Locus und Brouter habe, da ich momentan ja nur Guiding entlang der Route machen kann. Wenn ich da von der Route abweiche, zeigt er ja auch immer auf den nächstgelegenen Punkt auf der Original-Route. Das ist ja ganz ok, aber je weiter ich von der Route abweiche, desto schwieriger wird es für mich, auf der Karte einen geeigneten Weg (nicht Luftlinie) zurück zur Route (oder zum nächsten Ziel) zu finden. Am idealsten wäre also sogar Routen-Neuberechnung zum nächsten Zwischenziel. Ich verstehe aber, dass das momentan nicht vorgesehen ist, und vermutlich auch nicht so auf die Schnelle implementiert werden kann.
Ich würde deshalb darauf ausweichen, unterwegs jeweils von Zwischenziel zu Zwischenziel zu navigieren. D.h. zunächst nur Navigation zum 1. Zwischenziel mit automatischer Neuberechnung bei Abweichen von der Route. Am Zwischenziel angekommen würde ich dann eine neue Route zum nächsten Zwischenziel berechnen usw.. Dank offline-Routing ist das ja unterwegs kein Problem und sollte auch relativ flott gehen, wenn die Zwischenziele z.B. schon als POIs vorhanden sind. Allerdings hätte man dann vor der Tour keinen schönen Überblick über die Länge der Gesamtstrecke. Aber man kann nicht alles haben, die Möglichkeiten, die wir jetzt schon haben, sind ja auch schon super! Das ist also keinesfalls Kritik!

Übrigens wäre die Neuberechnung für mich der einzige Mehrwert der Navigation gegenüber dem Guiding. Sprachansagen und Richtungspfeile brauche ich nicht. Da ich mit Zusatzakku (und ab nächstem Jahr hoffentlich mit Nabendynamo) unterwegs bin, habe ich das Display immer an. Stöpsel im Ohr oder gar Ansagen über den Handy-Lautsprecher kann ich auf dem Rad überhaupt nicht leiden (schon gar nicht im Wald). Aber für viele ist das sicher eine schöne Sache und technisch gesehen auf jeden Fall interessant!

Was anderes: funktionieren aktuell eigentlich Alternativrouten mit Brouter und Locus? Also ich meine über die Navigations-Funktion, nicht über den manuellen Aufruf von Brouter. Ich wollte das mal probieren, indem ich mehrmals hintereinander eine Route mit exakt den gleichen Start- und Endpunkten berechnen lasse. Es kam aber immer die gleiche Strecke raus! Hat das schonmal jemand probiert?

@Arndt:
Auch von mir Danke für die Entwicklung von Brouter!
Ich teste schon seit ein paar Versionen immer mal, aber jetzt durch die Integration in Locus geht das natürlich noch komfortabler. Ich bin sehr gespannt wie die Entwicklung weiter geht...
Die Idee mit der "foolproof-App" find ich ok. Ich persönlich werde zwar weiter die "fullfeatured-Version" verwenden, aber ich hab auch Informatik studiert :-)

In der Zwischenzeit werd ich mal an einem Brouter-Profil basteln, welches besser meinen Anforderungen entspricht...

Da lass uns gerne teilhaben, bin auch daran interessiert.

Kann ich gerne machen. Wäre das im Locus-Forum ok, obwohl es sich ja um was Brouter-spezifisches handelt?

Meine Vorlieben für die Routenberechnung wären:
- Vermeidung von Hauptverkehrsstraßen, bevorzugte Nutzung von Wald/Feldwegen (auch wenn das einen Umweg bedeuten würde, ich will in die Natur!)
- wenn Routing durch Städte/Dörfer nötig, Bevorzugung von highway=residential o.ä.
- keine Nutzung von CycleRouten, da diese oft auch auf Hauptverkehrsstraßen verlaufen

Bisher passt da noch kein Standard-Profil so richtig. Die Trekking-Profile routen mir alle noch zu sehr über Straßen. Das shortest-Profil kommt meinem Geschmack oftmals noch am nächsten, aber das kann auch daran liegen, dass es in meiner Gegend viele Wald/Feldwege gibt und der kürzeste Weg deshalb oft über solche führt.

Ich denke Brouter bietet da mit seinen editierbaren Profilen genug Möglichkeiten, um das Ergebnis zu tunen.

Ich werde versuchen, das Profil am PC mit einer AndroVM anzupassen, auf dem Smartphone wird mir das auf Dauer zu umständlich. Die VM ist jetzt schonmal soweit vorbereitet mit installiertem Locus, Brouter und den Standard-Profilen.

Ich bin sehr gespannt, wie sich auf dem Gebiet alles weiter entwickeln wird. Ich denke Locus + Brouter könnte für mich die ideale Lösung werden, um schnell mal mit dem MTB loszufahren, ohne vorher am PC erst langwierig eine Route erstellen (und auf das Handy übertragen) zu müssen.

Ich war früher nie der große Tourenplaner. Erst durch Locus getrieben mache ich jetzt so Zeugs überhaupt. Und am PC habe ich noch nie eine Route erstellt

Ich habe bei meinen Ausflügen immer gerne ein Ziel (meistens ein Geocache, den ich machen will, oder eine Sehenswürdigkeit). Ich fahre selten einfach so ins Blaue drauf los. Deshalb plane ich oft eine Strecke im Vorraus, um zu meinem Ziel zu kommen. Unterwegs bietet sich dann aber öfters ein anderer Weg an, der von der Landschaft her schöner ist, oder bei einem Multi-Cache muss ich über eine Station gehen, die nicht auf der Route liegt, deshalb wären Neuberechnungen praktisch.

Da ich aber auch öfters von der Route abweiche (im Frühjahr sind z.B. manche Waldwege noch unbefahrbar), wären automatische Neuberechnungen ideal für mich.

Auch die automatische Umschaltung auf Guiding statt der Neuberechnung ist recht nützlich.

Ich verstehe nicht, was du damit meinst. Gehst du von Navigation aus, und es wird auf Guiding umgeschaltet, wenn man zu weit von der Route abweicht? Das wäre für mich nicht sooo interessant, da ich oft mit Absicht von der Route abweiche (siehe oben: schöne Landschaft, Geocaching-Stationen, Wege nicht befahrbar usw.). Ein Rückführen (Guiding) auf die Original-Route würde mir da nichts nützen, da ich ja eine andere Strecke fahren WILL. Mein ursprünglich gestecktes Ziel möchte ich aber meist am Ende auch noch erreichen, deshalb wäre eine automatische Neuberechnung der Route zum Ziel die beste Lösung für mich.