Am 15.07.2010 um 06:16 schrieb Tirkon:

> steffterra <steffte...@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. ;-). 

>> 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.

>> 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?

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?

>> 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?

> 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? 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 ;-)

Schöne Grüße,

steffterra


_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Antwort per Email an