Am 14.07.2010 um 18:40 schrieb Tirkon: > >> ... sonst wäre es keine Kreuzung. > > Wenn Du so möchtest, dann ist es eben keine Kreuzung. Ich habe ja auch > nicht von Kreuzung gesprochen, sondern von drei Straßen, die sich in > einem Punkt treffen und lasse offen, ob das mit der Zusatzbedingung > eine Kreuzung ist oder nicht.
Sorry, aber was ist es dann, wenn keine Kreuzung??? Wege kreuzen sich -> Kreuzung. Nenne eine T-Kreuzung meinetwegen eine Einmündung in die andere Straße, die Regeln bleiben die gleichen, egal welche Winkel auftreten und wie viele Straßen beteiligt sind, oder? >> Bedenke, dass ich explizit nur von der _Mittel_linie spreche, also von der, >> die die beiden Fahrt_richtungen_ auf einer Straße trennt! Diese Trennung >> wäre an Kreuzungen aber unsinnig, weil man sonst nicht abbiegen dürfte, da >> man sie ja nicht überfahren darf. Was meinst Du also bitte mit Mitellinie? > > Dasselbe wie Du, nämlich eine Fahrtrichtungstrennung. Als Bild nähme > sich mein Beispiel so aus: > > // / // > // / // > // b // > ================= / // > / // > ---------a---------P || > \\ > ================= \ \\ > \\ \ \\ > \\ c \\ > \\ \ \\ > \\ \ \\ > > Natürlich ist in diesem Falle ein Abbiegen über die Relationen bPc und cPa > nicht möglich. Ich gehe mal davon aus, dass Du darstellen wolltest, dass nicht nur a, sondern auch b und c jeweils eine durchgezogene Mittellinie sind. (Falls nein, stimmt cPa nicht, da man im Rechtsverkehr dann schon links abiegen kann.) Meinst Du wirklich, dass eine dermaßen gefährliche Kreuzung keine weitere Verkehrsregelung wie z.B. Abbiegegebots/Verbotsschilder hat, die das zusätzlich regeln (und die sowieso über turn_restriction-Relationen abzubilden wären?). Wenn es keine gefährliche Kreuzung sein soll - wieso gibt es dann eine durchgezogene Mittellinie (außer in Parkhäusern habe ich solche Linien noch nicht gesehen und diese ways tagge ich derzeit noch nicht Außerdem gibt es da meist auch noch Pfeilmarkierungen am Boden, die es zusätzlich verdeutlichen ;-) und drittes Argument: zeige mir mal ein Beispiel (google-Maps-link wäre wegen sat-bild gut geeignet), dass mir hilft, dieses Beispiel als "nicht-an-den-Haaren-herbeigezogen" anzusehen. ;-) Und trotz all dieser Argumente: warum willst Du das dann nicht einfach über turn-restriction-Relationen abbilden - ich hielte es sogar zusätzlich für nötig! Die durchgezogene Mitellinie kannst Du ja trozdem auf allen drei ways (a,b, c) taggen. Wo ist das Problem? > Das wäre ja auch gerade der Sinn solch einer > Linienanordnung. Man könnte sich den Fall vorstellen, dass aPb eine > durchgängig geführte aber engkurvige Straße ist und c seitlich > einmündet. Da die Einmündung aber äußerst stark befahren und zudem > eng, unübersichtlich und unfallträchtig ist, möchte man an dieser > Stelle den Einmündungsverkehr weder von noch zur gegenüberliegenden > Spur von aPb gestatten: > > \\ \ \\ // / // > \\ \ \\ // / // > \\ \ \\ // b // > \\ a \\ // / // > \\ \ \\ // / // > \\ \ \\================ / // > \\ \ / // > \\ --------P------------- // > \\ // > ======== \ =========// > \\ \ \\ > \\ \ \\ > \\ c \\ > \\ \ \\ > \\ \ \\ > > > Fändest Du den Fall so abwegig, dass es ihn nicht geben sollte? > Zumindest mit baulich getrennten Richtungsfahrbahnen für aPb kenne ich > einige ähnliche Beispiele: > http://www.openstreetmap.org/?lat=51.24622&lon=6.809134&zoom=18&layers=B000FTF nein, den letzten Fall halte ich nicht für abwägig (egal, ob a,b und c gestrichelt oder durchgezogen gemeint waren). Aber dann ist am Ende von c hoffentlich ein STOP-Schild - wenn es denn so gefähtlich ist an der Stelle ;-) Aber zumindest gibt es sicher auch Abbiegegebots/verbots-Schilder, die es zusätzlich regeln. Auch deshalb ist hier ausführlich mit turn-restriction-Relationen zu arbeiten - schon weil es sicher nicht alleine durch die Linien geregelt sein dürfte. Aber ich verstehe immer weniger, warum Du die durchgezogenen Mittellinien (um bei diesen Beispielen zu bleiben) hier über Relationen abbilden möchtest? Die turn_restriction-Relationen sind deshalb ja trotzdem nötig und dann kann man zusätzlich sehr leicht noch die Mitellinie mittaggen - und das geht gerade bei Deinen Beispielen sehr leicht. Erkläre mir mal bitte, wieso man nicht einfach die ways bis zu ihren Nodes entsprechend mit solid_line:middle=yes taggen kann (tag ist noch diskutierbar, siehe mein Eingangsposting) Man könnte natürlich sagen dass "from" a "via" Node-aP "to" P usw. die Regel "middle_line=yes" haben kann, aber was für einen Nutzen bringt mir das, wenn ich es direkt auf dem way als Eigenschaft des way taggen kann? Wo siehst Du da Probleme, das richtig zu interpretieren? Die Linie ist halt nunmal da durchgezogen, wo es getaggt ist. Fertig. Falls in der einen Fahrtrichtung nun die Mittellinie durchgezogen und in der anderen gestreichelt ist, dann kann man das doch auch taggen: "solid_line:middle:forward=yes" und "solid_line:middle:backward=no" (in Richtung der Einzeichnung des way bezogen, wie immer bei Verwendung von forward und backward) Bei Relationen könnte man natürlich eine Relation in der umgekehrten Richtung für den "no"-Wert anlegen. Nur ich stelle den grundsätzlichen Nutzen eine Relation in Frage, wenn es sich um die eigenschaften eines way handelt und nciht um die Abbildung einer Regel oder Sachverhalts, die es zu interpretieren gilt. Denn dafür haben wir schon die turn_restriction-Relationen. Noch ein Nachteil der Relationen: Man müsste alle way-Abschnitte (also alle einzelways einer Straße) zu der Relation zusammenfassen, durch die die Mitellinie durchgezogen ist, sonst macht es keinen Sinn. Wir haben schon Probleme, dass Wanderwege-Relationen, ÖPNV-Realtionen usw. nicht zerstört werden. Dann bitte lasst es uns dort unterlassen, so umfangreiche Relationen zu erstellen, wo es auch sehr einfach als way-Eigenschaft direkt getaggt werden kann. Nicht unönötig verkomplizieren bitte. (Bei mehreren Fahrstreifen - und das wird sicher irgendwann kommen - schon wegen der zukünfitgen Routinganfoderungen -müsste man zusätzlich auch nochmal Relationen für diese erstellen - wo führt das hin?) Grüße, steffterra _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de