Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - abrensch

Pages: [1]
1
[DE] - deutschsprachiger Forumsbereich / Re: BRouter Version 1.4.8
« on: December 10, 2016, 20:35:46 »
Version 1.4.8: http://brouter.de/brouter/revisions.html

(noch nicht auf Google-Play)

Insbesondere Turn-Restrictions sind dabei, zumindest die einfachen, nicht die komplizierten Wendeverbote mit "via-way". Für Auto-Profile wirken die per Default, für Fahrrad-Profile muss man sie einschalten.

Noch eine Bitte an Euch: ich bekomme bei  Google-Play zum Teil sehr heftige Kritiken, die offenbar mit Showstoppern unter Android 6 zu tun haben. Ich besitze bisher kein Android 6 Gerät, darin liegt's wohl auch ein bisschen, aber deshalb bin ich an konstruktivem Feedback zu solchen Showstoppern interessiert.

Danke und Gruss, Arndt
The following users thanked this post: erfi

2
[DE] - deutschsprachiger Forumsbereich / Re: BRouter Version 1.4.8
« on: October 24, 2016, 15:53:09 »
ich bitte um eine verständliche Erklärung added turncost as start-direction bias (locus only) am besten an einem Beispiel 8)

Menion hat in die Aufrufschnittstelle zwei neue Parameter eingebaut, mit denen erreicht werden soll, dass eine dynamische Neuberechung mehr "nach vorne" geht und nicht schon veraltet ist in dem Moment, wo sie angezeigt wird:

- direction
- noManveuverTime

Nur ist das so zu Zeit nicht machbar, weil würde einige der strukturellen Änderungen erfordern, die auch für Abbiegebeschränkungen notwendig sind.

Aber das, was ich leicht tun kann, hab' ich gemacht: ich benutze die aktuelle Start-Richtung und rechne für den ersten Wegschritt die Winkelkosten relativ zu dieser Startrichtung genau, wie jeden anderen Winkel auch.

Dadurch rückt der Punkt, ab dem die Vorwärtslösung gewinnt, um "turncost/costfactor" Meter nach vorne man bekommt also in mehr Fällen schon bei der ersten Neuberechnung die Vorwärtslösung.

Aber wie gesagt, nur ein leichter Bias, noch kein Navi mit künstlicher Intelligenz, das raten kann, was man vorhat.
The following users thanked this post: balloni55, erfi

3
[DE] - deutschsprachiger Forumsbereich / Re: BRouter Version 1.4.8
« on: September 14, 2016, 11:56:53 »
Wäre schön wenn mir jemand bei meinen Problemen helfen könnte diese zu beseitigen. Da ich schon gerne wegen meinem Hund im vorraus wissen würde wieviel Km und Hm es sind.

Hab' das heute morgen im Zug getestet, und natürlich, in Bayern alles prima, aber als ich dann ausgestiegen bin und wollte die letzten 5km an mein Ziel radeln (dass ich im Zug schon eingegeben hatte, vor dem GPX-Fix), da hätte ich das Ding an die Wand schmeissen können und war genauso frustiert wie Du.

Zufällig hatte ich das debug-log aktiv und kann sehen, was passiert war: Locus wollte partout nach Bayern! Hat auch so eine gestrichelte Linie gemalt mit 383km, und auch wenn ich "Navigation beenden" und neue Zieleingabe gemacht habe, wollte der immer noch nach Bayern.

Alles, was geholfen hat war, Locus richtig zu beenden (also nicht nur in den Hintergrund drücken) und neu starten.

Passiert ist das mit Version 3.18.7

Wenn Du solche Effekte hast, einfach mal den Request, der den Timeout gemacht hat, mit der BRouter-App nachrechnen ( "<repeat timeout> shortcut in der aktuellen Version BRouter 1.4.5 ). Dann sieht da ja sofort, wo Locus Dich hinschicken wollte.

Oder, wenn Du die Bordmittel dazu hast, auch mal das debug-log aktivieren: dazu eine leere Datei mit Namen "debug.txt" in das Basisverzeichnis von BRouter legen. Und wenn nach so einem Fehler dann da was drinsteht, diese Datei hier anhängen.
The following users thanked this post: FXP_Freak

4
Versions / Re: [APP] - version 3.18.x (27. 6. 2016+)
« on: August 30, 2016, 19:48:40 »
So, user steps are:
1. Attempt Brouter navigation in Locus but get timeout.
2. Use Brouter app to do same calculation, using remote.brf profile and selecting a to point and a from point.
3. Now it will work in Locus so either import track, or recalculate.
Am I right? If so it's still not very user friendly.

I uploaded a new version with some (60%) Performance improvement, and with a new shortcut to simplify this workflow:
(not yet on play, only here: http://brouter.de/brouter/revisions.html )

After a timeout, if you start brouter-app (within 5 minutes) you see "<repeat timeout>" in the profile list, and this way you can redo the timed-out calculation and update the reference track without any further click.

More user friendly?

BTW, seems that in the current Locus version, the display of timeout-messages (or any other error-messages) is broken.
The following users thanked this post: poutnikl

5
[DE] - deutschsprachiger Forumsbereich / Re: BRouter Version 1.4.8
« on: August 30, 2016, 19:43:05 »
Ich denke, es kommt auf die Anzahl der Möglichkeiten (Kreuzungen) an, die auf Deiner Strecke liegen. Irgendwann schlägt dann das timeout zu. Welchen Fehler bekommst Du genau? screenshot?

Fehlermeldungen sind so ne Sache, weil Menion in der neuesten Locus Version die Anzeige der Fehlermeldungen zerschossen hat...

Ich hab' eine neue Version hochgeladen (1.4.4, noch nicht bei google, nur hier: http://brouter.de/brouter/revisions.html ) mit etwas (+60%) Performance-Verbesserung und mit einem neuen Shortcut, um nach Timeout leichter die Berechnung zu vollenden und so eine Timeout-freie Berechnung aus Locus vorzubereiten.

Die neue Version, mit einem neueren Gerät (ARM Cortext A53 Prozessor) sollte auch in dicht gemappten Regionen die 100km ohne Timeout voll kriegen. Mit den KFZ-Profilen auch mehr.

Und wenn doch timeout, dann ist's mit dem neuen Shortcut ja auch nicht so schlimm.
The following users thanked this post: strcat, erfi

6
Versions / Re: [APP] - version 3.18.x (27. 6. 2016+)
« on: August 12, 2016, 14:31:51 »
- 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

Quote
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.


Quote
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.

Quote
- 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 :-)
The following users thanked this post: Andrew Heard

7
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
The following users thanked this post: gynta, tommi, franc, Andrew Heard

8
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

 
The following users thanked this post: tommi, michaelbechtold, Andrew Heard, Tomáš Janoušek

Pages: [1]