Ja, ich bezog das durchaus auf alle Daten, die richtungsabhängig sind. Eventuell braucht es einen Flächendatentyp mit Richtungsvektor, wobei ich mir nicht sicher bin, ob das wirklich ausreicht.
Ich habe es nicht im Detail durchgelesen, aber ich bezweifle, dass auf Turn Restrictions verzichtet werden kann. Möglicherweise braucht man sie allerdings seltener, was ja auch ein Fortschritt wäre. Warum die Restrictions komplizierter sein sollen, sehe ich allerdings nicht. Statt zwei Linien + Punkt oder mehrere Linien sind es dann halt mehrere Flächen. Kein großer Unterschied.
Bedaure, mir fehlt für sowas aktuell die Zeit. Ich hoffe, dass Fabi ein Beispiel zeigen wird. Ich bleibe aber vorerst dabei, dass ich die anderen Varianten nicht für besser wartbar halte. Gerade alles, was viele Tags auf eine Linie quetscht hat ein großes Potential zu inkonsistenten Daten, weil die Auswirkungen der Tags vor allem für Mapper, denen das Schema nicht vertraut ist, nicht erkennbar sind. Modelle mit mehr Geometrie dürften offensichtlicher sein und leichter als kaputt erkennbar, wenn einer dran gepfuscht hat.
Davon habe ich nicht gesprochen. Es ging darum, dass alle als Linien eingetragenen Straßen weiterhin voll gültig sind, nicht, dass sie parallel erfasst werden sollten. Entsprechend ist die Umstellung langsam und alle wichtigen Tools werden auf die Dauer mitziehen. Alle anderen werden mit der Zeit sowieso durch ganz andere Änderungen, beispielsweise an der API obsolet werden. Abgesehen davon schadet uns die doppelte Erfassung beispielsweise bei Flüssen auch nicht (auch wenn sie da zugegebenermaßen wesentlich simpler ist).
Wie gesagt, ich spreche nicht von Linien und Flächen für die selbe Straße, sondern von der grundsätzlichen parallelexistenz. Außerdem diskutieren wir hier dafür aktuell mindestens genauso komplizierte Relations- und Tagmodelle um geometrische Eigenschaften irgendwie in dafür ungeeigneten, stark generalisierten Linien unterzubringen. Da sollte man Alternativen zumindest bedenken. Zumal, wenn sie zwar vielleicht was einzelne Punkte um die es hier geht betrifft nicht viel besser sind, dafür aber in anderen (stichwort Rendering) wesentlich bessere Möglichkeiten für die Zukunft erlauben.
Rate mal, warum es da noch die Relation für die Fahrspur gibt?! Die ist genau dafür dam um durch die angrenzenden Flächen bzw. Linien den Verlauf der Spurhauptrichtung herausbekommen zu können. Da die quer angrenzenden Flächen nicht mit in der Spurrelation sind, gehören die eben auch nicht mit zur Fahrspur.
Das istr alles lösbar, aber ich bin nicht gerade der Freund des motorisierten Induvidualverkehrs (dafür gibt es viele objektive Gründe, die wollen aber viele nicht unbedingt wahrhaben…) und kennen da alle Regelungen genau, so das das Leute die sich auskennen mal korrigieren sollten.
Wie ich schon öfter und auch in dem Vorsclag geschrieben habe: man hat die Wahl zwischen vom Menschen mappbar und dafür beschränkt in der darstellung oder allgemeineren maschinentauglichen Modellen. Da mußt du mal sagen, was du gerne hättest!?
Wieso? Da die Tags der konkreten Wege das Modell nicht interessieren, kann da gerne an einer Spur noch ein altes highway=* usw. getaggt sein. Ansonsten gilt da wieder das was bei Punkt 3 steht.
Das geht, bei deiner Kreuzung müssen maximal 6x7 (5x4 Spuren + 2x2 Radwege) Felder erstellt werden. Dann kann man erst mal allen auf die Kreuzung einmündenden Übergängen eine Übergangsgruppe zuweisen und dann muß für die schwierigen Fälle, die sich nicht achon über die Standardfälle mit auflösen lassen, ggf. eine Mehrfachzuweisung von Übergangsgruppen erfolgen. Der schlimmste Fall ist, daß man für jede Abbiegebeeschränkung die Übergangsgruppe der Spur explizit über den gangen Spurverlauf an jedem Übergang mitführen muß. Die Idee mit der Übergangsgruppe ist auch darauf ausgelegt, das sich die meisten üblichen Standardkreuzungen und -fälle damit effizient darstellen lassen, bei komplexen Kreuzungen kann dafür dann die Zahl der nötigen Relationen zunehmen. Es fehlt auch noch eine formale Beschreibung für eine möglichst effiziente Zuweisung der Gruppen (die hab ich erst ansatzweise), aber es lassen sich definitiv alle Abbiegebeschränkungen auflösen.
Die andere ungenaue “gut genug”-Alternative der Navibauer scheint, soweit ich das herausgefunden habe, zu sein, die Kreuzung zur “allgemeinen Verkehrsfläche” zu machen, wo man per Definition dann in alle Richtungen fahren kann und auf die einmündenen Spuren dann formale Zuordnungen der möglichen Spurübergänge per Relation bastelt. Frei nach der Devise: wir müssen ja auch nur routen, was schert uns denn, wie die Kreuzung in der Realität tatsächlich genau ausieht und wie dort die Spuren konkret verlaufen, bestenfalls redenrn wir noch die Sperrflächen und Fußgängerüberwege als funktionslose Bilddarstellung mit rein…
Die sind kein Problem, weil die grundsätzliche befahrbarkeit hat ja nun noch nichts mit der richtungsbezogenen Gültigkeit der aufgestellten Verkehrsschilder oder dort verlaufenden Buslinien zu tun. Die Befahrbarkeit ist eine Tatsache, warum die dann so ist, also die Ursache, wie z.B. eine Line oder ein Schild, ist, muß man dann noch extra erfassen.
Die bekommt man ja qasi, wenn man die jeweilige Übergangsgruppe an alle relevanten Übergänge taggen muß.
Die Liniendarstellung ist eine Ersatzdarstellung für die Flächendarstellung, so das man da nur eine Variante also Linien oder Flächen braucht.
Die Liniendarstellung wird eben nicht beibehalten, denn die ist in der Darstellung der Übergänge von der Straße und bei der Darstellung der realen Geometrie der beteiligten Flächen nämlich prinzipbedingt eingeschränkt.
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.
