Messages

[Wet conditions]

Hi.  Just looked at this for the first time, and skimmed the wiki.  (My head is spinning.)

In the Locus UI, may I suggest: "Wet conditions".  That means, in a general sense, things are wet right now.  "Is wet" implies knowledge of the route, but you haven't been there specifically yet.

For the explanatory text, maybe "Avoid route that may be difficult in wet weather."  (In North American English, the term "road" doesn't include trails, which are part of this.)

(In spite of my user name, I'm a native English speaker; Spanish is just a hobby to support travel.)

[...]

Wet surface
"Try to avoid muddy or slippery roads"

Not clear for me.
This Roads are muddy or slippery only if it's raining??

or this roads always are muddy or slippery because that's his normal ground conditions (bog path, road through marshland, moore land,...)? 

The iswet flag means there is possiblility of being muddy or slippery for  ways that can be - according to OSM surface data -  vulnerable to that.
Iswet could be named as well as "Prefer_roads_that_do_not_get_muddy_or_slippery_if_water_is_applied_on_them". But iswet is shorter. For being muddy as normal condition, there is OSM tag surface=mud.

In trekking bike and bike travelling context, most people would take unpaved soil track shortcut, if it is supposed to be dry, but (not too big ) tertiary road detour instead, if there are/can be muddy ponds on it.

It is generally recommended not to consider things useless until they are understood. Until integrated to Locus, people familiar to BRouter used to got quickly, what iswet flag is good for, as it is an old thing already.

What about - perhaps a crazy idea - general expandable list of "slots" for the Locus Routing

It would have
Slot Name ( like Fast Tollfree - car would be seen from the icon )
Mode, projected to the slot icon ( car, moped, bike, foot, canoe ). For BRouter may be extracted from Profile code
User routing service ( Mapquest, OSRM, GraphHopper, BRouter )
Optional legend - extracted or typed
Dynamic routing  options ( possible ?? ) like
     already available options for existing services ( car/bike/foot, fast/short for OSRM etc,)
     for Mapquest also toll, unpaved ...,
     For Brouter the used profile + extracted list of defined parameters.( or just predefined fixed list )

- I read about no single problem till now, that car-fast, car-slow ... etc. cause problems to anybody.

I can help you remember :-)

http://forum.locusmap.eu/index.php?topic=5066.msg42633#msg42633

So this system as is, is usable and logical for users.

The system, as it is used, is not logical. In my mapping I mapped "moped" -> "car slow". A moped is not a car, so this is not logical, it's just a workaround. When zossebart maps 5 biking-profiles on the 5 transport modes and has a hard time to remember what "car slow" actually is, then there's also a usability problem.

What comes now is a complication - "profiles". You care about "average users". I care currently more about less then average users. They don't care about profiles. I expect, they will use all settings as is, no need to modify it.

I do not agree. The complication is the fact that there are two "namespaces" with a mapping between them. If there's only one namespace, whether you call it a mode or a profile is just wording. A user seeing a combobox with items like "car" "moped" "roadbike" "velomobil" "bike" "hike" will be less confused than a user that has to learn that a moped is a slow car.

- anyway good point is with extra parameters. As I think about it, agree they should be shared and agree they needs to be visible easily directly during creating navigation definition (start/stop).

Think about consistency. As poutnik pointed out, it's quite arbitrary where you put the "cut" between having distinct profiles or controlling behavior via parameters (and in current beta there are far too many profiles, because most differnces would be better implemented by parameters).

There's no good reason to treat these two ways of configuring the router on different levels of visibility/reachability. So if I convinced you to put the parameters directly on the Navigation Screen, I will also convice you to put the profile name there. Then you have a layout problem because of the extra space that needs, and convice yourself that you need to remove the transport mode buttons :-)

I would keep scenario themes as the baseline, with bunch of check-in options to tweak them,
like Elevate theme for OpenAndroMaps ( Hiking / Cycling / City, each with lot of options )

exactly +1

Thank you for comments about names of themes. I'll discuss it with team - "Hike & Bike" / "Ski" could be ideal solution. BUT you gave me another idea - "General" theme. What about to remove City theme and create something between City and Hike & Bike. Menion gonna kill me but I like this idea.

IMHO, I would keep scenario themes as the baseline, with bunch of check-in options to tweak them,
like Elevate theme for OpenAndroMaps ( Hiking / Cycling / City, each with lot of options )

Hello Christian,

main key parameter for guidance that influence "when" Locus switch to next trackpoint is "Set next trackpoint" (in Guidance settings).

About rotation ... good observation. Locus filtered values from "before" screen turned off. I've fixed it now. Result is quite visible jump in rotation right after you turn screen on, but positive is, that you see it almost immediately. So "fixed", thanks.

Hello Petr
We talk about "house number sorting" in march 2016. do you remember?
I think alphabetical sorting arrays will be work. Let's try
Currently we have a wild mixed list.

done

@Andrew Heard
My description were quite simplified. There are more values that influence if road / street has record in DB. Num of segments (number of OSM Way with the same name), the distance from the city (if any exist around), houses along the road...

The handling of long roads is not ideal and the address database does not expect that there could be long roads outside the towns. The generator process them but there are some weakness.
More over is complicated to recognize if Osm Way  is part of street inside any town if it is only some named road outside.  For example almost every forest track in Germany has defined the name. For example https://www.openstreetmap.org/way/37641016

And the question is how handle such way? Is it street? Should we use this road in address search? This is probably the question for every body..

However you can send me some mistakes and I'll check them.

@Andrew: hmm I'm almost sure that my small change should have no influence on this. I may disable it, as it's just one line of code, but it really should work without a problem.

Do you have exact steps I may follow to get exactly same problem?

I'm trying to play with it little bit, but GPS is always turned of correctly in Locus, hmm :/.

EDIT: maybe I've found some weird combination, so next version probably during weekend, thanks

Hehe, oki guys, you are welcome. To make it more "fast", after save of changes, screen will be closed back to map. Hope it will be ok. And btw. do not forget to enable this button in settings, because I left it disabled by default.

Hmm, this isn't what I wanted to hear . Implemented.

Ich hab' heute ein neues Release (1.4) hochgeladen, was die Abbiegehinweise enthält:

http://brouter.de/brouter/revisions.html

Gegenüber dem letzten Patch, den ich hier vorgestellt hatte, ist das schon deutlich anders.

Es gibt "keep left/keep right" Hinweise und explizite Kreisel-Ansagen. Aber auch, wenn man mit dem "trekking" Profil entlang der Radwege über eine komplexe (Kreisel-)Kreuzung fährt, wird das in der Regel zu einer einzigen Winkel-Anweisung vereint, die dann nur noch sagt, dass man (alles-in allem) nach links fahren soll.

Ist also bisschen das andere Extrem zu dem vorherigen Zustand mit zuvielen Hinweisen, und kann auch irritierend sein, wenn man für eine links-rechts Kombination mit weniger als 40m dazwischen einen "geradeaus" Hinweis bekommt.

Aber nach meiner bisherigen Erfahrung ist eigentlich nur wichtig, dass man einen Trigger bekommt, was er dann sagt ist eher zweitrangig.

Ich hab' das im dev-forum alles auch Menion erklärt, und hoffe, dass es bald eine Locus Version gibt, die auch für Berechnungen über die Servive-Schnittstelle diese Hinweise verarbeitet.

Bisher geht's it Locus nur über den manuellen Import von GPX-Tracks. Werden die mit der BRouter-App berechnet, sollten die die Locus Hinweise enthalten (wegen turnInstructionMode = 1 = auto in den Profilen). Will man sie in brouter-web berechnen, muss man turnInstructionMode = 2 setzen.

Die zweite Neuerung in dem neuen Release ist ein "erweiterter Scan" nach Wegpunkt-Datenbanken, weil ich mitbekommen hatte, dass das öfter zum Showstopper wird, wenn die Installationsorte der Maptools nicht automatisch gefunden werden. Hab' noch keine Erfahrung, wie gut das mit Android 5, 6,, (7) .. funktioniert.

Gruss, Arndt

Anyway if you will wants to use format I use in Locus, less work for me, anyway it's not clear solution I think.

Hi Menion,

sorry for the long delay, but here's what I came up with.

You can use the latest version (1.4.) of BRouter from it's homepage (not yet on Google Play):

http://brouter.de/brouter/revisions.html

use the apk there'in, and also update the routing profiles (they are not automatically overwritten by an APK update. Simplest way is to just delete the "profiles2" directory, it will be re-created on next brouter app start)

After careful consideration, I decided to go with the native turn-instruction formats used by Locus and OsmAnd.

3 ways to generate an GPX, so 3 ways to make sure that Locus format is used:

- when creating a GPX via the BRouter app, nothing special to do. The profiles are configured to "turnInstructionMode = 1 = auto, which means it generates Locus format when using a Locus waypoint-database.

- when creating the GPX by requesting it via the AIDL interface, you must send an additional parameter
  "turnInstructionFormat" with value "locus".(Just the same way you are sending "lons" and "lats", but with a String value)

- when creating a GPX via the Web-Interface ( http://brouter.de/brouter-web/ ) you have to modify the profile to contain turnInstructionMode = 2 (use the "upload" button the upload the modified profile)

I tested the voice hints by manuelly importing them into Locus, and that works fine. So I really wold like to be able to use them also when using BRourer via the AIDL-Interface...

What you have to change for that is:

- send turnInstructionFormat = locus as secribed above

- evaluate the locus extensions containing the turn-instructions the same way you do it when importing with "merge waypoints into track"

What you should also do is look at a bug I encountered when using the "roundabout" hints:
the first instruction after a roundabout that is not a roundabout is announced as the last roundabouts exit count ("third exit") instead of the actual next instruction ("turn left").

Thanks in advance for looking into this,

regards, Arndt

@Andrew Heard
1) North Street and Slovenia Ljubljana - this should be fixed in the next address database that is in generation process

2) Inconsistent suburbs - Well it's similar to previous problem - to find the best city / district / suburb for street. If no suburb is found for street then no suburb is shown in dialog. However especially mentioned Grenfell St should be displayed with Suburb - I'll check it in the next DB (probably in the end of this week)

5) @menion I can confirm issues with Swiftkey keyboard