[Talk-de] Durchgehende Mittellinie

Tirkon tirkon33 at yahoo.de
Sa Jul 17 23:08:00 UTC 2010


steffterra <steffterra at me.com> wrote:

>Am 15.07.2010 um 06:16 schrieb Tirkon:
>
>> steffterra <steffterra at me.com> wrote:
>>> 
>>> 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??? 
>> 
>> Das frage Dich selbst. Denn dass das keine Kreuzung wäre, kam von Dir:
>>>>> steffterra: ... sonst wäre es keine Kreuzung. 
>
>Ja, denn es war meine Argumentation, dass es in einer Kreuzung/Einmündung  eben _keine durchgezogenen Mittellinien gibt_! Verstehst Du. Das hast Du mit Deinen Zeichnungen versucht zu widerlegen und dabei kam heraus, dass es sich um Sonderfälle _in_ Parkhäusern handelte. ;-). 

Seufz! Irgendwie geht jetzt Deine Interpretationsphantasie mit Dir
durch. Ich habe weder versucht zu belegen, dass das eine Kreuzung ist,
noch dass es keine Kreuzung ist, weil es mir schnurzpiepegal ist.
Darum widerspreche Dir selbst weiterhin oder auch nicht und diskutiere
das mit Dir selbst aus. Und frage mich nie mehr, warum das keine
Kreuzung ist, wenn ich es als Zitat von Dir wiederhole. ;-)

>>> 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. ;-)
>> 
>> Ich hatte schon beim Schreiben des Postings sinniert, wo ich es
>> gesehen habe. Ich wusste nur, dass ich es gesehen habe. Der mich dann
>> drauf gebracht hat, warst dann Du.
>
>Gern geschehen. :-)
>
>> Es war tatsächlich im Parkhaus.
>
>Wie gesagt, es gibt keine durchgezogenen Mittellinien in Kreuzungen, damit ist Deine Argumentation, dass es über eine Relation abgebildet werden muss (wegen der Kreuzungen/Einmündungen/etc. wäre es nötig meintest Du) hinfällig.

Wieso das? Sind Parkhäuser kein Beispiel? Und wer sagt, dass es sie
außerhalb nicht gibt? Mir fällt bloß momentan kein konkretes Beispiel
ein, an dem die durchgezogene Mittellinie außerhalb des Parkhauses von
drei Seiten kommt aber nur für eine Relation durchgeht. Ansonsten gibt
es durchgezogene Mittellinien an Abzweigungen zuhauf und ich habe
schon in meinem Ursprungsposting die Hauseinfahrten genannt. 

>>> Aber ich verstehe immer weniger, warum Du die durchgezogenen Mittellinien (um bei diesen Beispielen zu bleiben) hier über Relationen abbilden möchtest? 
>> Möchte ich ja nicht und hatte ich auch geschrieben: "Auch ich würde
>> gern auf die Relation verzichten und nur Tags benutzen." 
>
>Würdest - Du meinstes, dass es nicht in jedem Fall ginge. Und ja ich gebe Dir Recht im Falle von "Kreuzungen" _in_ Parkhäusern geht es nicht. Da müssten (sofern ein Tagging dort einmal möglich wird) turn_restrictions ausreichen und taggen kann man es trotzdem am way zwischen den nodes, die es betrifft. Auch kein Problem, oder?
>
>>                    //   /   //
>>                   //   /   //
>>                  //   b   //
>> =================    /   //
>>                     /   //
>> ---------a---------P   ||
>>                         \\
>> =================    \   \\
>>                  \\   \   \\
>>                   \\   c   \\
>>                    \\   \   \\
>>                     \\   \   \\
>> 
>> gerendert so aussähe:
>>                    //   /   //
>>                   //   /   //
>>                  //   b   //
>> =================    /   //
>>                         //
>> ---------a------       ||
>>                         \\
>> =================    \   \\
>>                  \\   \   \\
>>                   \\   c   \\
>>                    \\   \   \\
>>                     \\   \   \\
>> 
>> Die ununterbrochene Mittelinie zwischen a und b über den Punkt P
>> hinweg fehlt. Jetzt klar?
>
>klar, aber woher weisst Du, dass es so gerendert werden würde? mache die nodes so, wie weit die durchgezogene Mittellinie geht und gut. Wenn die durchgezogene Mittellinie vorher aufhört, dann mache vorher einen node und wenn sie erst am kreuzungsnode aufhört, muss der Rednerer das auch so rendern.
>
>>> 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.
>> Ich hoffe, die obige Zeichnung, welche den Realzustand mit der
>> gerenderten Version zeigt, hat die Sache klar gemacht. Du hast mir
>> immer noch keinen Weg genannt, mit dem die ununterbrochene Linie
>> zwischen a und b im obigen Beispiel auch über den Punkt P hinweg
>> korrekt in einer Karte gerendert würde.  
>
>Gerendert "würde" es vom node bis zum node, auf dem way, auf dem es getaggt wird. Dann tagge es doch auf dem way a bis zum node P und auf dem way b vom node P bis zum node am Ende von b. Dann hast Du eine durchgezogene Linie vom way a über node P und auf dem way b. Wo ist das Problem für Dich? Dein Punkt "P" ist doch exkat der Mittelpunkt der Kreuzung. Also ist es der gemeinsame node von way "a", way "b" und way "c", oder etwa nicht? Vlt. ist Dein Beispiel ungünstig und Du kannst es uns/mir über eine andere Herangehensweise erklären?

Du meinst also, dass man auf dem way, auf dem die Mittellinie nicht
durchgeht, künstlich ein kleines Stück ohne Mittellinie einfügen
sollte, obwohl die bis zum Rand der Querfahrbahn durchläuft? 

>Außerdem: Derzeit wird gar keine Mitellinie gerendert, da auch keine Fahrspuren, parking_lanes, bicycle_lanes, etc. gerendert werden. Das muss das Rendering lösen, nicht das tagging. Klar kann der Renderer nur das rendern, was an Tags vorhanden ist. Aber wenn bis zum node getaggt ist, wieso meinst Du dann, dass es nicht bis zum node auch gerendert würde??? Dein Renderingbeispiel ist doch fiktiv, oder hast Du einen Beispiellink in Mapnik/Osmarender für mich? Wenn es auf dem Beispiellink genau so falsch gezeigt wird, dann rendert der Renderer falsch, oder?

Ich habe versucht, Dir in Bildern das Problem zu illustrieren. Das
scheint bei Dir aber nicht gut anzukommen. Daher jetzt noch
detaillierter: Straßen werden auf OSM mit einer gewissen Breite
dargestellt. Sie würden als unendlich dünne Linie nicht wahrgenommen
werden können. Ergo erweitert sich der Punkt P in seiner Darstellung
rundweg auf einen Punkt mit dem Durchmesser der Breite einer Straße,
wenn sich zwei "Breiten" schneiden. Ist also Punkt P weder mit "solid"
getaggt (oder in eine solche Realtion aufgenommen), fehlt
sinnvollerweise die Mittellinie auch über die Dicke des Punktes, da
sie als unendlich kleiner Lücke nicht wahrgenommen werden kann. Ergo
wird ein sinnvoller Renderer einen Punkt P, der nicht mit "solid"
getaggt ist oder zu solch einer Relation gehört, die Mittellinie über
die Breite des Punktes nicht taggen. Dies entspricht der Realität, wo
die Mittelinie entweder unmittelbar vor der Kreuzung unterbrochen ist,
wenn man abbiegen darf oder durchgeht, wenn man nicht abbiegen darf.
Ähnliches gilt für eine einseitige Überfahrerlaubnis, die in der
Realität auch nicht unendlich schmal ist.

>>> 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)
>> 
>> Das forward und backward ist übrigens auch noch ein Problem. Anfänger
>> interpretieren sie als Fahrtrichtungsangabe und sehen sie daher nur
>> für Einbahnstraßen und Kreisverkehre als relevant an.
>
>Da hilft nur Doku-Lesen - wie bei so vielem und OSM wird nicht einfacher werden. Und eines verspreche ich: wenn wir hier durch sind, mache ich einen gescheiten Wiki-Eintrag, mit vielen Beispielen für JOSM und analog dazu mit Zeichnung/Foto der Wirklichkeit. Das mache ich so wasserdicht, dass es eben keine Missverständnisse mehr gibt. Denn die Mittellinie, die die Fahrtrichtungen trennt ist nunmal keine Linie, die zwei Fahrspuren einer gemeinsamen Richtung trennt und dafür gibts auch noch keine Tags, aber ein Proposal von mir, das die durchgezogene Mittelline ergänzt.

>> JOSM kehrt in
>> manchen Fällen die Richtung automatisch um.
>
>Aber nicht ohne Rückfrage, oder?

Aber irgendwo machen Anfänger mal ihre ersten Gehversuche. Und da
bleibt die "Fahrtrichtung" beim ersten Probieren mal leicht in der
falschen Richtung, weil sie vermeintlich nur bei Einbahnstra0e und
Kreisverkehr gilt. Bis man dann bestürzt wahrnimmt, dass die Richtung
auch noch im fortgeschrittenen Tagging eine Rolle spielt, hat man
schon mehrere Stra0en umgedreht.  

>> Besser wäre es vielleicht
>> daher, wenn die Straßenrichtung beim Neuerstellen eines Ways von der
>> Datenbank festgelegt würde und nicht umkehrbar wäre. Dabei bleibt sie
>> zwischen zwei Knotenpunkten immer gleich



>Und was machst Du wenn sich die Richtung einer Einbahnstraße ändert? 

Dasselbe was Du dann beim ersten Richtungtagging einer Einbahnstraße
machst: Je nachdem ob sie gegen oder mit der von der Datenbank
festgelegten Richtung läuft, tagst Du forward oder backward.

>Ich glaube Du bist bei einer Grundsatzdiskussion über Schreibrechte für gewisse Eigenschaften und sog. Userleveln/Editierrechten angelangt. Lassen wir das bitte in diesem Thread ;-)

Mit forward und backward im Gepäck wird Dir gar nichts genommen und
Userlevel und Schreibrechte sind nicht notwendig. Worin kann der Sinn
einer Funktion liegen, wenn damit viele sorgfältig zusammengetragene
richtungsabhängige Tags und Relationen auf einer (langen) Straße
umdrehen kann und die nach Anwendung beim Drüberschauen auch sehr
schlecht auffällt, so dass der Fehler sehr schlecht erkannt wird.
Diese (dusslige) Umkehrfunktion zieht einem gebauten Haus sozusagen
den Boden unter den Füßen weg. Schlimmer noch: Was ist, wenn nach
einer versehentlichen Änderung jemand Anderes richtungsabhängige Dinge
taggt. Dann sind die einen richtig herum und die anderen falsch. Wer
will die Straße wieder komplett abfahren, um jedes einzelne Tag und
jede einzelne (beschädigte) Relation zu überprüfen und wieder ins
rechte Lot zu bringen? - und das wegen eines versehentlichen Klicks? 

Nein, es für die Umkehrfunktion keine einzige sinnvolle Anwendung
außer Vandalismus. Wenn der dann auch noch - insbesondere für Anfänger
- so leicht versehentlich begangen werden kann, dann hat die Funktion
jede Daseinsberechtigung verloren - und zwar für jeden User. Daher
brauchen wir in diesem Zusammenhang nicht über Userlevel und
Schreibrechte nachzudenken.

Ich mache mal einen eigenen Thread dazu auf.





Mehr Informationen über die Mailingliste Talk-de