Messages

laufen die Versionen parallel, oder installiert man "drüber" und muss dann noch den Pfad anpassen?

Die neue Version kann auch die alten Dateien noch verarbeiten. Ich habe das gleiche Verfahren gewählt bei beim letzen Format-Wechsel im letzten Jahr:

- Verzeichnis "segments4" wird automatisch neu angelegt mit einer Datei "storageconfig.txt", die per "secondary_segment_dir" auf das alte Verzeichnis (segments3) Zeigt, damit das auch noch gefunden wird.

- "secondary_segment_dir" ist aber eigentlich dazu da, irgendwo auf die externe SD-Karte zu zeigen, solche Konfigurationen gehen also verloren und müssen nachgetragen werden.

- der Download-Manager schreibt immer in segments4 und verdeckt dann alte Dateien in segments3, die aber nicht gelöscht werden.

Der Download-Manager kann jetzt übrigens auch Updates, und hat eine leicht erhöhte Bandbreite (2Mbit = 262 Kb/s statt bisher 200 Kb/s), so dass der Dach-Download über den Download-Manager jetzt ca eine halbe Stunde dauert.

Hallo,

ich hab' die Version 1.3 hochgeladen (nur Distribution-Zip, nicht Google-Play):

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

Das ist ein rein technlogischer Update, er macht die Datenfiles deutlich kleiner, macht die carsubset-dateien überflüssig und verbessert den Memory-Footprint, verhindert also Out-Of-Memory-Fehler.

Das ist nur als Zwischenrelease gedacht, und die 1.4 wird dann (hoffentlich) auch funktional was neues bringen (Voice-Hints?) und dann auch wieder auf Google-Play erscheinen. Aber so will ich jetzt erstmal im "friendly fire" mögliche Probleme mit dem Datei-Format-Update erfahren...

Gruss, Arndt

[nur wirklich dann]

Ja klingt doch alles sehr einfach. Man braucht doch nur wirklich dann eine Anweisung, wenn sich in der Nähe des  Richtungsänderungspunktes auch noch ein(e) weitere(r) Weg/Straße/Pfad,... befindet.

Der Klang täuscht. Einmal ist es auch vom Algortithmus her bisschen komplexer. Das braucht auch ein Modell der Wege-Kategorien. Eine Autobahnabfahrt kann geradeaus gehen und ist trotzdem eine Abfahrt. Das gleiche gibts im Wald.

Dann gibt's da irgendwo eine Entfernungsskala, aber der eine Richtungs-Aenderung auch wirklich eine ist. Locus ist da schon gut und quatscht einen für "am Kreisel geradeaus" nicht so zu wie OsmAnd das tut. Um's wirklich richtig zu machen muss man aber wissen, was ein Kreisel ist.

Dann das technische Protokoll. Menion hatte mir vor langer Zeit mal was geschickt und dazugesagt, es sei alles absulut undokumentiert. Wenn sich da wirklich 2 Softwarekomponenten sinnvoll verstaendigen wollen, brauchts eine solide Schnittstellen-Definition, und ich kenne bisher keine.

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.

BRouter erstellt doch das Routing inkl. Abbiegehinweisen mit Hilfe der OSM Kartendaten, oder? Der letzten Folie deines Vortrages ist zu entnehmen, das Turn instructions auf der Todo Liste stehen. Heißt das, dass BRouter garkeine Anweisungen erzeugt?

Ja, gar keine. Sowohl OsmAnd als auch Locus machen aber selber welche, aber eben nur aus dem Verlauf des Tracks, ohne das gesamte Netzwerk zu kennen.

Auf der Folie stand "Turn restrictions", das meint aber was anderes (Abbiege-Beschränkungen für's Kfz-Routing)

Da stand aber auch "voice hints", und das meinst Du wohl. War aber keine "ToDo" Liste, sondern eine Ideen-Liste, der Unterschied war mir wichtig...

Ich sehe bessere Abbiege-Hinweise aber eher als einen der fehlenden Bausteine für sinnvolles Kfz-Routing (die anderen sind die Abbiege-Beschränkungen und die Zeit-Prognosen). Im Wald hab' ich da garnicht sosehr ein Problem damit.

Daher an dieser Stelle mal ein großer Dank an Arndt für beide stabile Versionen

Bei BRouter-Web geht der Dank aber an Norbert... und natürlich an alle OSM-Beitragenden und die Autoren und Maintainer von all den Software-Libs und Diensten, auf denen das aufbaut.

Zu der Version 1.2: der Update lohnt nur, wenn man selber Profile bastelt, weil da sind Syntax-Erweiterungen drin, ein formalerer Mechanismus zur Behandlung von Initial-Kosten und eine neue lookup-tabelle mit paar mehr tags.

Dass beim Update die lookup-Tabelle und die Profile NICHT überschrieben werden, ist übrigens Absicht. Weil wer die neue lookup-Tabelle einspielt, kann alle Datenfiles wegwerfen die älter sind als ein paar Wochen. Um upzu-daten, muss man aber nichts von sonstwoher laden, einfach das "profiles2" Verzeichnis löschen, dann wird es beim nächsten Start neu angelegt mit dem Inhalt, der im APK verpackt ist.

Wer's noch nicht gesehen hat, hier das Video zu meinem Vortrag auf der Fossgis-Konferenz in Münster zu BRouter:

https://www.youtube.com/watch?v=Eba4fcYI4h4

ich war erfreut zu lesen, dass jetzt POIs direkt angesprochen werden können (statt der from/to-Mechanik. Kurzer Test mit meiner Locus-POI-DB: Essig, da über 1000 Elemente. Das ist unfein :-(( Und sollte hoffentlich leicht zu beheben sein, hoffe ich.

Nee leicht leider nicht. Kann natürlich die Prüfung rausnehmen, laufe dann aber Gefahr, dass sich das ganze Ding aufhängt, wenn ich zig-tausend Pois in eine Combo-Box fülle. Also brauchts da ein Konzept, z.B. alphabetisch sortieren und abschneiden, richtiges paging zum durchblättern, oder nur eine spezielle "Kategorie" anzeigen in dem Fall, oder doch wieder Namenskonvention. Aber alles nicht intuitiv und schwer zu dokuemntieren.

Jaaa! So klappt es endlich! Damit kann ich leben Das BRouter Verzeichnis auf der internen, die Sekrete3 auf der externen, der Pfad dort hin in der storageconfig.txt im  segments3 (intern) Verzeichnis

So ist ja auch meine "offizielle" Lösung für Android 4.4 + externe SD : http://www.brouter.de/brouter/kitkat_survival_readme.txt

Was da aber jetzt genau klemmt in der Konstallation, wo alles auf der externen Karte ist, weiss ich nicht. Ob's wirklich mit der Groesse der Karte zu tun hat oder mit Deiner speziellen Konstellation aus "gerooted und sd-zugriffs-berechtigung repariert" auch nicht. Da werden schon ein paar Datei-Pfade auf existenz geprüft bei der Suche nach den Wegpunkt-Datenbanken von Locus, Oruxmaps und OsmAnd, aber welcher dieser Zugriffe das ist weiss ich nicht.

Es gibt eigentlich fuer solche Probleme ein optionales debug-log-file: Wenn die Datei "debug.txt" im brouter-verzeichnis existiert, wird da bisschen was protokolliert, das Timiing dieser Datei-Zugriffe aber dummerweise nicht. ich werd das in der nächsten Version mal erweitern und mich dann hier nochmal melden.

Dann muesste er die Punkte finden, aber beim Versuch, den berechneten Track abzuspeichern wieder einen Fehler werfen, weil er dann in ein schreibgeschütztes Verzeichnis schreiben will.

Nachtrag:

Ich habe gerade versucht
"additional_maptool_dir=/storage/extSdCard/Android/data/menion.android.locus.pro/files" einzufügen. Abspeichern klappt nicht.

... jetzt hatte ich doch auf deutsch erklärt, was hier auf englisch schon beschrieben ist  http://brouter.de/brouter/kitkat_survival_readme.txt und frag mich, ob Du das überhaupt liest?

BRouter *kann* den Track nicht unter "mapitems" abspeichern, weil er für dieses Verzeichnis in dieser Konstallation (also im spezial-Verzeichnis auf der externen SD Karte unter Android 4.4) keine Schreibrechte hat.

Also muss man noch eine Umleitung hinzufügen und den Track woanders speichern. Dann findet Locus ihn natürlich nicht so leicht.

Daher an der Stelle nochmal ein Hinweis auf die "schnellen partiellen Neuberechnungen": Statt den Track "brouter0.gpx" zu öffnen, kann man ihn auch über die Dienste-Schnittstelle neu rechnen, und das geht auch für sehr lange Strecken, wenn der Zielpunkt exakt der selbe ist. Denn dann rechnet er die Strecke garnicht wirklich neu, sondern nur den Anfang und nimmt den Rest aus der vorhergehenden Berechnung. 

...habe ich versucht auf die SD Karte zu verschieben.(/storage/extSdCard/Android/data/menion.android.locus.pro/files).
Das ist  mir bei Locus auch gelungen... Nur BRouter zickt ein wenig herrum.

Wie gesagt, das ist alles bisschen spziell mit Android 4.4 und der externen SD-Karte. Wenn sich Locus komplett nach /storage/extSdCard/Android/data/menion.android.locus.pro/files installiert hat, dann liegt da jetzt auch die Wegpunkte-Datenbank, in der deine Punkte gespeichert sind. Dieses Verzeichnis findet brouter aber nicht.

Deswegen gibt es eine neue Konfigurationsdatei, um ihm auf die Sprünge zu helfen, soe wie hier erklärt: http://brouter.de/brouter/kitkat_survival_readme.txt

Heisst, Du musst in einer Datei "brouter/segments3/storageconfig.txt" einen Eintrag anlegen:

additional_maptool_dir=/storage/extSdCard/Android/data/menion.android.locus.pro/files

Dann muesste er die Punkte finden, aber beim Versuch, den berechneten Track abzuspeichern wieder einen Fehler werfen, weil er dann in ein schreibgeschütztes Verzeichnis schreiben will. Also brauchts dann noch eine "Verweis-Datei" in diesem Zielverzeichnis namens "brouter.redirect" in der dann wiederum steht, wohin denn stattdessen gespiechert werden soll. Das kann dann aber nur ein Verzeichnis sein, wo Locus sie wiederum nicht so leicht findet.

Also alles bisschen unschön, aber ich bin nicht Schuld, Google hat's vermurkst, bzw. so ein kleines bisschen auch Locus und OsmAnd, weil die beide das Verfahren verwenden, die komplette Installation in das schreibgeschützte Spezialverzeichnis auf der SD-Karte auszulagern. Das ist aber keine so gute Idee, weil es z.B. automatisch gelöscht wird, wenn man die App de-installiert.

für NRW gibt es einen Routenplaner http://radservice.radroutenplaner.nrw.de/rrp/nrw/cgi?lang=DE
Dieser kann so befragt werden, dass er Radnetzwege bevorzugt.
Besteht die Möglichkeit ein Profil für den BRouter bereitzustellen, welches sowas beinhaltet?

Naja das trekking-profil macht das schon immer (und trekking-ignore-cr macht es nicht)

Allerdings werden da regionale wie nationale Netze gleich behandelt. Mit dem Update des Datenformats sind die Netzte jetzt einzeln drin, man kann es also so konfigurieren, dass er z.B. bevorzugt nationalen Fernradwegen nachfährt.

[2]

Wie jetzt 3?
Nicht mehr segments2
Einfach so?
Wie gut brouter auch immer sein mag - es nervt
Ich beiss mir jetzt mal auf die Zunge  - aber user togtog hat nicht so ganz unrecht...

Hi, ja mal ein paar Worte zu dem Update, weil da steckt viel mehr Arbeit drin als es scheint.

Gut sein reicht eben nicht, man muss auch gut bleiben, und da war die Beschränkung in der lookup-Tabelle einfach nicht mehr haltbar. Es kommen einfach neue Tags, die wichtig sind oder wichtig werden, "bicycle=use_sidpath" oder "incline" sind so Beispiele, und wenn man das nicht kann, dann ist man in zwei Jahren Geschichte.

Vom Wanderrouting ganz zu schweigen, es ist eigentlich kaum zu glauben, dass BRouter in Verbindung mit Wanderrouting genannt wird, obwohl er keine Wanderrelationen kannte. Mit dem Update kennt er sie. Ist aber erstmal mehr eine Investition in die Zukunft, denn ich hab' ja bisher keine Profile veröffentlicht, die die neuen Tags auch benutzen.

Die Transition vom alten Datenformat zum neuen ist dabei ein schwieriges Ding, weil man ja nicht einem die Installation zerschiessen darf, dem unbemerkt ein Update aus Google-Play eingespielt wurde. Und wie hier ja berichtet wurde: im Prinzip funktioniert das, man merkts halt erstmal nicht.

Also ich freu mich über das Interesse an dem Update und den Testfeedback, obwohl das noch nicht bei Google-Play ist. Besonders freuen würde ich mich über Versuche und Berichte, mit den neuen Tags neue Profile zu bauen, also insbesondere ein Wander- und ein Rollstuhl-Profil.

Gruss, Arndt

aber kann denn nun jemand dem BRouter beibringen über´s Tor zu klettern? 
Eine angepasste Version des Trekking.brf wäre schön.

Na genau, wie ich das geschrieben hatte (da waren die Node-Sperren auch schon weg).

siehe Attachment

Ein OSM mapper hat dies so getaggt - brouter müsste sich eigentlich nach eindeutigen Regeln richten.

So ganz eindeutig ist es leider nie. Der Klassiker ist der Wirtschaftsweg mit dem Schild "Verbot für Fahrzeuge aller Art, Land- und Forstwirtschaft frei", den man eindeutig (lernt man in der Fahrschule) mit dem Fahrrad nicht befahren darf, nur das dummerwise oft am gleichen Mast die lokale Radwegebeschilderung hängt.

"Default-Access Rules" für barrier-nodes sind ein schwammiges Thema, access=permissve/destination auch, Fahrräder über bicycle=no + foot=yes, bicylce=no auf einer Nicht-Motorstrasse (wegen Radwegebenutzungspflicht)... Da steckt schon einiges an Heuristik drin, weil die Regeln eben nicht so eindeutig sind.

Spanien ist nochmal ein anderes Problem, weil ganz andere Regeln bzgl. Zutritt zu privatem Wald/Feld als in Deutschland. Wollte mal auf Mallorca eine Raddtour machen in ein Tal, von dem im Reiseführer stand, es sei Mittwochs erlaubt, es zu betreten. War dann auch Mittwochs da, stand vor dem wirklich beeindruckenden Tor, aber siehe da: es hatte einen Knopf zum öffnen. Um mich abzuschrecken hat's gerreicht, weil ich mich vor Hunden fürchte und genau so sah das aus.

Kann man irgendwo, irgendwie ...vielleicht in der *.brf-Datei....eine "mir sch...egal, ich bin Hiker ..ich kann überall laufen-außer auf dem Wasser" Einstellung herbeiführen ?

Ja klar, in trekking.brf (Ausdrücke jeweils ersetzen):

im way-context:

  assign accesspenalty 0

und im node-context:

  assign initialcost 0

Auf Autobahnen kannst Du dann aber immer noch nicht laufen

@togtog
Ich verstehe deinen Frust und versuche garade selbst heraus zu bekommen was Arndt dazu bewegt, sein augenscheinlich gutes Algorithmus-Tool nur einem elitären Keis zugängig zu machen

Hi Gynta,

das ist jetzt nicht fair weil Du wolltest ja heute ohne Ironie. Ich bin selbst kein Locus-Profi, hab's aber jeute mochmal nach dem com-magaizin-Artikel konfiguriert und das war eindeutig. Togtog sagt, er hat's gelesen, aber versteht nicht und überhaupt. Also erstmal eine reine Locus Frage und nicht spezifsch zu BRouter, und andereseits nicht klar wo hier die Doku-Lücke ist. Also wenn Du tatsächlich der Meinung bist, man solle jeden mitnehmen, dann musst Du's halt auch machen...