Das die Restrictionen abgeschfft werden, steht ja auch nirgendwo, sondern die sind prinzipbedingt gleich mit eingebaut. Was deren Ursache ist, muß man dann wie gesagt noch getrennt darstellen.
Naja, es gibt da die vier Fälle (1. Übergangsgruppe wird neu gesetzt (=keine Auswirkung, aber idt der Anfang eines z.B, "forward"s); 2. Übergansgruppe ist gleich der des letzten Überganges (=z.B. “forward” aus der Richtung des letzten Überganges); 3. Übergangsgruppe ist ungleich der des letzten Überganges (=Verbot für alle, außer für die definierte Gruppe) und 4. Übergangsgruppe ist irrrelevant, da nicht vorhanden (=erlaubt von allen anderen Übergängen der Fläche)) für die übergänge und damit bekommt man die nötigen Varianten: allgemeines Verbot, allgemeine Erlaubnis und richtungsbezogene Erlaubnis/Verbot dargestellt. Das kompliziertere Beispiel brauche ich zumindest nicht. Wer meint eines zu brauchen, soll sich eben eins malen.
Das sehe ich genauso. Mal abgesehen davon, das die Vertreter der Linienmodelle mir mal erklären sollen, wie sie die Geometrie und die Übergänge zwischen den verschiedenen Flächen detailiert darstellen wollen, wenn alles Linien sind.
Auf http://www.cvisproject.org/ gibts dann (z.B. http://www.cvisproject.org/download/ERT_CVIS_FinalProject_Bro_06_WEB.pdf ) anschaulichere Infos, wie das Ganze dann mal zusammengebaut funktionieren soll.
Dabei kümmert sich die dort gelikten Subprojekte dann immer um Details, wie z.B. http://www.safespot-eu.org/ um die Api für die Sensordaten. Soll heißen, das Proposal zum dynamic_maxspeed kann man sich eigentlich sparen, weil neben der Erkennung von Falschfahrern wird es dann bestimmt bald automatische Strafzettel für nicht gesetzte Blinker, unangeschnalltes Fahren und jede einzelne Geschwindigkeitsüberschreitung (wer dachte die Mautbrücken sind da schlimm, hat falsch gedacht…) geben. Naja und immerhin gibt man sich Mühe bei der Sicherheit, aber früher oder später holt dann jemand doch den Masterkey aus dem HSM und das Ganze verkommt spätestens dann zum weiteren Spielplatz für Nerds.
Erfreulich ist, dass offensichtlich vermehrt turn=* und turn:lanes=* erfasst wird. Bei mapfactor wird auch schon an einer möglichen Auswertung gearbeitet http://forum.mapfactor.com/discussion/comment/1992#Comment_1992
Leider bin ich dort auch darauf gestoßen, dass die Erfassung nicht immer mit der Wiki zu turn und turn:lanes kompatibel ist wie etwa hier: http://www.openstreetmap.org/?lat=53.54521483182907&lon=10.030772387981415&zoom=18
Den Mapper habe ich angeschrieben.
Hat jemand eine Idee, wie wir für diese Erfassungen der lanes-Attribute eine Fehlertool bekommen können oder wäre das in OSMI oder keepright integrierbar? Wenn wir wollen, dass Router diese Informationen umfassend verwenden, müssen wir auch für fehlerfreie Erfassung sorgen
Hmmh, in Deutschland sind Mittelspuren mit beidseitigem Abbiegen nicht üblich, eventuell nicht mal in der StVO vorgesehen. Das Luftbild ist zur Beurteilung nicht von ausreichender Qualität. Auch Split statt Asphalt und die geringe Breite von 2m (notwendig wäre 3m) spricht gegen eine eigene Spur. Ob das Abbiegen über diese Mittelfläche gestattet oder ggfs. geduldet wird, kann man ohne Ortskenntnisse nicht einschätzen.
Aus der Ferne würde ich mich also eher gegen eine Mittelspur aussprechen.
Diese sind in Deutschland zwar selten, aber in §7 (3a) der StVO vorgesehen. Ein Beispiel ist in Hamburg die Straße Nedderfeld. Dort befinden sich östlich vom Offakamp zwei derartige Abschnitte. In Realität wird diese Spur dort aber hauptsächlich zum Umfahren falsch parkender oder haltender Autotransporter verwendet.
§7 (3a) der StVO passt für die Stelle, denn sie darf und soll zum Abbiegen nach links und Einfädeln über die Gegenfahrbahn genutzt werden. Die Breite von ca. 2 m ist wohl entstanden, weil die vorhandene Gesamtbreite der Straße bei der Neugestaltung nicht mehr hergab. Ich komme da leider nicht so oft durch, sonst hätte ich ein besseres Foto “on the ground”.
Auf Bing kann ich keine Leitlinien sehen. Somit ist §7 (3a) vermutlich nicht zutreffend. Formal kann man die Stelle wohl als eine breite Fahrbahn ohne Markierungen ansehen. Dann würde man sich ja zum Linksabbiegen auch eher mittig einordnen. Der Fahrbahnbelag wäre dann eben über den Querschnitt unterschiedlich, wie es beispielsweise auch bei Vorhandensein von Sommerwegen (http://de.wikipedia.org/wiki/Sommerweg) der Fall ist.
Passt hier wohl am besten
Bei uns wurde eine Kreuzung umgebaut. Jetzt hat man die Gegenfahrbahn baulich getrennt und zwischen die drei Spuren für left|through|right noch zwei Fahrradspuren für links und geradeaus eingeschoben, die von den motor-vehicle-Spuren mit durchgezogenen Linien getrennt sind. Rechtsabbiegende Radfahrer gibt es nict. Die dürfen durch einen kleinen Park.
lanes=* ist ein eigener Key, in dem Anzahl der Fahrstreifen angegeben wird.
Wendet man darauf das Conditional-Resctricions-Schema (als Erweiterung des Access-Schemas) an erhält man z.B. “lanes:motor_vehicle”=, womit die Anzahl der Fahrstreifen angegeben wird, die unter diesen Bedingungen (hier: Fahrzeug ist ein “motor_vehicle”) gültig ist. Da sich die Zahl der Fahrstreifen nicht ändert wenn man eine Strasse entlang fährt (ausser vielleicht, wenn man ein Baufahrzeug ist), finde ich das allerdings nicht sinnvoll. “surface:motor_vehicle”= würde hoffentlich auch niemand angeben.
Ausserdem gäbe es Probleme, wenn z.B. lanes=4 “lanes:motor_vehicle”=2 “turn:lanes”=“left|left|right|right” ohne verkürztes “turn:motor_vehicle:lanes”=* angegeben ist, weil für motor_vehicle mehr Fahrstreifen in “turn:lanes”=* vorhanden sind als laut “lanes:motor_vehicle”=* vorhanden sind
Wenn man auf Access-Keys (z.B. motor_vehicle=*) das Lanes-Schema anwendet, hat man einen Key wie z.B. “motor_vehicle:lanes”. Darin würde darin üblicherweise (bei lanes>1) mindestens ein ‘|’ vorkommen und der Wert des Access-Keys fahrstreifenweise angegeben sein.
