Ich vermute, es liegt am Weg-Punkt-Matching. Da gibt es die Limitierung, dass sehr lange Wegsegmente eventuell nicht gefunden werden, wenn beide Endpunkte zu weit (> ca 10km ) vom Suchpunkt entfernt sind. Wenn diese Vermutung stimmt, sollte man aber insgedam über diesen Abschnitt der Donau routen können, wenn nur Start-und Zielpunkt nahe genug an einem Netzwerkknoten (also z.B. einer Flussmündung) liegen.
Ich muss das noch verbesserrn (Problem tritt bei Autobahnen ja prionziell auch auf) und schwer ist das auch nicht, ich muss nur die Länge der Wegsegmente begrenzen und Zwischenknoten einfügen.
river=stream hab’ ich nicht mit in dem Filter, ist daher nicht Teil des Netzwerks. Wenn ich das Fluss-Routing von Melk nach Altenwörth (zur Mündung der Krems) probiere, dann geht es, also wirds am Wegpunkt-Matching liegen.
Ich hab’ ein Issue eingestellt bei Github/Brouter dazu
ich schon wieder… bin erstaunt darüber, warum der Online-Brouter neuerdings motzt wenn ich mein eigenes Routing-Profil hochlade, und folgende Fehlermeldung bringt:
Profile error: ParseException at line 32: unknown lookup name: longdistancecycleway
Das Profil beruht auf Trekkingnosteps, und bei dem kommt das auch…
hast du da was geändert?
Weil da ist die Struktur der Profile bisschen anders. Aber nur bisschen, es sind nur solche technischen Anpassungen, wie z.B., dass es longdistancecycleway als zusammenfassendes Tag für alle Radrelationen nicht mehr gibt, dafür aber die Rad (und Wander-) Relationen einzeln nach network, also z.b. “route_bicycle_ncn”.
Also Du solltest entweder die “aktuelle” Version des Online-Routers benutzen (BRouter web client) oder aber diese technischen Anpassungen in die von Dir angepasten Profile “hinein-mergen” (indem Du Dir die Differenzen anschaust zwischen dem alten Profil:
Auf google-play ist das bisher nicht, ich trau mich noch nicht, weil die “Transition” zum neuen Datenformat ist relativ touchy, und bei 4000 aktiven Installation mit geschätzt 1000, die automatische Updates eingeschaltet haben, kann das auch schiefgehen, daher soll das erst noch bisschen reifen.
Von der Funktionalät zwar relativ unspannend, aber doch einige wirkliche Verbesserungen in dem Update, 4 möchte ich nennen:
das Datenformat ist jetzt sowohl flexibler (kann beliebig viele tags und Relationen kodieren) und gleichzeitig kompakter (25% kleiner)
es gibt erweiterte Konfiguration, die es erlaubt, auch auf einem nicht gerooteten Android 4.4 Gerät die Datenfiles auf der externen SD-Karte zu speichern
die “timeout-freien Neuberechnungen” haben jetzt einen “trivial shortcut” und damit macht es sehr viel mehr Spass, mit Osmand eine Langstrecke abzufahren und dabei ziemlich prompte Neuberechnungen zu bekommen, wenn man von der Route abweicht oder der GPS bisschen jittert.
das Skalierungsproblem im Download-Manager bei High-Definition-Screens ist behoben (das in der Routing-Animation aber noch nicht…)
Die Standard-Profile sind aber noch die alten, d.h. sie machen noch keinerlei Gebrauch von den neuen Möglichkeiten, die das erweiterte Dateiformat bietet. Und ich hoffe da immer noch auf Input von den Wanderern und den Rollstuhlfahrern. Weil ich selbst wander einfach nicht genug, um da irgendwas sinnvolles zu fabrizieren.
Freu mich wie immer über Feedback, speziell dazu, wie der Übergang zum neuen Datenformat funktioniert und ob’s dabei Showstopper gibt.
Ich habe jetzt die manuelle Installation 1.01 installiert, die (nach der Meldung beim Installationsvorgang) die manuell installierte Vorgängerversion ersetzt hat. Beim Start bekomme ich jetzt eine Fehlermeldung “error occured java.langnullpointerException”.
Bei der Gelegenheit, gibt es auch für die manuall zu ladenden Navi-Daten eine visuelle Übersicht, welche Kachel welchen Bereich abdeckt?
Nachtrag: Ich habe eine Datendatei ins 3er Verzeichnis kopiert, danach liess sich die Datei starten und fragte ob ich Downloadmanager oder Programm haben will, habe Download gewählt (obwohl mein xperia active -ics- da vorher immer stehen geblieben war; ich kann nicht zoomen). Dann hat das Programm gemeldet, die alten Strukturen müssten weg, also alle Verzeichnisse mit einem Dateimanager gelöscht und neu gestartet. Das Programm fragt wo die Daten hinsollen und startet dann wieder die Karte, die ich nicht zoomen kann …
Nachtrag2: brouter deinstalliert, Verzeichnisse wieder gelöscht. brouter lokal wieder installiert, er fragt aber nur wohin die Dateien soll und startet den Downloadmanager, mit dem ich aber mangels zoom-Möglichkeit keine Daten herunterladen kann …
Nachtrag3: Daten der App im Appmanager gelöscht, Datei deinstalliert. Datenverzeichnis gelöscht. neu installiert. Wieder Downloadmanager, wo ich nicht zoomen kann. Ich geb’s erst mal auf. Schade
Der Manuelle Download von http://brouter.de/segments3 hat aber ja doch das Problem gelöst, also wars nicht wirklich Grund zum Verzweifeln und Aufgeben…
Nachtrag: Heute früh mal alles neu installiert und jetzt kann ich wenigstens beim Start wählen, dass ich in die App komme. Werde dann mal testen, was ich so an Routen geboten bekomme. Auf einen ersten Blick sind mir beim Fahrrad außerorts noch zu viele Straßen mit Kfz Verkehr drin. Aber das kann man ja irgendwo einstellen …
Jedenfalls schon mal danke für das interessante Programm. Aber es war ziemlich viel Arbeit, bis ich das am Laufen hatte. Irgendwie fehlte mir zunächst der Überblick, wie es einzusetzen ist.
Ich wollte das Programm auch mal ausprobieren. Leider ist doch sehr wenig dokumentiert, man muss jede Kleinigkeit im Internet suchen.
Meine Frage, welche von den Dateien braucht man für Südwest-Deutschland? http://h2096617.stratoserver.net/brouter/segments2/
oder nimmt man die? http://h2096617.stratoserver.net/brouter/segments3/
Ich kann die nur über das Netz auf meine Handy kopieren.
Und wohin sollen die, es wird ja nur ein Verzeichnis segments3 angelegt und nicht segments wie man es in einer Installationsbescheibung lesen kann.
Außerdem bekomme ich bem Start immer die Fehlermeldung:
java.lang.NullPointer.Exception
Die Fehlermeldung, die Du am Ende nennst, war bei mir weg, als ich die Navi-Daten gespeichert habe. Du must bis Version 09 die segments2 Daten nehmen, ab Programm Version 1 die 3er. Wenn das 3er Verzeichnis schon angelegt war, dann müsstet Du eben auch die 3er herunterladen (es gab eine Änderung der Datenstruktur).
Die Kartenverteilung findest unter dem allerletzten Link in Post #396 ein bisschen weiter oben. Für Süddeutschland kommen da zwei Kacheln in Frage.
Volle Zustimmung übrigens zur Dokumentation. Ich habe mich da nur durchge"quält", weil doch einige Nutzer von der Qualität der Routen geschwärmt haben.
Die GPX + KML Download-Links sollten jetzt auch im Firefox zu einem Öffnen/Speichern Dialog führen.
Danke noch für den Link, ich verwende jetzt den Content-Disposition Header und spezifische “application/…” Mime-Types. Das HTML5 download Attribut funktioniert mit unserem separaten Server nicht, da dieses bei Firefox auf same-origin beschränkt ist und auch kein CORS unterstützt. Details siehe Issue.
Der Update ist jetzt auf auf Google Play (Version 1.0.2)
Der Null-Pointer beim Start ist selbstverständlich behoben (das “kann-nicht-zoomen-Problem” bei Sony Experia konnte ich aber noch nicht lösen…)
Die Routing-Profile sind unverändert gegenüber der 0.9.9 Version, von den neuen Möglichkeiten durch die erweiterte Lookup-tabelle ist da also noch kein Gebrauch gemacht.
Hallo,
ich musste brouter auf meinem Sony Xperia L neu installieren (habe es von Google play runtergeladen).
Ich habe nun in den Ordner segments3 die Dateien E10_N50(2).rd5 und E5_N50(2).rd5 von hier http://brouter.de/brouter/segments3 reinkopiert.
Wenn ich nun brouter öffne kommt die Meldung “brouter wurde beendet” und in Osmand kommt die Meldung “from-position not mapped”.
Vor der Neuinstallation lief brouter immer einwandfrei. Warum habe ich jetzt diese Fehlermeldungen?
Das ist so ein Windows-Ding, dass “(2)” ergaenzt wird, wenn der Download-Manager eine Datei zu einem Namen zum zweiten Mal lädt.
Du musst sie umbenennen in “E10_N50.rd5 und E5_N50.rd5”
Das erklärt zumindest das “not mapped” aus der Dienste Schnittstelle. Warum die BRouter-App dadurch crashed weiss ich aber nicht. Könntest Du mal auf “Bericht senden” drücken nach dem Crash, dann bekomme ich den Report.
Du musst auch darauf achten, kein “brouter” Arbeitsverzeichnis aus der alten (0.9.9) Installation wiederzuverwenden, weil sonst werden die Lookup-Tabelle und die Profil-Dateien nicht ersetzt.
Ich habe die Dateien umbenannt. Osmand berechnet jetzt die Routen wieder und die BRouter-App crashed auch nicht mehr.
Läuft alles wieder ohne Probleme.
Hallo bei diesen Koordinaten N 49,97785° O 10,68241° gibt es eine Unterführung . Routen Fahrradrouten in Oruxmap mit der Einstellung MapQest also Onlinerouten werden korrekt durch die Unterführung berechnet.
Verwende ich den Brouter wird nicht durch die Unterführung geroutet . Nicht mal wen ich direkt links und rechts neben der Unterführung Start und Endpunkt setze .
RD5 files sind aktuell 3 wochen alt, die gegend hat aber einen Aenderungssatz, der nur 9 Tage alt ist. Die Unterführung ist also offenbar neu eingetragen.
Probier’s morgen nochmal, sobald’s hier durch die Unterführung geht:
