Hmm, schade. Das sollte man ändern. Ein neues Tag/Attribut dafür?
Bahntrassen haben einen ganz besonderen Character, die sie von anderen Radwegen unterscheidet.
Die sind eben nicht entlang der Hauptstraßen, sondern mitten in der Landschaft.
Steigungen im Mittelgebirge werden durch Tunnel und Viadukte unterdrückt.
Die Attraktivität für Radfahrer ist also besonders hoch, gerade wenn man noch einen Kinderanhänger ziehen muss.
Meinst du den BRouter könnte man als Plugin in OsmAnd integrieren,
so dass er wie der eingebaute Router fungiert ?
Also incl. Routen-Neuberechnen, wenn man mit Absicht von der berechneten Route abweicht
(bei mir sehr typisch).
Damit kann man sich im Android-Market auch noch ein paar Euros dazuverdienen.
Du wirst schon reich, wenn nur ein Bruchteil der weltweiten Population (1 Mrd.?)
mit Android-Smartphone und Fahrrad jeweils ein paar Euros für das Plugin geben würden.
Sehr viel Konkurrenz hast du bei Profil “Rad” nicht. Man muss nur eben besser sein.
Fürs Auto ist mein kommerzielles Navi besser und darum nutze ich das dort exklusiv.
Genau das hab ich längst gemacht und so benutze ich das auch fast täglich:
Bei dem Pull-Request bin ich mir aber mittlerweile nicht mehr so sicher, ob Victors Bedenken wirklich technisch motiviert sind oder ob er einfach nicht will.
ich habe den BRouter mit dem MapsforgeSwingMapviewer “verheiratet”. Ein Tester hat den Router jetzt mal in den Schweizer Alpen “vergewaltigt”. Routet man jetzt auf einer Bergstrecke in kurzen Abschnitten geht der Router irgenwann zurück auf eine “weit” abliegende Nebenstrasse…
Meine Frage ist nun: Läßt sich der BRouter auch so konfigurieren (vergewaltigen?) dass er auch auf Wanderpfaden (Bergpfaden) die kürzeste Route sucht. Egal welche Wege/Pfad Beschaffenheit vorhanden ist. Ich weiß, e soll ja ein Fahrradrouter sein. Ich bin in dieser Richtung auch zufrieden.
Zusammenfassung: Ist es möglich,den BRouter so zu konfiguriern dass er den kürzesten Wegt such unabhängig von Steigung und Wegbeschaffenheit ?
Hintergrund: WanderRouten in den Bergen…
Ich hab’ das mal in den östereichichen Alpen gesehen, dass eine Wintersperre für den Pass als access=no für ein kurzes Stück der Passstrasse eingetragen war. Was dann natürlich dazu führt, dass der Router irgendwelche noch unpassierbareren Wanderrouten findet.
Sowas kann man patchen, indem man access=no einfach rausnimmt, also aus “or access=private access=no” einfach nur “access=private” macht
vielen Dank für die Antworten. Ich habe mal ein Snapshot gemacht (Zentrum ca. 46.53;8.37) geroutet wurde vom 1. roten Punkt zum 2. roten Punkt und dann sollte zum 3 . roten Punkt geroutet werden, aber dann kommt die Blaue Nebenlinie ohne roten Endpunkt…
Ich habe den “shortest.brf” genommen und die Routingdateien sind neu.
Wie schon beschrieben die http://www.wanderreitkarte.de/ routet das problemlos. Die Kartenbasis (OSM) müßte doch gleich sein, oder?.
ich habe das geändert:
zeile 23: switch or access=private acces=no geändert: switch or access=private
zeile 65: switch or access=private acces=no geändert: switch or access=private
dan kommt aber ein Fehler:
Exception in thread “AWT-EventQueue-0” java.lang.IllegalArgumentException: ParseException at line 30: assign operator within expression
at btools.expressions.BExpressionContext.parseFile(BExpressionContext.java:470)
at btools.router.RoutingEngine.(RoutingEngine.java:78)
at womisa.brouter.BRouter.findROUTE(BRouter.java:25)
at org.mapsforge.map.swing.controller.MouseEventListener.mouseClicked(MouseEventListener.java:119)
at java.awt.Component.processMouseEvent(Component.java:6508)
at java.awt.Component.processEvent(Component.java:6270)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4501)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
at java.awt.Container.dispatchEventImpl(Container.java:2273)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:708)
at java.awt.EventQueue$4.run(EventQueue.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Na, ich wollte meine Original-Version nicht deinstallieren. Die ist mittlerweile bei Version 1.6.5 und dein
Binary wäre ein Downgrade auf 1.6.1. Dazwischen hat sich laut Release-Notes das Format der Kartendateien geändert.
Die kommen jetzt auch von einem neuen Server (hatte ich schon bei mir aufgespielt): http://new.osmand.net/list.php
Die Java-Version läuft auf meinem billigen Samsung-Smartphone (lahme CPU, wenig RAM) extrem langsam.
Mit den native Libs (C++) ist das erträglicher. Der Kartenaufbau könnte natürlich flotter sein, aber es sind
eben auch viele Objekte drin (Detailmodus ist aktiviert). Einmal hatte ich aus Versehen die Java-Version drauf,
da wegen Speichermangel die “Link to SD-Card” Funktion fehlerhaft war, OsmAnd dann die native Libraries
wohl nicht finden konnte. Mein interner Flash-Speicher ist nur 150 MB. Darum muss ich alles auf eine
ausgelagerte Partition der 32 GB µSD-Karte verlinken.
Also Brouter benimmt sich dann genauso wie der Interne Router? Der merkt relativ schnell, wenn ich der Route nicht folge,
und berechnet dann ohne Nachfrage oder Benutzerinteraktion gleich die neue Route.
Soll das denn wirklich ein OsmAnd-Plugin werden? Die stehen unter “Zusatzmodule”.
Dein Download ist ja kein Plugin, sondern eine gepatchte Version von OsmAnd selbst.
Der Unterschied beim Plugin wäre, dass man immer die Updates der Originalversion bekommt,
auch wenn sich das BRouter-Plugin nicht geändert hat.
Ich suche schon länger eine Offline-OSM-Karte, z.B. für den Laptop, wenn man mal kein Netz hat.
Am liebsten hätte ich den OsmAnd auf dem Laptop, aber das geht bisher nur umständlich in einer Android VirtualBox.
Eben mit den Funktionen, nach POI auf der Karte zu suchen oder Routen berechnen zu lassen.
Kann man mit dem Mapsforge Viewer auch nach POI suchen? Die Kombination ist sehr praktisch
(“kürzester Weg zur nächsten Pizzeria” oder so).
das ist aus verschiedenen Tools mit “heißer Nadel” und nicht all zu vielen Java Kenntnissen zusammengestrickt. Suchen nach POIS lokal wüßte ich derzeit nicht wie man das machen sollte…?
Nehme da aber gerne Anregungen entgegen.
Das GANZE ist noch sehr BUGGY und bei der Bedienung nicht stabil genug für “Jedermann” und die “Inbetriebnahme” an Randbedingungen wie Karten, RenderThemes, Routingfile etc. geknüpt, deshalb möchte ich das nicht publizieren. Außerdem weiß ich nicht wie das mit den Urheberechten von Mapsforge, BRouter, GPXCreator ist.
Mein Beitrag dabei ist kein Geheimnis. Ich bin aber selbst erstaunt, wie man mit Klick,Klick,Klick eine Route auf eine Vektorkarte via BRouter (Mapsforge,Openandromap, Freizeitkarte) erstellen kann.
Gedacht ist das für meine Routenplanungen auf dem Desktop um dies dann auf das Smartphone zu übertragen. Ich verwende derzeit Oruxmaps.
Ok. Verstehe ich. Kannst du denn andere Offline OSM-Kartenprogramme empfehlen?
Ich suche schon länger nach einer Alternative zu Google Earth auf OSM-Basis,
zum schnellen Anschauen der Karte (Earth ist bei mir viel flotter und flüssiger als WWW-basierte Apps),
und zum Annotieren (drübermalen von Polygonen, Tracks, Fähnchen, Textkommentar, Flächen markieren,
Austausch der Overlay-Objekte via KML-Datei, etc.).
“Marble” sieht auf dem ersten Blick ganz gut aus, läuft aber nicht mit den Vektorkarten
und hat keine Annotierungsmöglichkeit.
…NEIN! Deshalb habe ich mich auf den Weg gemacht auf dem Desktop ein Tool zu schaffen, mit dem ich meine Mapsforge basierenden Vektorkarten anschauen kann. Dazu war das Mapsforge Rewrite mit dem Desktop SwingMapViewer eine Steilvorlage und ein Grund zum Einstieg in diese Thematik.
Weiterhin kam hinzu, dass der BRouter leicht zu integrieren war. Somit habe ich eine vertraute Umgebung für meine Android / Oruxmaps Karten/ und BRouterwelt auf dem Desktop. Somit habe ich auch auf dem Desktop einen “grafische” Routenerstellungsmöglichkeit, ohne Onlineverbindung. Karten und Routen sind 1:1 austauschbar.
Wenn sich das Ganze stabilisiert hat kann man eventuell auch über eine Weitergabe auch nachdenken…aber dazu bedarf es einer vernünftigen Doku bzw. Infoseite und das machen Entwickler sehr ungern.
Ps.: Nebenbei eine Frage an NOP.:
Ich weiß ich soll einen eigenen Thread aufmachen, aber weiter oben habt Ihr weit ab vom Thema diskutiert…
Welcher Router steckt hinter der “wanderreitkarte” und wo könnte man Infos für eine lokale Integration und Konfiguration finden?
Es ist eine Schwäche im Wegpunkt-Matching von BRouter. Ich durchsuche für den Match (=nächste Entfernung zu einem in diesem Profil routbaren Weg) nur in 4 1/80-Grad Kacheln, also einem Gebiet von ca 2,5km*2,5km. Ein solcher Wanderweg, der kilometerweit keine Verzweigung hat, kann mir dabei entgehen. Ich werde das nochmal verbessern, also z.B. das Suchgebiet vergrössern, wenn der Match so weit danebenliegt oder lange Wegabschnitte unterteilen. Danke für den Hinweis.
Das “or” hätte noch weg gemusst, sonst ist die Hirarchie des Ausdrucks kaputt. Aber wie gesagt, access=no ist hier ja nicht das Problem.
Ja zu schnell, wie ich finde, die Schwelle liegt bei 30m. Ja, die Funktion ist fast völlig identisch, nur dass BRouter keine Strassennamen liefert (also wenn Du Strassennamen hörst, hast Du den falschen Router eingestellt…) und bei Langstrecken ist das Verhalten anders: BRouter hat einen Timeout von 60 Sekunden, OsmAnd-Intern hat keinen Timeout, verschluckt sich aber irgenwann am Memory-Limit. BRouter kann aber “timeout-freie” Neuberchnungen, wenn zu dem selben Zielpunkt schon eine Route berechnet wurde, und diese Vorberechnung kann man alternativ auch über die BRouter-App machen, so dass man auch Langstrecken mit automatischen Neuberchnungen über OsmAnd (oder Locus…) abfahren kann.
Nein, OsmAnds Plugins sind ja nur eine Mogelpackung, mit modularer Software hat das nichts tu tun. Ich hab’ den Patch als Pull-Request in Guthub eingestellt und erwarte eigentlich, dass Victor ihn “merged”, und dann ist es ganz normaler Bestandteil der Releases.
in diesem Zusammenhang ein Vorschlag für zukünftige Versionen?
Sollte der gefundene Routen-Endpunkt xxx m vom vorgegebenen Zielpunkt oder yyy m Höhe entfernt sein wird die gefunden Route verworfen. Im Extremfall “keine” Route gefunden.
Möglichkeit der Vorgabe der Maximalen Alternative Routen und der Router gibt die Anzahl der gefundenen Routen (tmp Files) zurück.
Das ist im Falle von Bergwanderrouten wichtig: Worst Case…Es führt genau 1 Weg zum Gipfel, aber es wird ein Routenendpunkt 500m entfernt aber 1000m tiefer gefunden…
Ok. Prima. Dann wird das sicher bald meine bevorzugte Routing-Engine. Meistens, so wie heute, benutze ich OsmAnd nur informativ als Karte und als GPS-Logger. Wahrscheinlich komme ich erst wieder im Frühjahr zu längeren Touren in unbekannte Gebiete. Im Winter fahre ich nicht gerne. Bis dahin ist BRouter dann hoffentlich schon in der Release-Version von OsmAnd drin. Meinst du das funktioniert mit Victors Plänen zur C+±Umstellung? Ich kann mir nicht vorstellen, dass die App komplett nach C++ umgestellt wird. Geht das überhaupt bei Android? Ich dachte die App-APIs sind in erster Linie in Java ausgelegt und C++ hat dann im Prinzip nur die Linux-Betriebssystem-APIs zur Verfügung. Ich sehe den Mix verschiedener Programmiersprachen nicht so kritisch. Bei mir nutze ich oft mathematischen Code aus Fortran, der über DLLs angebunden wird. Fast alle Supercomputer machen das so für HPC. Bei klar definierten Schnittstellen und unabhängigen Modulen ist das kein Problem. Auch der Mix von Python und C++ ist sehr beliebt in der OpenSource-Welt.
Also hatte ich das vorher richtig eingeschätzt, dass das Memory-Limit die größte Einschränkung beim Routing ist, oder? Mein Billig-Samsung hat nur ca. 150 MB RAM. Das ist nicht viel.
Dass du dein Wegenetz konsequent auf Routing-Performance optimiert hast ist verständlich. Aber ist das so stark reduziert, dass du keine Referenz (ID, Index, Pointer) mehr zur OsmAnd-Vektorkarte herstellen kannst? Da stehen die Straßennamen schon drin.
Ok, so hatte ich das auch ursprünglich verstanden. Dann muss ich wohl auf die nächste Release warten.
Aber was ist das Problem mit den Plugins aka “Zusatzmodule” ? Die werden im Android-Market separat zum Download angeboten (Parking-Plugin, STRM-Plugin etc.) Oder sind die alle schon im Hauptprogramm vorhanden, werden quasi durch den Extra-Download nur freigeschaltet? Ein modulares Plugin-Konzept ist natürlich schwieriger zu realisieren. Ein Routing-Plugin würde Zugriff auf interne Datenstrukturen benötigen, z.B. auf die Kartendaten, die in OsmAnd geladen werden.
Man kann Java natürlich auch normal zum Maschinencode statt Bytecode compilieren. In GCJ gibt es das schon länger (wohl nicht so gut optimiert). Google will das jetzt auch für Android umsetzen. Maschinencode ist einfach vom Prinzip her schneller als Bytecode. Bytecode ist für ARM und x86 immer ein Fremdkörper, der in virtuellen Maschinen emuliert werden oder übersetzt werden muss. Nur spezielle Java-Prozessoren können den ausführen. Bytecode hat sicherlich Vorteile, ist aber nie performance-optimal.
Verschiedene Sprachen geben aber verschiedene Möglichkeiten, einen Algorithmus zu optimieren. Java und Python leiden darunter, dass man die Speicherbytes durch Pointer nicht so gut unter Kontrolle hat. Das wird der ART-Compiler von Google auch nicht lösen können. Das ist sprachinhärent.
Es kann durchaus sein, dass es für das Routing-Problem keine so große Rolle spielt, denn die Speicherverwaltung im dynamischen Routing-Graphen würde man vermutlich auch in C++ nicht manuell übernehmen.
Einen Unterschied gibt es auch bei den Datentypen. Bei Java wird immer eine virtual table für Objekte benötigt (richtig?). Wenn massenweise Datenobjekte verwaltet werden (z.B. in Vektoren und Matrizen), ist das deutlich weniger effizient als C+±Objekte ohne virtual tables.
oh ja, passiert immer dann, wenn start- und endpunkt auf dem gleichen wegabschnitt liegen, da findet er den zielpunkt nicht und durchsucht dann den rest der welt. Danke für den Hinsweis.
War noch nie ganz richtig an der Stelle, nur bisher war es so, dass dann der Zielpunkt falsch gemappt wurde (auf die nächste Kreuzung, nur irgendwann (wird wohl die 0.95 gewesen sein) hab’ ich’s dann wohl verschlimmbessert.
Wird wohl Zeit für die 0.97… muss nur erst paar andere, langweilige Dinge (wie Steuererklärung…) vom Tisch kriegen bevor ich mich wieder rein vertiefen kann.
