BRouter: offline Fahrrad-Routing für Android

Vielleicht finden sich ein paar Leute zusammen? Ich könnte mir gut vorstellen daran mitzuarbeiten, habe aber sicher nicht für alles die nötigen Fähigkeiten. Und Arnd kann inzwischen weiter in Ruhe den Offline-Android-Router optimieren… (da warte ich nämlich auch drauf).

Besten Dank für die neue Version 0.9.2! In der Zwischenzeit konnte ich nochmal einen OsmAnd Source Build mit BRouter-Anbindung bauen und bin begeistert: der Fehler der Version 0.9.1 tritt nicht mehr auf. Aktuell teste ich verschiedene Szenarien durch, um hoffentlich ein qualifizierteres Feedback geben zu können.

Die aktuelle Anbindung läuft wie schon zuvor beschrieben. Allerdings scheint die Auswahlmöglichkeit zwischen Auto, Fahrrad und Fußgänger kein Unterschied zu machen, maßgeblich ist wohl nur, was beim Start des BRouter ausgewählt wird. Vielleicht würde sich da eine Konfigurationsoption anbieten, die verschiedene “externe” Profile auf BRouter-interne Profile matched. Das hängt aber alles sehr davon ab, in welche Richtung sich das Interface zu OsmAnd zukünftig entwickeln wird.

Auch dafür besten Dank, der Link ist angekommen. Für meine Tests habe ich erstmal mit der fertig kompilierten .apk Version gearbeitet, bevor ich mich in die Quellen einarbeite.

An einem komfortablen webbasierten Client wäre ich schon sehr interessiert, da ich lieber am großen Bildschirm plane und momentan auch noch nen Garmin nutze.

Ich hätte auch Lust, das zu entwickeln, hab aber eigentlich schon zu viele Sachen angefangen und bin momentan noch an was anderem dran. Von daher fände ich es toll, wenn wir das zusammen als Community-Projekt angehen könnten.

Wenn der Server der Online-Demo nicht für intensivere Nutzung geeignet ist, könnte man sich auch nach Alternativen umsehen. Persönlich hätte ich auch kein Problem damit, den BRouter erst mal als Java-Applikation herunterzuladen und analog zur Android-apk über eine HTTP-Schnittstelle lokal im Browser anzusprechen. Vorausgesetzt, dass eine solche Variante ohne allzu großen Aufwand machbar ist, das könnte ja auch jemand übernehmen.

Erst hatte ich die Idee, einen vorhandenen Routing-Client anzupassen, aber so einfach sah mir das beim Project-OSRM-Web gar nicht aus, zudem ist mir dort die GPL Lizenz zu restriktiv. Das Routing bei XC Trails sieht noch ganz nett aus, scheint aber nicht Open Source zu sein. Weitere hab ich noch nicht angeschaut.

Ich konnte es trotzdem nicht lassen und hab das mal mit Leaflet und den draw und GPX Plugins angetestet und vorübergehend als Beispiel hochgeladen.

Folgende Features würde ich mir wünschen:

Wer hätte sonst noch Lust mitzumachen? Möchte das jemand in die Hand nehmen?

Gruß,
Norbert

Edit: Leaflet.Elevation, Plugin Links

Hallo

grundsätzlich hätte ich da auch Interesse was beizutragen, aber dazu fehlt mir auch das nötige Hintergrundwissen. Ich habe etwas Erfahrung in der
.NET Programmentwicklung .Ich habe da mal vor langer Zeit einen primitiven Kartenviewer geschrieben. Dieser verarbeitet aber auschließlich Tile-Karten und KEINE Vektorkarten ==> C /C# Lösung sehr aufwendig

Ich würde jedoch eine rein lokale Lösung anstreben die ohne Webserver (HTTP) läuft. Eventuell könnte man sowas in GPSPrune (HMI /Java) integrieren/verheiraten. Es kommt auf die Schnittstelle zum Brouter an. ==> reine Javalösung?

Eine Interessante alternative wäre die Integration/ Verheiratung mit Oruxmaps. Hatte ich mal weiter oben angefragt, aber leider keine Antwort bekommen. Das könnte man dann in der Virtuellen Box mit Andorid unter Windows betreiben. Der Weg ist hier beschrieben http://www.openandromaps.org/ Der Vorteil wäre die Kompatibilität zu Android. Habe ich aber noch nicht probiert. ==> Andoidlösung mit Standard Programmen

Frage:
In welcher Spache und Entwicklungsumgebung ist der Brouter geschrieben?
Wie sieht eine Schnittstelle zum BRouter aus?

Viele Grüsse
Achim

Ich finde das so schon eine riesige Verbesserung zum aktuellen Frontend des Online-Routers (und viele der auch aus meiner Sicht wünschenswerten Zusatzfeatures eher Nice to Have, weil es sie ja aktuell auch nicht gibt). Wieso meint ihr (insbesondere womisa), das müsste offline funktionieren? Es ging doch gerade um ein Web-Frontend für den Online-Router?

Ich weiß jetzt allerdings noch weniger, ob ich wirklich Sinnvolles beitragen kann. Ich hätte mir das Leaflet-Beispiel ganz sicher nicht aus dem Ärmel geschüttelt. Aber irgendwas gibt’s ja meistens auch für Doofe zu tun.

Ja cool. Finde, das ist so schon ein nettes Spielzeug. Da noch Profilauswahl, Höhendiagramm und GPX-Download und das ist brauchbar.

Die Sperrgebiete sind ein unique-feature, was die anderen nicht können (sie können es prinzipiell nicht, weil sie shurtcuts vorberechnet haben und deswegen keine individuellen Routing-Kriterien berücksichtigen können. Wäre also auch noch schön, Sperr-Kreise (Position und Radius) setzen zu können und die als Kreis zu visualisieren.

Es ist ein Strato V-Server level 2 mit Ubuntu 10 32 bit und der läuft schon nicht schlecht (zwar nur 2 GB garantiert aber faktisch doch immer 4). Von den 100 GB Plattenplatz brauche ich aber einen Grossteil für den Präprozessor, so dass da faktisch nur ca 10-20 GB übrig sind, und der läuft einmal im Monat und braucht dann 3 GB Hauptspeicher. Also ein Serverprozess sollte sich mit 1/2 GB Hauptspeicher begnügen, sonst kann der Präprozessor nicht mehr parallel laufen.

Ich hab’ mal das “Server-Jar” und zusaetzlich den Source-Code der beiden “Aufruf-Klassen” BRouter.java und RouteServer.java als Paket hochgeladen: http://h2096617.stratoserver.net/brouter_bin/brouter092_bundle.zip

Das ist sowohl die Kommandozeilen-Version, als auch das CGI der Online-Demo als auch mein Standalone-Server für die “yournavigation-Simulation”. Sie, und auch die Android-App, benutzen alle die gleiche API zum eigentlichen Router, die letzlich aus den Klassen CycleRoute, RoutingConfig, OsmNodeNamed und OsmTrack besteht. Ist bisschen mässig dokumentiert, aber ich kann die API an der Stelle sauber machen. Dann ist BRouter letzlich eine Java-Bibliothek. Die vollen Sourcen schicke ich Dir gesondert zu.

…ganz einfach. Unabhängig von einer Netwerkverbindung zu sein, wenn man die Karten schon mal lokal geladen hat.
…und um hauptsächlich die Serverbelastung auf ein Minimum zu reduzieren
… nicht geroutete Wegpunktdateien halte ich sowieso lokal und kann diese dann mit verschiedenen Parametern durch den BRouter jagen

Ich habe mal mit dem Webinterface gespielt und das funzt gut. Ist es erlaubt mit dem Server einige Tests durchzuführen?
Ich stelle mir das so vor, ich erstelle mir eine Route mit signifikanten (erwünschten) Wegpunkten und iteriere jeweils mit 2 Wegpunkten durch den BRouter und erstelle so sukzesive meinen gerouteten Track/Route. Das teste ich mal mit einem C#Client in Verbindung mit dem BRrouter Webserver.

Oder geht das einfacher (Viapunkte)?

Was muß ich ALLES haben um unter Windows einen BRouter-Server laufen zu lassen, oder gibts da schon eine EXE oder einen ausführbaren JAR File?

Vielen Dank
Achim

Ist notiert. Kreise sollten kein Problem sein, siehe Leaflet.draw demo, hab ich nur wegkonfiguriert.

Dankeschön!

Ich denke mit der API kommt man schon erst mal klar so. Bei Unklarheiten können wir ja auch fragen.

So wie ich Arndt verstehe ist der Online-Server - zumindest im Moment - nur als Demo gedacht und nicht für den produktiven Betrieb. Wenn ich das richtig sehe, hat der Server folgende Einschränkungen, weil Online halt keine Priorität hat:

  • es kann nur eine Anfrage gleichzeitig verarbeitet werden, bei einer zweiten wird die aktuelle abgeschossen
  • bei jeder Anfrage wird die Java Runtime neu gestartet, das ist schon ein ziemlicher Overhead

Mir geht es daher nicht um Offline, sondern darum die Routing-Engine lokal zu haben, damit ich vor allem während der Entwicklung niemandem in die Quere komme (und umgekehrt) und die Engine ohne schlechtes Gewissen quälen kann :wink:

Um einen richtigen Routing-Server aufzusetzen müsste man noch etwas Arbeit investieren und z.B. einen Java Server (Tomcat) installieren, in dem ein Servlet die Engine ansteuert.

Da gibt es sicher genug Möglichkeiten. Da ich aktuell eigentlich noch an etwas anderem arbeite, wäre eine Idee, die noch fehlenden Sachen aus dem jetzigen Client in das Leaflet Beispiel einzubauen, um erst mal die aktuelle Funktionalität nachzubauen.

Ich bin aber nicht unbedingt auf Leaflet festgelegt, nur möchte ich mit OpenLayers 2 nichts neues mehr anfangen und für OL3 ist es vermutlich noch zu früh :confused:

Das RouteServer.java macht sein eigenes Socket auf und ich möchte das auch so verwenden, dass man damit den BRouter mit integriertem Server startet, also keinen extra Webserver benötigt. Allerdings möchte ich definitiv einen Web-Client im Browser haben, also wird eine lokale Anwendung schon aus zwei Teilen bestehen und für die Kartenanzeige wird man im Normalfall schon eine Online-Verbindung benötigen. Da kommen wir dann vermutlich nicht zusammen.

Ja, das ist rein Java und das jar könnte als Bibliothek direkt in einem anderen Java-Programm integriert werden.

Das mit der VM wäre mir persönlich jetzt zu umständlich.

Da bin ich auch unschlüssig, da ich nicht weiß, wie viel Mehraufwand das für den Router ist. Für den Client wäre es einfacher mit Via-Punkten zu arbeiten, entweder mit einmaliger Berechnung am Schluß, oder mit kompletter Neuberechnung bei jedem Anlegen eines Punktes, was ich schon schön fände. Ich denke, es macht auf jeden Fall Sinn, wenn wir Via-Punkte in die API einbauen.

Was bequemes gibt es noch nicht. Habs noch gar nicht getestet, aber der Kommandozeilen-Aufruf (siehe Command-Line-Mode in readme.txt) müsste so schon gehen (wenn Java Runtime installiert ist). Der CGI-Mode braucht nen Webserver. Den Stand-Alone-Server müsste man von Kommandozeile auch schon starten können, allerdings mit yournavigation-Schnittstelle, die man eher nicht verwenden will.

Falls sich sonst niemand meldet, wäre das vielleicht ein Punkt, den ich als erstes angehen würde: Eine vollständige BRouter HTTP API mit Via-Punkten und Sperrzonen in das RouteServer.java (oder extra) einbauen und ein kleines Script zum Starten.

Das ist ein schwieriges Thema, weil es bei diesem Router ja kein oberes Limit für die Bearbeitungszeit gibt. Und es passiert mit dem neuen, besseren Location-Matching zwar nicht mehr häufig, aber immer noch, dass wegen einer “Zielinsel” keine Route gefunden wird, es aber auch kein Abbruch-Kriterium gibt, und das muss man irgendwann beenden. Ich hatte es zuerst mit Warteschlange und Timeout gemacht, aber das ist unglücklich, weil man mit so einem Timeout ein künstliches Limit schafft für die geroutete Distanz, daher das jetzige Verfahren mit dem Process-Kill. Ich denke, man kann das noch bisschen klüger machen mit z.B. einem Pool von 5 parallelen Berechnungen (und erst die 6. schiesst die älteste ab) und einer Rechenzeit-Priorität für die Kurzläufer.

Bei Via-Punkten macht auch BRouter das Routing für jedes Teilstück einzeln, es gibt da ein bisschen Re-Use beim Location-Matching und kleineren Caches, aber das sollte glaubich die Design-Entscheidung nicht beinflussen, ob über vias im Web-Client oder im BRouter iteriert wird.

Ich hab’ Dir die vollständigen Sourcen jetzt geschickt (an Deine gmx-adresse), ohne ists ein bisschen schwierig, weil die API doch arg verbastelt ist. Zu Sperrgebieten ist in RouteServer.java die Anbindung im Prinzip drin (“nogoList”), aber nicht der Konstruktor dieser Objekte:

  List<OsmNodeNamed> nogoList= new ArrayList<OsmNodeNamed>();
  OsmNodeNamed n = new OsmNodeNamed();
  n.name = "nogo2000";
  n.isNogo = true;
  n.ilon = (int)( ( lon + 180. )*1000000. + 0.5);
  n.ilat = (int)( ( lat + 90. )*1000000. + 0.5);
  nogoList.add( n );

Der Radius steckt also im Namen, und das Koordinatensystem ist das BRouter-Interne. Die Erweiterung um via-Punkte in dem RouteServer.java Beispiel ist trivial, da wird einfach nur die Wegpunktliste länger, also statt from-to dann from-via1-via2-to. Die Beschränkung auf 9 Vias gibts nur in der Android-App (wegen der Namenskonvention), an dieser Stelle in der API ist die Zahl nicht beschränkt und auch die Namen der Wegpunkte sind beliebig.

Hallo

ich habe mal im Routeconverterforum nachgefragt ob eine Integration von BRouter von Interesse wäre. Routconverter hat alles für eine komfortable Routenerstellung /Editiermodus etc. standardmäßig schon drin. RC könnte doch auf dem PC die Rolle von Osmand, Oruxmaps sinngemäß übernehmen. Routeconverter ist auch in Java geschrieben.

Würde das die Zustimung und eventuelle Unterstützung vom BRouterAutor bekommen?

MfG
Achim

Hi Achim,

wenn ich es richtig verstehe, kann Routeconverter (noch?) keine Offline-Karten. Richtig Sinn machen würde das ja dann, wenn man so eine echte offline-Lösung für den Desktop schaffen würde, und da hätte ich auch grosses Interesse dran. Wenn man aber ohnehin den online-Zugang braucht für den Tileserver, dann wird man es den Benutzern nicht vermitteln können, sich mit dem Download der Routing-Datafiles rumzuschlagen.

Alternativ könnte man da aber auch den Router als Online-Dienst einbinden (sie haben wohl schon andere Dienste drin?), das wäre ja mit wenig Aufwand zu machen, und da wären wir ja wieder bei Norberts Vorschlag, zunächst mal eine dokumentierte http-schnittstelle zu schaffen mit der vollen Funktionalität in der API.

Ja, ich würde beides (die offline und die online-Integration) unterstützen, mit Arbeit zurzeit nur begrenzt (muss bisschen kürzer treten bei dem Thema), mit der Lizenz kann man das vielleicht irgendeine Lösung finden, den Router dort zu integrieren ohne BRouter gleich selbst unter GPL-Lizenz stellen zu müssen.

Gruss, Arndt

Hallo Arndt,

vielen Dank für die freundliche Antwort.
Eine andere Idee für eine “offline” Version wäre eventuell noch MOBAC als Oberfläche zu benutzen. Ich habe vor langer Zeit mal angeregt, dass man externe Programme mit Parameter aufrufen kann. Damit hat man zum Beispiel Maperitive mit einer Batchdatei steuern können. Dieses Feature hatte ich zusammen mit dem Autor ausgetestet. Sinngemäß könnte man das mal mit BRouter versuchen.

Mir ist aber noch nicht klar wie bekomme ich unter Windows eine Standolone-Version vom BRouter (Kein Server) zum Laufen und wie ist die Parameterübergabe?
Idee wäre man übergibt eine gpx Datei mit mindestends zwei Punkten und bekommnt eine geroutete GPX Datei mit dem Track zurück bzw. mehrere GPX Dateien mit den alternativen Routen. MOBAC,Maperitive und BRouter könnte auch in Betracht gezogen werden, wobei Maperitive ja mit Scripten programmierbar ist.

Viele Grüsse
Achim

Mal ganz was anderes, ich habe gestern auf dem Rad mal über deine Frickeleien nachgedacht, wie Du die Verbindung zu verschiedenen Apps herstellst. Wäre es auf Dauer nicht einfacher, wenn Du deinem Brouter einen eigenen Kartenviewer und Sprachausgabe spendieren würdest. Letztendlich eine eigenständige Navigationsapp. Die Hauptaufgabe sinnvolle Navigation hast Du ja schon gelöst. Der Rest wäre doch eher leicht zu programmierendes Beiwerk?

Aus purem Zufall bin ich letzten Freitag bei Android-Hilfe über einen Beitrag zu Brouter gestolpert und habe es sofort online ausprobiert: Sehr beeindruckendes Resultat für das von mir gewählte Profil (fastbike o.ä., Rennradfahrer).
Als allerersten möchte ich mich aufs herzlichste dafür bedanken!
Heute habe ich mir dann den ganzen offline-Kram heruntergeladen, in einer virtuellen Box installiert und ein wenig damit herum gespielt, als Offroad Proggies fungierten Locus und Oruxmaps.
Ein paar Punkte, die mir dabei aufgefallen sind, möchte ich nachfolgend aufführen.

  1. Ich habe hauptsächlich das Rennrad? Profil gewählt, es hat für mich! erstklassige Vorschläge gelistet, teilw. wirklich excellent.
    Gut asphaltierte Nebenstraßen mit ordentlichen Steigungen (> 10%) waren genauso mit von der Partie wie die stark befahrene Bundesstraßen. Leider sind letztere nicht immer die erste Wahl bei meinen Gesinnungsgenossen aus diversen Radsportvereinen, die meisten versuchen diese zu meiden, insbesondere dann, wenn es weniger verkehrbelastete Alternativen gibt. In diesem Zusammenhang ist mir aufgefallen, dass manchmal auch dann eine mehrfach ampelverstellte Hauptverkehrsstraße gewählt wird obwohl eine lupenreine und sogar kürzere Radwegalternative vorhanden ist.
    Im Extremfall meidet Brouter sogar “Radwege” wie der Teufel das Weihwasser.
    Beispiel ist eine Route von Dormagen/Zons über den Rhein Richtung Wuppertal. Nur mit Start- und Zielkoordinaten versorg wird ohne Zögern die Fähre bei Zons genommen. Für Jugendliche duraus romantisch nehmen die meisten RRler doch wohl eher eine Rheinbrücke. Nachdem die Fähre gesperrt wird findet der Router nur zwei große Umwege, entweder über die A1 bei Köln/Leverkusen oder die Düsseldorfer Südbrücke, beides befahrbare Radwege. die naheliegende Strecke über die Fleher Brücke (A46) mit ihren erstklassigen Radwegen bleibt außen vor. Werden Wegpunkte direkt auf die Brücke gesetzt passiert folgendes: die der linksrheinischen Brückenauffahrt am nächsten liegenden werden zunächst angefahren, dann heißt es wenden und im großen Bogen an der Neusser Galopprennbahn vorbei über die Südbrücke hin zur Fleher, dann die rechstrheinische Auffahrt hoch und die dieser Auffahrt näher gelegenen Punkte einsammeln, wenden, die Auffahrt wieder runter und den Weg fortsetzten.
    Im Modus “tracking” wird die Brücke benutzt, dann aber die holprigere Nordseite, wahrscheinlich wegen der flacheren Auffahrt, die von RRlern bevorzugte “knackigere” und babypoasphaltierte Südseite kommt erst beim Profil “shortest” zum Zug.

  2. Das Profil “shortest” routet ohne Rücksicht auf Verluste, d.h. auch über wenig genutzte weil verwinkelte Brücken, d.h. enge und steile Treppen bzw. Drahtkäfige, wo man sein Rad aus Platzmangel kaum hochtragen kann bzw. senkrecht vor sich her bugsieren muss.

Beim gestrigen Querlesen habe ich irgendwo etwas von einem “Kostenfaktor” gelesen, eine Eingabemöglichkeit dafür habe ich nicht gefunden.
Weiterhin habe ich ebenfalls gelesen, dass Brouter wohl urspünglich für die Cooperation mit OSMAND ausgelegt wurde. Ich konnte aber heute feststellen, dass es, wenn auch “etwas umständlich”, “Routinganforderungen” sowohl von Locus als auch von Oruxmaps erkennt und die Ergebnisse in deren Verzeichnisstruktur bereitstellt. Da nun diese beiden Programme Vektormaps Marke “mapsforge” sollte es doch spätestens mit der nächsten Version 0.4. möglich sein, diese fürs Routen zu nutzen.

…ist diese Aussage Ernst gemeint?

Hast du mal die entsprechenden Kartenprogramme zeitlich verfolgt wie lange das gebraucht hat bis diese in ihrer jetzigen Form stabil waren (OruxMaps, OsmAnd,Mapsforge, Locus etc.). Es ist ja nicht “nur” die Kartenanzeige sondern auch die Track/Routen Verwaltung/Anzeige und das navigieren auf einer vorgegebenen Route. Das ist glaube ich schon ein wenig Zeitaufwändig, oder?
Es geht doch auch um eine Lösung die auf dem PC (großer Bilschirm läuft). Da gilt für die entsprechenden Kartenprogramme das Gleiche (GpsPrune, Routeconverter, etc.)

In diesem Sinne
Achim

Naja, bisschen mehr Respekt vor der Leistung dieser Kartenprogramme hab ich schon, und mein Router ist ein 1-Mann Hobbyprojekt…

Ich verfolge ja eine andere Strategie um die “Frickeleien” zu überwinden, über eine standartisierte Router/Maptool Schnittstelle. So ein bisschen funktioniert das ja schon mit OsmAnd mit dem Hack mit dem Android-Lokalen HTTP-Server, der einen Yournavigation-Server simuliert, und wenn’s irgenwann mal wieder schlechteres Wetter gibt, komm ich da hoffentlich auch weiter.

In “meiner” Höhenpräferenz werden zwar flache Abfahrten bevorzugt, bei den Anstiegen gibt es keine Präferenz, so dass da gerne auch mal steile Anstiege gewählt werden. Viele Leute mögen das nicht und kann man aber ändern.

Ja das fastbike-Profil ist bisschen ein “stiefkind”, weil es nicht so viel benutzt wird und da steckt auch nicht so viel Tuning drin. Ich selbst mache aber zur Zeit viele “schnelle Ebike Touren”, was bisschen vergleichbar ist zum Rennrad, und bastel an einem Profil ähnlich fastbike, was aber auch Radwege un Ampeln kennt.

Das ist ganz klar ein Fehler, und Du kannst Dir aussuchen, ob der Fehler im OSM-Tagging steckt oder im fastbike-Profil. Die A46-Brücke hat “highway=path, bicycle=designated” und das hat im fastbike-Profil Kostenfaktor 10, also so gut wie verboten. Das trekking-Profil hingegen erkennt das “bicycle=designated” und bewertet den Weg besser. Da fehlt einfach ein tracktype=grade1 oder surface=paved, oder highway=cycleway, irgendwas halt, was den Weg aufwertet.

shortest ist auch nicht zum Radfahren gedacht, es ist einfach der Kürzeste Weg, den man zu Fuss passieren kann.

Die Profile enthalten die Kostenfaktoren, wenn Du da mal reinschaust siehst Du ganz viele Zahlen und die meisten davon sind Kostenfaktoren. Und die Fähre wurde auch nicht einfach so genommen, sondern mit 10000m Zusatzkosten, also die nimmt er nur, weil die Brücke so weit weg ist. Und diese Zahlen kann man alle ändern. In der Online-Version gibts dafür einen “Upload” Button, auf dem Handy muss man das mit einem Texteditor machen.

Den Gedanken hatte ich auch schon, statt meiner eigenen “routing-data-files” einfach die open-andro-maps zu nehmen, aber ich habe mir das Format bisher nicht näher angeschaut, meine eigenen Dateien sind halt von der Daten-Vorverarbeitung und der Index-Struktur schon ziemlich spezifisch für schnellen Zugriff fürs Routing gemacht.

Hallo Arndt,

Ich könnte mir schon vorstellen die Tags die Du brauchst in die OpenAndroMaps einzubauen, oder auch deine Routingfiles so wie sie jetzt sind passend zu meinen Karten zu generieren.
Ich könnte ja mal eine Testkarte generieren, was ich bräuchte sind informationen über die erforderlichen Tags und was Du sonst noch benötigst und einen Permalink für den gewünschten Ausschnitt.

Wobei, vom Standpunkt der allgemeinen Verwendbarkeit ist Deine Lösung mit den eigenen Routingfiles sicher besser da es damit egal ist ob jemand die Freizeitkarte oder die Openandromaps oder die internen Locus-Karten verwendet. Ausserdem ist der User (und auch Du) damit unabhängig von Versionswechseln und Bugs in Mapsforge (da gibt es ganz Fiese) ausserdem nimmt Mapsforge immer das gesammte Objekt (Way/Poi) mit in die Karte auf wenn auch nur ein Tag gematched wird was bedeutet, das wenn ein way eine Routinginformation enthält, der ganze way mit allen Tags schon bei sehr niedrigen Zoom_leveln (die Du sicher fürs Routing ab Zoom Level 1 brauchst) komplett in die Karte aufgenommen wird - was sicher Probleme verursacht. … Müsste man ausprobieren.

Beste Grüsse
Christian
www.openandromaps.org