Dann wird es Zeit, mit konsequentem forward/backward tagging die Routeranbieter dazu zu bringen, das auszuwerten.
Baßtölpel
Man sollte aber auch die Abwärtskompatibilität aufrecht erhalten. Früher gab es nur eine Angabe auf der Straße, wenn es präzisiert wird “kann” es ein Router übernehmen.
Es wäre aber nicht richtig, den “älteren” die Daten, die einmal gültig waren zu entziehen. Leider wird das nicht immer beachtet.
Ich halte dann kein maxspeed besser als maxspeed, das zur Hälfte falsch ist. Schließlich funktioniert routing auch ohne.
Baßtölpel
Abwärtskompatibilität ja, wenn die Daten das erlauben. Sind die maxspeeds für forward und backward verschieden, sollte maxspeed gelöscht werden, weil es sachlich nicht richtig sein kann.
Die Router müssen sich an das tagging anpassen, nicht umgekehrt. Wir taggen nicht gegen, aber auch nicht für die Router.
Welcher Router wertet eigentlich sowas aus? 
http://www.openstreetmap.org/node/2367023237
Wiki Doku dazu: http://wiki.openstreetmap.org/wiki/Relation:enforcement
Wer nimmt schon for+back tags wenns auch ne Relation tut?!
Warum nicht von einfach zu spezialisiert:
einfach war immer maxspeed=* (bezieht sich auf Wegrichtung)
wenn präzisiert dann erweitert maxspeed:backwards=*
oder spezialisiert maxspeed:backward:conditional=* oder maxspeed:backward:lanes=*
Was ist übrigens wenn lanes und conditional zusammen in einer Fahrtrichtung auftreten?
Weil sich maxspeed=* nicht auf die Wegerichtung bezieht, sondern für beide Richtungen gilt. Entsprechend werten die Router es auch aus. Die Spezialisierung ist maxspeed:forward und maxspeed:backward. Wo beide übereinstimmen, kann maxspeed=* gesetzt bleiben, ansonsten ist es sachlich schlicht falsch und ein Fall für die Datentonne.
maxspeed=* ist einfach eine Abkürzung für maxspeed:both=*
Das ist nen Blitzer, das bezieht sich nicht auf maxspeed?
Die Relation ist sinnvoll, ich brauche keine Blitzerwarnung für einen unter mir im Tunnel wie es mit einem bloßen Node passiert.
+1
+1
Meiner Beobachtung nach müsste OSMAND das bereits auswerten… Ich kann es mangels Tablet z.Z. nicht testen… Mein Schrotteil ( Galaxy Tab 4) ist schon zum zweiten mal in Reparatur, schaltet sich selbst aus und geht erst nach einem Stromstoß wieder an… 
Sven
Üblicherweise schreibt es sich allerdings maxspeed:lanes:backward.
Dann sollte maxspeed:lanes:conditional angegeben werden. Selbst wenn im conditional-Fall die Werte für alle Spuren gleich sind hat man so wenigstens eine klare, logische Auswertereihenfolge.
Ok, kann ich mit leben.
Ist ja eh ein Luxusproblem, da in vielen Orten noch kein einziges maxspeed gemappt ist.
Nein, bisher nicht.
Ich war schon fast der Meinung… aber ok… Irgendjemand schrieb doch vor einer Weile, daß programiertechnisch da bei OSMAND wohl schon gearbeitet wird… ich finde nur den Beitrag nicht… Bei meiner Strecke, wo ich maxspeed:forward und maxspeed:backward getaggt habe, war ich der Meinung, die richtige Geschwindigkeit wird angezeigt… aber ok… vielleicht… irre ich mich auch… Ich konnte es wegen dem Samsung-Schr*** auch nicht weiter testen…
Sven
Ok, wird also gelöscht. Ich bin ja sowieso ein Verfechter nur maxspeed:forward und maxspeed:backward zu kartieren, die Redundanz ist erträglich, dafür ist klar, dass beide Seiten auch wirklich getrennt betrachtet wurden.
Tja… die mit mkgmap erstellten Garmin-Karten können das gar nicht abbilden. Ich nehme daher immer den kleineren von beiden Werten. Dafür gab’s nen extra Patch, siehe http://gis.19327.n5.nabble.com/Numerical-comparison-of-two-tags-td5783600.html
Darüber hinaus scheint nur Itomap http://www.itoworld.com/map/124 diese maxspeed-Spezialitäten zu berücksichtigen (das ist aber kein Router!).
Du gibst die Richtung ja schon vor: Wenn ein Datenmodell kein backward/forward kann dann muss der Präprozessor eben intelligenter werden und z.B. das kleinere nehmen. In die Datenbank gehört es nicht weil es für eine Richtung immer falsch ist.
Und natürlich der JOSM-Kartenstil “Höchstgeschwindigkeit”: https://josm.openstreetmap.de/wiki/De:Styles/Maxspeed 