Messages

you are right, I see it now. Had slipped my mapview too far on that coastline...

Gesendet von meinem G8441 mit Tapatalk

Okay sorry, there must have gone something wrong at my side. Will try to investigate it in the next days...

For example this way is not shown with latest Github Tiramisu Velo: https://www.openstreetmap.org/way/687857869
It's highway=path and bicycle=designated, no foot tags at all.
Or is it shown for you?
Maybe I did a mistake? The downloaded zip at least contains the latest changelog, so I think I should have the right one.

Even highway=path + bicycle=designated + foot=designated can be a good cycleway (maybe also take surface into account), for example with segregated=yes it means a shared foot- and cycleway where there is a lane for cyclists and one for pedestrians. See https://wiki.openstreetmap.org/wiki/Bicycle , Table "Miscellaneous", row "S5" for example.

I tried it, but it doesn't seem to work?  Should it work with paths that have both bicycle=designated and foot=designated or only with bicycle=designated alone?

Gesendet von meinem G8441 mit Tapatalk

I think Saturo is right, the Tiramisu Velo Theme has to be changed to also show highway=path + bicycle=designated at least.

In OSM, a path is any way which is not meant for motorized traffic. This must not necessarily be a small path in the woods.
See OSM Wiki: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath -> "Usage as a universal Tag"

It's also used for combined foot- and cycleways. Both of Saturos examples seem to be such combined ways (note that he changed the tagging to highway=cycleway in the meantime, which might be incorrect).

You can find many of such ways:

http://overpass-turbo.eu/?Q=way%0A%20%20%5Bhighway%3Dpath%5D%0A%20%20%5Bbicycle%3Ddesignated%5D%0A%20%20%5Bfoot%3Ddesignated%5D%0A%20%20(%7B%7Bbbox%7D%7D)%3B%0A(._%3B%3E%3B)%3B%0Aout%3B&C=49.7204;11.08559;14

If there is no cycle route going over it, these ways are invisible in Tiramisu Velo, although perfectly suitable for bikes.

Genau, nutze für Rundkurse o.ä. lieber Strecken-Priorität.

Wenn du eine Strecke mit festen Zwischenzielen planst, die du auf jeden Fall erreichen willst (z.B. verschiedene Geocaches), dann ist Endpunkt-Priorität sinnvoller. Dazu müssen die Zwischenpunkte aber auch als solche in der Route vorhanden sein (im internen Routeplanner blaues Quadrat statt grünes Dreieck).

Kommt immer darauf an, was das Ziel der Navigation ist:

Ziel(e) erreichen: dann "Endpunkt - Priorität"

eine bestimme Route abfahren: "Routen - Priorität"

Ich finde, so wie es in Brouter-Web implementiert ist ("Track als Route laden") ist es schonmal ein guter Anfang. Dort kann man auch mit einem Schieberegler die Anzahl der Zwischenpunkte anpassen.
Natürlich mit einem entsprechenden Routingprofil.
Vielleicht wäre es noch hilfreich, Stellen größerer Abweichung zwischen original und nachgeroutetem Track hervorzuheben, so dass der User dort ggf. manuell optimieren kann.
@freischneider: wenn ich das richtig verstehe, willst du einen Foren-Thread zur Ideensammlung aufmachen? Die verlinkte Helpdesk-Idee findest du dafür wohl ungeeignet?

soweit kannte ich das schon. Aber da kann ich gleich das normale Menü benutzen. In dem Block stand was man kann es über BT steuern. Aber wie. Wenn man mit langen Handschuhen auf dem Rad unterwegs ist, könnte das nützlich sein.

Ich kenne nur den indirekten Weg über Tasker (BT -> Tasker -> floating menu action task).
Also aus Tasker einen Broadcast Intent mit "function" "floating_menu" senden. Verwende ich seit einiger Zeit problemlos.

Don't know if it's specific to this current version or generally to LM4, but Action Task "quick_action_menu" doesn't seem to work any more. The Wiki still documents it. Were there any changes in LM4 compared to LM3? If I try to trigger it from Tasker, a toast with "Action `quick_action_menu` does not exists" is shown.

PS: yes, I changed the Package from "menion.android.locus.pro" to "menion.android.locus" of course.

I wanted to create ticket on helpdesk this morning, but can't reproduce any more. Did you change anything on your side?
If the problem should occur again, I will create a ticket.

I unfortunately have problems with the sync. After installation of the first official version of LM4, I imported my database from LM3 backup, and manually synced it to the web. It took several days (sic!) to get this through (I have a relatively large track- and point-database). It seems that whenever the connection was interrupted (bad WIFI or no WIFI because I left the house), the sync started from scratch the next time WIFI was available. However, after some days, I managed to fully sync over night (might have been luck because normally ther is the forced dsl reconnect at night).

From now on, I thought, only changes (new tracks etc...) in the database would have to be synced. However, Locus seems to try to sync my whole database again for example after I recorded a track! Also, it behaves like the first sync and starts anew after connection losses. This morning it was at 96% when I had to leave the house for work, now it's starting again from the beginning :-(
What also puzzles me is that it is DOWNLOADING points and tracks from the web and not UPLOADING my new items.
Is this intended behaviour? If it was, I would have to disable sync I fear, because I normally don't have a stable WIFI over several hours everytime I add a track or point! So please tell me this is a bug and it can somehow be solved.

First, great work with the web-planner. I'm looking forward to further enhancements.

One question: is it intentional that the height-graph is only shown for tracks which are currently planned, but not for "old" tracks synced from the phone (although they have height-data)?

And are there plans to also make the synced POIs visible in the webplanner? Would be great to have e.g. POIs of trailheads available in the planner.

Hey,

first, congratulations for the new version! great (and much) work!
Immediately signed gold last week. Finally a way to give at least something back to you guys, you are doing great work! I tried to buy some locoins from time to time in the old version to support you a little bit, (and get new lomaps with the pois), but now with the subscription I feel better, because I cannot forget it :-)

I have a question regarding migration from pro to 4. I did a full Backup in pro and imported it to 4. What else exactly do I have to do to fully migrate?
- change default directories from "menion.android.locus.pro" to the "menion.android.locus" - subfolders
- copy over all those folders (maps?, mapsOnline?, Mapsvector?, srtm?, MapItems?, router?, config.cfg?). or are some of them included in the backup? I'm a little bit confused
- change all the package names for intentents in my tasker task from "menion.android.locus.pro" to "menion.android.locus"?
- what else did I miss?

Yes, my request is to do it like brouter-web and dynamically parse and display all parameters from brf file.

I don't have a specific request for confirmed parameters, despite maybe the kinematic model parameters (totalMass, Maxspeed etc.), which are brouter-builtin.

All other parameters I would like to use mostly exist in single profiles only and therefor I wouldn't recommend adding them as supported to Locus just because of this one profile.
For example, I created an enduro-motorcycle profile on user-request which has a "non-standard" parameter to switch the avoidance of paths, or I consider adding another parameter to influence uphill routing on paths to my mtb profile etc...). Without support for generic parameters, I would have to generate separate profiles of all permutations of profile parameters like libor does, but it gets confusing and it's not easily switcheable for example in a routeplanner session (if the profile-variants aren't already assigned to the (limited) slots in Locus).

As I wrote before, I think it's ok that the default setting only shows the whitelisted parameters (as is now).
But I would like to have the possibility to enable "full dynamic parameter" mode in expert settings for power-users (which you clearly embrace with locus (intens, url favourites, bt-buttons, dashboards, quick pois, presets...should I go on with the list?  )).
Maybe you could group the whitelisted parameters at the top of the settings dialog and show the other "non-standard" parameters below. Maybe with a caption "additional settings" and in a fainter color?

@zossebard
The set o profiles we currently work with is and will be available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Some of them are default profiles from parent brouter repository and we rather want to keep them as they are validated by the previous usage in the app. Some of them are by Poutnik. We also consider your mtb profiles, of course. The modifications we made so far are rather minor. Feedback and improvement are welcome, just let us keep in mind that this set should be a safe set of defaults for all users. Regarding all profile parameters: I think we got your point, Menion will do that.

thanks for the information! nice to hear that you consider supporting more parameters. this way power users will e.g. also be able to tweak kinematic model parameters to optimize ETA (if supported by the profile).

Sent from my G8441 using Tapatalk