steffterra <steffte...@me.com> wrote: >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. ;-).
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. _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
