OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#26 2013-01-17 21:30:36

badger123
Member
Registered: 2010-06-05
Posts: 91

Re: BRouter: offline Fahrrad-Routing für Android

EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Wenn man so etwas einbaut sollte dies deutlich hervorgehoben werden bzw. schon gleich am Anfang drauf hinweisen das es solche Teilstücke gibt. Wenn man mit Gepäck und/oder Anhänger unterwegs ist dann sind Treppen auch nicht mit 2km/h zu bewältigen.

Offline

#27 2013-01-17 21:40:18

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 8,752

Re: BRouter: offline Fahrrad-Routing für Android

Wieso routet mich der router über den Weg

Welchen Router Du auch immer meinst. Wenn er über access=no routet ist er defekt.

Last edited by chris66 (2013-01-17 21:40:55)


Internettechnik aus Nordkorea: Demnächst auch in der EU.

Online

#28 2013-01-17 22:48:59

schiki
Member
Registered: 2012-12-07
Posts: 95

Re: BRouter: offline Fahrrad-Routing für Android

Hallo Holger,

Access=no genauso wie vehicle=no wird zur Zeit vom BRouter nicht ausgewertet, siehe auch https://groups.google.com/forum/#!topic … Z3HK64AMgA

Gruß Schiki


Gruß aus Rheinhessen

Offline

#29 2013-01-17 23:00:19

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: BRouter: offline Fahrrad-Routing für Android

badger123 wrote:
EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Wenn man so etwas einbaut sollte dies deutlich hervorgehoben werden bzw. schon gleich am Anfang drauf hinweisen das es solche Teilstücke gibt. Wenn man mit Gepäck und/oder Anhänger unterwegs ist dann sind Treppen auch nicht mit 2km/h zu bewältigen.

Ich schrieb nicht umsonst "als Alternative". Jeder kann dann selbst entscheiden, ob das für ihn/sie machbar ist. Die 'alte Oma' wird diese 'Alternative' ggfs. auch nicht nutzen wollen.

Darüber hinaus sollten solche rechtlich oder physisch problematischen Stellen per Einstellung von Vermeidungen ausgeschlossen werden können.

Edbert (EvanE)

Offline

#30 2013-01-18 00:17:42

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: BRouter: offline Fahrrad-Routing für Android

Nahmd,

EvanE wrote:

Darüber hinaus sollten solche rechtlich oder physisch problematischen Stellen per Einstellung von Vermeidungen ausgeschlossen werden können.

.oO( zum Beispiel sac_scale=demanding_mountain_hiking )

Gruß Wolf

Last edited by Netzwolf (2013-01-18 00:19:58)

Offline

#31 2013-01-19 14:08:23

abrensch
Member
Registered: 2013-01-07
Posts: 405

Re: BRouter: offline Fahrrad-Routing für Android

chris66 wrote:

Welchen Router Du auch immer meinst. Wenn er über access=no routet ist er defekt.

Ganz so einfach ist es nicht. access=no definiert ja nur den default-acess, der dann von bicycle=... oder foot=... wieder überschrieben werden kann.

schiki wrote:

Access=no genauso wie vehicle=no wird zur Zeit vom BRouter nicht ausgewertet, siehe auch https://groups.google.com/forum/#!topic … Z3HK64AMgA

Ich habe jetzt zwei Anpassungen gemacht (in allen Profilen ausser "shortest):

1) zum Problem access=no und HolgerJeromin's Beispiel in Hilden

  switch and access=unknown
             and or bicycle= bicycle=no
                 or highway=track or highway=road or highway=path or highway=footway highway=service
         100000

Tatsächlich ist access=no nicht in der atuellen lookup.dat, also musste ich access=unknown benutzen (=alles, was nicht leer ist und und in lookup.dat aufgeführt). Durch jedes "bicycle" tag ausser "no" wird es wieder aufgehoben. Ausserdem musste ich den Filter auf den highway-typ ergaenzen, sonst hatte ich beispiele in meiner Testsuite mit highway=residential, access=designated, die auch den Ausschluss getriggert haben.

Das in der google-group genannte Beispiel an der Kaiserbrücke in Mainz lässt sich damit aber nicht erschlagen, weil hier nur die access=no und barrier=gate tags an den Nodes stehen und nicht am way, und node-tags kann brouter noch nicht.

2) zum Problem cycleway=opposite*

Habe ich ergaenzt in der oneway-berechnung als:

       switch or cycleway=opposite cycleway=opposite_lane 0

(=keine oneway-strafe für diese beiden werte) cycleway=opposite_track fehlt leider auch in lookups.dat, aber so viele sind das nicht.

Sobald ich die Beschränkung für die Menge von Tags in den routing-data-files nicht mehr habe, kann man das sicher noch besser machen.

EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem
Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Gruss, Arndt

Last edited by abrensch (2013-01-19 14:09:52)

Online

#32 2013-01-19 14:50:26

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:
EvanE wrote:

Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem
Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Hallo Arndt

Sehr schön, kommt mir aber sehr viel vor. Muss man aber vielleicht vom Typ des Radfahrers abhängig machen. Ein MTBler käme wahrscheinlich mit Kostenfaktor=20 klar. Beim Rennrad weiß ich es nicht so genau. Einerseits wollen die schnell sein und ihr Rad ist eher leicht, anderseits steigen die ungern ab.

Wie sieht es mit einem Profil für Räder mit Anhänger aus? Das hat auf meinen Treppenvorschlag hin jemand als Einwand gebracht. Anhänger unterliegen ja besondere Einschränkungen / Notwendigkeiten (Mindestbreite, Gewicht, sperrig, ...).

Um klar zu machen, um was es mir geht, hier ein Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende hübsche Route. Da die vorgeschlagene Route vor Ort nicht direkt erkennbar ist, nehmen viele, die zum Weg entlang der Sieg wollen, halt die Treppe.

Edbert (EvanE)

Offline

#33 2013-01-19 16:05:54

maxbe
Member
Registered: 2010-01-19
Posts: 2,953
Website

Re: BRouter: offline Fahrrad-Routing für Android

Mal ne Zwischenfrage zu meinem besseren Verständnis: "Kostenfaktor=1" heisst bei Euch "man kann da mit 20 km/h fahren"? Welchem key bei OSM entspricht das?
Grüße, Max

Offline

#34 2013-01-19 16:40:38

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: BRouter: offline Fahrrad-Routing für Android

maxbe wrote:

Mal ne Zwischenfrage zu meinem besseren Verständnis: "Kostenfaktor=1" heisst bei Euch "man kann da mit 20 km/h fahren"? Welchem key bei OSM entspricht das?

Hallo Max

Ich denke man kann mit der einem eigenen Geschwindigkeit fahren ohne weitere Beschränkungen. Das kann in deinem Fall 10  / 15 / 20 / 25 / 30 oder 35 km/h sein. Ein besonderes Tag braucht es dafür wohl kaum.

Die Menschen und ihre Fahrräder sind verschieden, was zu sehr unterschiedlichen Durchschnittswerten auf gerader, ebener Strecke führt. Oder wie sagte ein Bekannter, der täglich 12 km zur Arbeit und wieder zurück fährt:
   30 km/h ist doch gemütliches Einrollen (auf einem Rennrad in der Gruppe).
Ich selbst bin froh, wenn ich (allein) auf ebener Strecke mit meinem Rad zwischen 20 und 25 km/h schaffe.

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. Daneben fließt der Kostenfaktor wahrscheinlich in die Berechnung der Zeit für die Route ein. Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

Nur meine Vermutungen
Edbert (EvanE)

Offline

#35 2013-01-19 17:36:24

abrensch
Member
Registered: 2013-01-07
Posts: 405

Re: BRouter: offline Fahrrad-Routing für Android

EvanE wrote:
abrensch wrote:

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Sehr schön, kommt mir aber sehr viel vor. ... Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende ... hübsche Route

Mit Faktor 40 für Treppen macht BRouter auch den langen Looping, bis 30 hätte er die Treppe genommen. Man kann sowas in der Online Version selber ausprobieren, indem man über den Upload-Button ein modifiziertes Profil hochlädt (was dann als "custom" in der Auswahlbox steht)

EvanE wrote:

Wie sieht es mit einem Profil für Räder mit Anhänger aus? Das hat auf meinen Treppenvorschlag hin jemand als Einwand gebracht. Anhänger unterliegen ja besondere Einschränkungen / Notwendigkeiten (Mindestbreite, Gewicht, sperrig, ...).

Ich hatte den Fall noch nicht, aber ich würde, ausgehend from trekking-profil, Fusswege und Treppen konsequenter vermeiden.

EvanE wrote:

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. Daneben fließt der Kostenfaktor wahrscheinlich in die Berechnung der Zeit für die Route ein. Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

Ja genau, nur dass BRouter keine Zeiten ausrechnet.

Der Router sucht den Weg mit den geringsten "Kosten", was aber ein rein abstraktes Konzept ist. Die Kosten werden zwar in Metern gezählt, meinen aber was anderes als die Länge der Route.

Der Hauptteil der Kostenfunktion ist dieser entfernungsabhängige Teil, also immer Wegstrecke mal Kostenfaktor, und das über alle Wegstücke aufsummiert. Es gibt aber noch zwei andere Teile in der Kostenfunktion, dass eine sind die Winkelkosten ("turncost")  und das andere die Höhenkosten ("elevationcost").

Gerade am Beispiel der "turncost" wird deutlich, dass das Konzept tatsächlich abstrakt ist. Er rechnet für eine 90-Grad Ecke Zusatzkosten von 90m. Das wäre aus der Sicht einer Zeitbetrachtung ja viel zu viel (man braucht keine 16 Sekunden zusätzlich, um um eine Ecke zu fahren). Man muss das eher als Filter verstehen, der verwinkelte Wege vermeidet, weil in verwinkelten Wegen mehr böse Überraschungen stecken als in geraden.

Der Kostenfaktor muss möglichst nahe bei 1 sein für die Art von Wegen, die man sucht, weil sonst durch die Art der Berechnungsmethode das "Suchgebiet" zu gross wird und die Berchnung dann zu lange dauert. Und er darf nicht kleiner als 1 sein, weil sonst die Berechnung nicht mehr funktioniert.

Online

#36 2013-01-19 22:51:05

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:
EvanE wrote:

Sehr schön, kommt mir aber sehr viel vor. ... Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende ... hübsche Route

Mit Faktor 40 für Treppen macht BRouter auch den langen Looping, bis 30 hätte er die Treppe genommen. Man kann sowas in der Online Version selber ausprobieren, indem man über den Upload-Button ein modifiziertes Profil hochlädt (was dann als "custom" in der Auswahlbox steht)

Interessant, also durchaus so wie ich es erwartet hätte.
Schön dass man bei Brouter das im Detail sehr genau einstellen und auch probieren kann.

abrensch wrote:
EvanE wrote:

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. ... Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

... Der Router sucht den Weg mit den geringsten "Kosten", was aber ein rein abstraktes Konzept ist. ...

Der Hauptteil der Kostenfunktion ist dieser entfernungsabhängige Teil, also immer Wegstrecke mal Kostenfaktor, und das über alle Wegstücke aufsummiert. Es gibt aber noch zwei andere Teile in der Kostenfunktion, dass eine sind die Winkelkosten ("turncost")  und das andere die Höhenkosten ("elevationcost").

Gerade am Beispiel der "turncost" wird deutlich, dass das Konzept tatsächlich abstrakt ist. Er rechnet für eine 90-Grad Ecke Zusatzkosten von 90m. Das wäre aus der Sicht einer Zeitbetrachtung ja viel zu viel (man braucht keine 16 Sekunden zusätzlich, um um eine Ecke zu fahren). Man muss das eher als Filter verstehen, der verwinkelte Wege vermeidet, weil in verwinkelten Wegen mehr böse Überraschungen stecken als in geraden.

Kommt wie immer darauf an. Rechts abbiegen verursacht (bei uns) relativ wenig Kosten, man sollte allerdings auf den Querverkehr achten. Beim links abbiegen hingegen muss man ggfs. recht lange auf den Gegenverkehr warten. Solange man rechts/links abbiegen nicht unterscheidet, scheint mir das ein recht guter/brauchbarer Mittelwert zu sein.

In der Tat gibt es viele (mich eingeschlossen) die eher eine einfache (wenige Abbiegevorgänge), leicht zu merkende Route auswählen, wenn sie ohne Router selber planen, als die letzten Meter sparen zu wollen.

Wie sieht es mit Kreuzungen (gleichrangig, niederer / höher Rang, mit Ampel geregelt) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

Edbert (EvanE)

Offline

#37 2013-01-20 18:13:20

abrensch
Member
Registered: 2013-01-07
Posts: 405

Re: BRouter: offline Fahrrad-Routing für Android

EvanE wrote:

Wie sieht es mit Kreuzungen (gleichrangig, niederer / höher Rang, mit Ampel geregelt) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

Schlecht :-)

Mit Ampeln ( highway = traffic_signals als node-tag ) hatte ich experimentiert, aber davon gibts einfach zu wenig in der Karte, schon garnicht an den Nodes von strassenbegleitenden Radwegen.

Über so eine Bewertung von Kreuzungen nach Richtung und Rang habe ich tatsächlich nachgedacht und so könnte man, auch mit vorhandenen Kartendaten, wohl auch tatsächlich bessere Wege finden, aber das war mir bisher zu schwierig.

Bahnübergänge kennt BRouter bisher nicht.

Über eine Fähre bin ich letzte Woche selbst gestolpert, stand plötzlich am Main an so einer kleinen Schönwetter-Ausflugsfähre, weil ich vergessen hatte, das "no ferries" Profil zu benutzen. Fähren waren deswegen schwierig, weil sich kein Kostenfaktor finden liess, der für diese kleinen Main-Fähren genauso funktioniert wie für die Bodenseefähren. Deswegen habe ich die Berechnung von Fähren jetzt nochmal geändert: sie bekommen jetzt einmalige Zusatzkosten von 10km, unabhängig von der tatsächlichen Wegstrecke der Fähre, und dann noch Kostenfaktor 5 für die Wegstrecke. Damit werden die kleinen Main-Fähren nicht mehr gefunden (weil die nächste Brücke ja nie weit ist), die Rhein-Fähren aber doch.

Gruss, Arndt

Online

#38 2013-01-21 07:54:19

schiki
Member
Registered: 2012-12-07
Posts: 95

Re: BRouter: offline Fahrrad-Routing für Android

Hallo Arndt,

war das zufällig diese Fähre? http://www.openstreetmap.org/?lat=50.05 … 11&zoom=16
Hatte ich auch schon in einer vom Brouter berechneten Route drin, fährt aber nur an Ausflugstagen.

Mit den beschriebenen Modifikationen ist der BRouter sicher noch ein gutes Stück besser geworden, ich werde ihn mir in den nächsten Tagen auf mir bekannten Terrain nochmal anschauen, aber nur theoretisch - momentan zu kalt und zu viel Schnee.

So etwas ähnliches mit unterschiedlichen Profilen gibt es jetzt auch für Bergwander in den Alpen, allerdings auf ein bestimmtes Gebiet beschränkt und nicht als App für das Smartphone: http://geo.dianacht.de/topo/ - von Netzwolf entdeckt.
Für Wanderer im Gelände ist glaube ich die Berechnung deutlich einfacher, es müssen nicht so viele unterschiedliche Tags berücksichtigt werden.

Gruß Schiki


Gruß aus Rheinhessen

Offline

#39 2013-01-21 08:56:50

maxbe
Member
Registered: 2010-01-19
Posts: 2,953
Website

Re: BRouter: offline Fahrrad-Routing für Android

schiki wrote:

Für Wanderer im Gelände ist glaube ich die Berechnung deutlich einfacher, es müssen nicht so viele unterschiedliche Tags berücksichtigt werden.

Jo, das ist kein Kunststück im Vergleich zu Arndts Fahrradrouting. Da stecken ein paar Verbotsregeln, paar Strassenklassen, Wanderwegrelationen, sac_scale und Höhenmeter drin. Fussgänger haben ja selten Einbahnstrassen, dürfen überall abbiegen und die Zielgruppe kann auch Treppen steigen. Das mit den Strafpunkten fürs Abbiegen finde ich als Idee gut, dann läuft man nicht im zickzack durch die Häuserblocks. Aber das ist auch eher in Städten interessant ist als im freien Gelände.

Grüße, Max

Offline

#40 2013-01-21 11:45:31

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: BRouter: offline Fahrrad-Routing für Android

maxbe wrote:

... Fussgänger haben ja selten Einbahnstrassen, dürfen überall abbiegen und die Zielgruppe kann auch Treppen steigen. Das mit den Strafpunkten fürs Abbiegen finde ich als Idee gut, dann läuft man nicht im zickzack durch die Häuserblocks. Aber das ist auch eher in Städten interessant ist als im freien Gelände.

Hallo Max

Neben dem "zickzack durch die Häuserblocks" gibt es noch den Fall kurze, steile Zick-Zack Strecke gegen eine längere, weiter geschwungene, weniger steile Strecke einen Berg hinauf. Da können die Präferenzen durchaus unterschiedlich liegen. Auch beim Fußgängerrouting kann ein Malus fürs Abbiegen also sinnvoll sein. Über die Größe des Malus müsste man dann gegebenenfalls mal nachdenken.

Edbert (EvanE)

Offline

#41 2013-01-21 12:33:38

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:
EvanE wrote:

Wie sieht es mit Kreuzungen (...) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

...
Mit Ampeln ( highway = traffic_signals als node-tag ) hatte ich experimentiert, aber davon gibts einfach zu wenig in der Karte, schon garnicht an den Nodes von strassenbegleitenden Radwegen.

Über so eine Bewertung von Kreuzungen nach Richtung und Rang habe ich tatsächlich nachgedacht und so könnte man, auch mit vorhandenen Kartendaten, wohl auch tatsächlich bessere Wege finden, aber das war mir bisher zu schwierig.

Hallo Arndt

Jede Kreuzung (ob Ampel oder nicht) ist ja immer auch ein Gefahrenpunkt, erfordert besondere Aufmerksamkeit und ggfs. eine Reduzierung der Geschwindigkeit. Von daher wäre ein genereller Malus (kleiner als beim Abbiegen) sinnvoll.

Kreuzungen mit Ampeln erkennt man bei separat eingetragenem Radweg an einem Knoten mit highway=crossing + crossing=traffic_signals. Zumindest wenn das richtig eingetragen ist.

abrensch wrote:

Bahnübergänge kennt BRouter bisher nicht.

Schade, sie bedeuten ja oft Wartezeit.
Bahnübergänge sind leicht am Knoten mit railway=(level_)crossing zu erkennen.
Den Malus würde ich größer (2-5x) als beim Abbiegen sehen.

abrensch wrote:

Über eine Fähre bin ich letzte Woche selbst gestolpert, ... Fähren waren deswegen schwierig, weil sich kein Kostenfaktor finden liess, der für diese kleinen Main-Fähren genauso funktioniert wie für die Bodenseefähren. Deswegen habe ich die Berechnung von Fähren jetzt nochmal geändert: sie bekommen jetzt einmalige Zusatzkosten von 10km, ..., und dann noch Kostenfaktor 5 für die Wegstrecke. Damit werden die kleinen Main-Fähren nicht mehr gefunden (weil die nächste Brücke ja nie weit ist), die Rhein-Fähren aber doch.

Das scheint mir ein guter Ansatz zu sein. Ob die 10km Malus optimal sind oder der Wert besser Richtung 5-8km verschoben werden sollte, muss die Erfahrung zeigen. Ein kurzer Online-Test ergab eine starke Präferenz gegen Fähren.

Edbert (EvanE)

Offline

#42 2013-02-03 12:32:28

GUFSZ
Member
Registered: 2012-11-30
Posts: 406

Re: BRouter: offline Fahrrad-Routing für Android

Dann mal hier eine Fehlermeldung.

Ich musste meine anderen Favoriten in der Kategorie löschen, in der der Startpunkt und ENdpunkt stand. Davor hat sich brouter beschwert, dass es keinen Startpunkt gäbe und sich verabschiedet.

Offline

#43 2013-02-10 08:50:12

GUFSZ
Member
Registered: 2012-11-30
Posts: 406

Re: BRouter: offline Fahrrad-Routing für Android

Ich habe da ein etwas komisches Routingergebnis mit dem Trekkingprofil bekommen.
Start und Zielpunkt: http://dl.dropbox.com/u/512261/Osmand/brouter.gpx
Ergebnis: http://dl.dropbox.com/u/512261/Osmand/b … omisch.gpx

Es ist die Brouterversion einen Tag bevor Du hier gepostet hast.

Offline

#44 2013-02-10 09:32:00

GUFSZ
Member
Registered: 2012-11-30
Posts: 406

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:

Über eine Fähre bin ich letzte Woche selbst gestolpert, stand plötzlich am Main an so einer kleinen Schönwetter-Ausflugsfähre,

Die an der Eddersheimer Staustufe? Es wäre besser, die aus OSM zu streichen, so häufig wie sie nicht fährt.

Das mit den Kosten würde ich mal mit den Rheinfähren überprüfen. Interessant dabei ist diese Fähre. Sehr interessante Fährzeiten: http://www.guntersblum-tourismus.de/ind … &Itemid=97

Offline

#45 2013-02-10 10:18:23

abrensch
Member
Registered: 2013-01-07
Posts: 405

Re: BRouter: offline Fahrrad-Routing für Android

GUFSZ wrote:

Die an der Eddersheimer Staustufe?

ja, glaub schon, sind aber noch 2km von der Fähre bis zur Staufufe. Jedenfalls die, die Schiki oben genannt hat.

Das mit den Kosten würde ich mal mit den Rheinfähren überprüfen. Interessant dabei ist diese Fähre...

Ja schwierig. Ist zwar eine Fähre auf eine Halbinsel, aber wie ich es sehe kommt man auf der anderen Seite über eine Brücke über den Altrhein, sodass das schon eine Langstecke schliessen könnte. Im Prinzip könnte ich die Fährzeiten auch auswerten, steht in beiden Fällen ja drin als "opening_hours" tag.

Der Routing-Fehler im anderen Post kann sein. In dieser Version (0.1) war ein Fehler drin mit einem internen Integer-Überlauf. Der ist behoben ab 0.3. Das mit dem Handling der OsmAnd-Favoriten verstehe ich selber nicht so ganz. Irgendwie sind das nur Backup-Files, die ich da lese, und ich lese auch schon 2 (favorites.gpx und favorites.gpx_bak oder so ähnlich), das ist bisschen Bastelei.

Gruss, Arndt

Online

#46 2013-02-10 11:45:09

schiki
Member
Registered: 2012-12-07
Posts: 95

Re: BRouter: offline Fahrrad-Routing für Android

GUFSZ wrote:

Ich habe da ein etwas komisches Routingergebnis mit dem Trekkingprofil bekommen.
Start und Zielpunkt: http://dl.dropbox.com/u/512261/Osmand/brouter.gpx
Ergebnis: http://dl.dropbox.com/u/512261/Osmand/b … omisch.gpx

Es ist die Brouterversion einen Tag bevor Du hier gepostet hast.

Ich bekomme mit BRouter Version 0.5 die gleiche merkwürdige Schleife am Anfang, selbst wenn man das Ziel ziemlich in die Nähe legt. Der Rest der Route sieht aber m.E. gut aus.
Vielleicht könntest Du für dieses Problem einen neuen Thread in https://groups.google.com/forum/?fromgr … ikerouting eröffnen


Gruß aus Rheinhessen

Offline

#47 2013-02-10 12:32:52

schiki
Member
Registered: 2012-12-07
Posts: 95

Re: BRouter: offline Fahrrad-Routing für Android

Hat sich geklärt, den Verbindungsknoten 2115081565 gibt es erst seit 16 Jan, die Routingdaten sind aber schon von Anfang des Jahres.


Gruß aus Rheinhessen

Offline

#48 2013-02-14 08:41:50

GUFSZ
Member
Registered: 2012-11-30
Posts: 406

Re: BRouter: offline Fahrrad-Routing für Android

https://dl.dropbox.com/u/512261/brouter … ch%202.gpx
Gleich am Anfang des Tracks gibt es eine sonderbare Sache. Der Schlenker in die "Alte Gasse" rein und dann wieder raus. Der erste Schlenker geht in die entgegengesetzte Richting der Linksabbiegerspur der Alten Gasse. Ich habe die Stelle in JOSM überprüft, dort ist Oneway richtig eingetragen.

Es stimmt irgendetwas nicht mit den Headerdaten der gpx-files nicht, die von Brouter kommen. Jedesmal wenn ich sie mit routeconverter.de öffne, lande ich in Afrika.

Offline

#49 2013-02-14 10:52:39

abrensch
Member
Registered: 2013-01-07
Posts: 405

Re: BRouter: offline Fahrrad-Routing für Android

GUFSZ wrote:

Gleich am Anfang des Tracks gibt es eine sonderbare Sache. Der Schlenker in die "Alte Gasse" rein und dann wieder raus. Der erste Schlenker geht in die entgegengesetzte Richting der Linksabbiegerspur der Alten Gasse. Ich habe die Stelle in JOSM überprüft, dort ist Oneway richtig eingetragen.

Ja das ist aber so gedacht. Hier der Ausschnitt aus dem Profile dazu:

  add switch and reversedirection=yes oneway=yes
        switch or cycleway=opposite cycleway=opposite_lane 0
        switch or highway=primary highway=primary_link 50
        switch or highway=secondary highway=secondary_link 30
        switch or highway=tertiary highway=tertiary_link 20
        4.0
       0.0

Das heisst, auf der Bleichstrasse ("secondary") ist der falsche oneway "ziemlich verboten"
(kostenfaktor 30+), in der Alten Gasse ("redidential") aber nur mit Kostenfaktor 4+
(=du kannst schieben). Und damit ist's die billigste Lösung, weil ein Weg ohne
oneway-verletzung wäre viel weiter.

Es stimmt irgendetwas nicht mit den Headerdaten der gpx-files nicht, die von Brouter kommen. Jedesmal wenn ich sie mit routeconverter.de öffne, lande ich in Afrika.

Da bin ich an anderer Stelle auch schon darauf aufmerksam gemacht worden. Ich "misbrauche" die gpx-Version für meine Version (hier 0.1) und das darf ich nicht. Wenn Du da eine "1.1" reinschreibst, geht es. Hab' ic als TODO auf meienr Liste.

Gruss, Arndt

Online

#50 2013-02-14 11:12:16

GUFSZ
Member
Registered: 2012-11-30
Posts: 406

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:

Ja das ist aber so gedacht. Hier der Ausschnitt aus dem Profile dazu:

  add switch and reversedirection=yes oneway=yes
        switch or cycleway=opposite cycleway=opposite_lane 0
        switch or highway=primary highway=primary_link 50
        switch or highway=secondary highway=secondary_link 30
        switch or highway=tertiary highway=tertiary_link 20
        4.0
       0.0

Das heisst, auf der Bleichstrasse ("secondary") ist der falsche oneway "ziemlich verboten"
(kostenfaktor 30+), in der Alten Gasse ("redidential") aber nur mit Kostenfaktor 4+
(=du kannst schieben). Und damit ist's die billigste Lösung, weil ein Weg ohne
oneway-verletzung wäre viel weiter.

Da ich die Stelle kenne. Die Lösung bedeutet einmal über eine vierspurige Straße und dann noch einmal zurück. Einfach den Bürgersteig an der Bleichstr. entlang zur Peterstraße geschoben, wäre schlauer.

Schau dir mal https://dl.dropbox.com/u/512261/brouter … %20Weg.gpx im Satellitenbild an.

Da Du an anderer Stelle geschrieben hast, dass Du auch die Daten für eine stimmgeleitete Führung für diverse Apps bereitstellen willst...

Bei abgeschaltetem Bildschirm, wären die Abbiegepunkte zum Schieben falsch angesagt.

Käme so etwas in gewisser Häufung vor, gibt eine Stimmführung mit abgeschaltetem Display keinen Sinn mehr.

Letztendlich habe ich hier einen lustigen Einzelfall aufgegabelt oder nicht?

Offline

Board footer

Powered by FluxBB