Also ich habe jetzt in den Profilen rumgestöbert, dabei ist mir folgende Zeile aufgefallen:
assign isbike or bicycle=yes [b]or or[/b] bicycle=permissive [i]bicycle=designated lcn=yes[/i]
Das “or or” ist das ein Fehler oder hat das einen tieferen Sinn?
Den Schluss verstehe ich auch nicht so ganz, weil vor “bicycle=designated” müsste eigentlich auch ein “or” stehen?
Du hast Recht, das scheint Lorsch/Bensheim zu sein. Ist mir noch gar nicht aufgefallen.
Welche Probleme gab es mit der Android 4.4 bei den Offline-Karten? Ist es das Zugriffsproblem auf die externe SD-Karte?
Ich habe Version 4.1. auf dem Handy und hatte keine Probleme. Kannst du das Problem und vor allem die Lösung mal so schildern, dass ich es in meine Anleitung zu OruxMaps (http://www.adfc-bergstrasse.de/smartphone.htm) mit aufnehmen kann?
NNoGo-Areas
Kann mir einer sagen, ob die Möglichkeit, NoGo-Areas zu definieren, bei der Kombination mit OruxMaps auch möglich ist? Meiner Versuche waren bisher nicht erfolgreich. Wenn ich es richtig verstanden habe, dann muss man Wegpunkte mit dem Namen “NOGOnn” anlegen, wobei nn der Radius in Metern ist, der dann vom Routenplaner gemieden wird.
Kann mir jemand weiterhelfen?
Gruß
Mannigator
Sollte ganz normal funktionieren, aber wie schon gesagt: kleingeschrieben (“nogo3000 Heppenheim”).
Siehst Du denn überhaupt Wegpunkte (ueber den “select from/via” Button) ? Weil Gründe, dass die Dateischnittstelle garnicht funktioniert gibt es einige (das hat dann mit der Verzeichnisstruktur auf der SD-Karte zu tun), aber wenn Du Wegpunkte siehst solltest Du auch Sperrpunkte sehen (in dem Dialog “Check NoGo Selection”). Und die, die Du da siehst, sind auch beim Zugriff über die Diensteschnittstelle aktiv, solange sie nicht für den jeweiligen Routing-Modus weg-konfiguriert wurden.
Zu Deiner anderen Frage wegen Android 4.4: ja, es ist das Problem mit der Zugriffsberechtigung auf die externe SD-Karte. Ich hab’ dazu ein eigenes “Readme” geschrieben: http://brouter.de/brouter/kitkat_survival_readme.txt
Ich habe uebrigens heute eine neue Version deployed (1.1), sowohl auf meinem Server ( http://brouter.de/brouter/revisions.html ) als auch bei Google-Play. Die unmittelbare Neuerung ist eine Laufzeitverbesserung um ca 30%, aber der Google-Play Update von 1.0.2 → 1.1 akkumumliert ja auch paar andere Patches der letzten 4 Monate.
NoGo-Areas
Vielen Dank an GUFSZ und abrensch, für den Hinweis auf die Groß-/Kleinschreibung.
Es klappt jetzt auch mit OruxMaps+BRouter. Ich werde das auch demnächst in die Anleitung aufnehmen. Schön ist auch, dass die nogo-Areas unabhängig von der Routenplanung bestehen bleiben können und nicht bei jeder Planung neu definiert werden müssen.
Guten Rutsch an alle.
Mannigator
Ich habe eine Frage zu den Kosten. Mir fehlt für die Kosten ein Maßstab. Ich beziehe mich jetzt alleine auf die Wege.
Bedeudet
switch tracktype=grade1 1
, dass mich in realen Weltwerten ein Kilometer grade1 einen Euro kostet.
Wenn ich dann setzte
switch highway=primary 4
, dann kostet mich wieder in realen Weltwerten ein Kilometer primary vier Euro.
Erst, wenn ich mit grade1 den primary-Weg mit mehr als vier Kilometer umfahren müsste, dann würde ich auf den Primaryweg geroutet?
Richtig. Der “costfactor” ist ja nur ein Faktor, hat also keine Einheit. Intern rechnet brouter aber die Kosten aber in “metern”, also:
cost = costfactor*distance[m]
Andere Terme in der Kostenfunktion haben aber entsprechend eine Einheit: “turncost” sind die Kosten in Metern für einen 90-Grad Winkel, “initialcost” ist in Metern.
“uphillcost” hingegen hat wieder keine Einheit, sondern ist ein Faktor: Kosten (in Metern) pro Meter Aufstieg.
Danke.
Schau dir bitte
http://brouter.de/brouter-web/#zoom=15&lat=50.11585&lon=8.68812&layer=OpenStreetMap&lonlats=8.690271,50.116148|8.686452,50.118679&nogos=&alternativeidx=0&format=geojson
an.
Gib dann beim Trekkingprofil turncost 36 ein.
Sieht so aus, als würde die Kurvigkeit der Weg nicht mitberechnet? Ob ich an einer Kreuzung aber abbiege oder eine enge Kurve fahre, macht teilweise einen relativ geringen Unterschied.
Stimmt, die Winkelkosten sind:
turncost * ( 1 - cos(winkel) )
Und damit hat eine ausmodellierte 90-Grad Kurve geringere Kosten als ein 90-Grad Knick.
Es waere aber auch falsch, die Winkelkosten zu “physikalisch” zu sehen, denn dafür sind sie viel zu gross. Es kostet keine 90m/20 kmh = 16 Sekunden, um irgendwo rechts abzubiegen. Du musst das mehr als Filter sehen: gerade Wege sind gute Wege, während in dem verwinkelten Gewurschtel die bösen Überaschungen stecken. Und vor dem Hintergrund macht die bessere Bewertung der ausmodellierten Kurven wieder Sinn.
Entweder habe ich ein Verständnisproblem oder Du wertest in deinen Profilen einen Teil der Tags unter http://wiki.openstreetmap.org/wiki/DE:Key:cycleway nicht aus.
Ein highway=primary mit cycleway=lane dürfte ein Großteil der Radfahrer anders bewerten als einen reinen highway=primary. Diese Bewertung scheint bei deinen Profilen nicht stattzufinden.
Siehst Du schon richtig. Geneu genommen werte ich cycleway, cycleway:right und cycleway:left ueberhaupt nicht aus, abgesehen von er Oneway-Logik.
“Anders” wird bestimmt jeder unterschreiben, auch die Rennrad-Fahrer, die benutzungspflichtige Radwege fürchten wie der Teufel das Weihwasser.
im “fastbike” Profil sind die getrennt gemappten Radwege (highway=cycleway) mit 1.3 schlechter bewertet als Bundesstrassen (highway=primary), die den Faktor 1.2 haben. Da waere es also nicht konstistent, eine Bundesstrasse wegen cycleway=lane besser zu bewerten.
Im “trekking”-Profil muss ich Dir aber recht geben, da passt das nicht. cycleway=lane sollte wenigstens so gewertet werden wie die anderen Trigger, die zu “isbike=true” führen.
Dann wird auch bicycle_road=yes nicht beachtet?
Wir haben uns mal vor einem Jahr über Fähren unterhalten. Ich bin nicht sicher, ob das sinnvoll ist und geht, aber wenn die Fähre ein Teil eines Radroutenrelation ist, dann sollte man sie anders werten als eine reine Fähre, weil die verlässlicher fährt. Und Fähren die Autos erlauben sind auch verlässlichere Kandidaten.
Interessant ist noch der Fall:
highway=primary, bicycle=no, cycleway=track
http://www.openstreetmap.org/way/273332262#map=17/50.79846/6.49801
Kommt aber relativ selten vor. Meist ist dann ein Radweg parallel dazu gemappt über den geroutet werden kann.
Ich wollte dann mal kurz bekanntgeben, dass man den BRouter ab jetzt auch mit QLandkarteGT nutzen kann. Aktuell muss man sich dafür den Sourcecode von QLandkarteGT noch selber auschecken und compilieren, im nächsten Release ist es dann für alle, die nur einen Installer bedienen wollen drin.
Als Voreinstellung ruft QLandkarteGT den BRouter-onlineservice von http://brouter.de/brouter-web auf. Lokales (offline) Routing geht genauso, dazu muss man den BRouter lokal standalone laufen lassen und in QLandkarte kurz die Konfiguration anpassen.
Viel Spaß damit 
Norbert
Ich freu mich drauf, es auszuprobieren (werde aber wohl auf die Release-Version warten…)
Den Server-Link als Default zu verwenden ist denk ich o.k., auch wenn das nie als “stabile” Schnittstelle gedacht war, aber faktisch ist sie es jetzt und ich werde auch drauf achten, keine inkompatiblen Aenderungen einzufuehren. Von der Last her hält er das auch aus, da sind zu Zeit ca 2000 Requests pro Tag drauf, kann im Fruehjahr aber mehr werden, und einmal die Woche, wenn der Präprozessor läuft, drückt der bisschen auf die Antwortzeiten. Wäre aber gut, in den Logs erkennen zu können, welche Requests von BRouter-Web kommen und welche von anderen Clients, im Moment kann ich das nicht unterscheiden.
Hab’ mal bisschen mit dem aktuellen Release von QLandkarteGT gespielt um kam (mit Onlinekarte) gut zurecht. Eine Route mit den existierenden Diensten (OpenrouteService und Mapquest) zu berechnen ist mir aber nicht gelungen, es waren immer nur gerade Linien.
Was cool waere, wenn man auch Sperrzonen setzen könnte. Wenn man das nicht “richtig” in die Oberfläche integrieren möchte mit gemalten, halbtranspareneten Kreisscheiben wie bei BRouter-Web, könnte man das auch “quick&dirty” machen mit der gleichen Namenskonvention (“nogo3000 Offenbach”) wie in der BRouter-App, und dann die Sperrzonen einfach bei der Wegpunkte-Auswahl mit auswählen?
Hallo Arndt,
Namenskonvention für No-Go-areas wäre schon möglich, aber einer Route fest zuordnen würde ich die nicht. Ohne Änderung wäre die Darstellung alles andere als intuitiv und das dahingehend zu überarbeiten per Konvention erkannte No-Go-Punkte einer Route anders darzustellen gefällt mir gar nicht (da bestimmt dann der Workaround das Konzept…). Für Sperrzonen sollte man schon das Datenmodel der Routen konzeptionell erweitern und No-Go-Areas separat bearbeitbar und dann einer Route hinzufügbar machen. Man will die Areas ja auch irgendwo sehen. Ein weiteres Problem mit der Namenskonvention ist, dass man in QLandkarteGT ‘Ad-hoc’-routen nicht notwendigerweise aus existierenden Wegpunkten, sondern viel einfacher über ‘Overlay’->‘Entfernungsmesser’->‘Route erzeugen’, das geht deutlich einfacher als erst mal für alle Zwischenziele einen Wegpunkt anzulegen. Nur kann man die Punkte der damit erzeugten Route nicht individuell bearbeiten und auch einer so dynamisch erstellten Route keine weiteren (existierenden) Wegpunkte hinzufügen.
Aber vieleicht muss man die NoGo-punkte überhaupt nicht einer bestimmten Route zuordnen, sondern einfach ‘global’ verwalten. In QLandkarte hat man ja immer eine Workarea in der man arbeitet. Eigentlich fehlt den Punkten dann nur ein optionaler Radius und ein ‘Go/NoGo’-flag, dann könnte man diese als Kreise darstellen und einfach alle in der Workarea befindlichen NoGo-punkte beim Routenberechnen (unabhängig von der konkreten Route) mitschicken.
Ich denke aber, dass ich das eher in QMapShack, dem in Entwicklung befindlichen Nachfolger von QLandkarteGT angehen werde. Da passt das konzeptionell viel besser rein, weil man mehr als eine Workarea zur gleichen Zeit offen haben kann. QMapShack ist schon sehr weit gediehen und was die Bedienung (gerade beim Routenerstellen) angeht auch einfacher zu bedienen als QLandkarteGT.
Gruß,
Norbert
Wir könnten Requests von BRouter-Web z.B. über den “Origin” HTTP Header ableiten und entsprechend loggen (gegen Apps die Header faken hilft das allerdings nicht).
QLandkarteGT könnte einen “User-Agent” HTTP Header mitschicken, idealerweise mit entsprechender Version, z.B. “User-Agent=QLandkarteGT 1.7.7”.
Vor ca. einem Jahr wurde das abgelehnt, da ging es um die Blockierung durch die OSM-Admins:
http://sourceforge.net/p/qlandkartegt/mailman/message/31987186/
Gruß,
Mondschein
Ich wurde heute von der Hahnstraße auf https://www.openstreetmap.org/way/4963475 geroutet.
Das liegt an meiner Gewichtung. Aber mir ist da aufgefallen, deine Onewayregelung berücksichtigt nicht, ob Bürgersteig oder nicht. Und damit, ob man schieben kann oder nicht. An so einer Stelle habe und möchte ich als Radfahrer schiebenderweise nichts zu suchen haben.
Aber solche Übergänge gibt es viele, wenn es oberirdische Schienenfahrzeuge entlang der Straße gibt.