Am 18.07.2010 um 01:08 schrieb Tirkon: > 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.
Das habe ich doch auch, mein bester. Wenn ich nicht so geduldig wäre .... Was versuchst Du überhaupt zu sagen? Deine Zeichnungen belegen, dass man natürlich den way an den Stellen, wo sich die ways treffen direkt so taggen kann. Wieso glaubst Du das denn nicht, dass das geht - Du legst ja auch fest dass der way ein residental ist usw, das geht auch exakt bis dahin wo der Node ist. Es geht genauso exakt, wie die durchgezogene Mitellinie _tatsächlich_ verläuft. Und was Renderer daraus machen, ist nicht das Problem des tagging. Die "müssen" halt für Kreuzungen einen eigenen Lupe/ Zoomlevel einführen, wo das dann gescheit gezeichnet wird. Das wäre doch ein echter Fortschritt für die Renderer. Doch deswegen unterlasse ich doch das taggen nicht! > 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. ;-) Deine Argumentation war, dass es genau an solchen Stellen nicht ginge und Du hast mir solche Kreuzungen sogar aufgezeichnet. Also wo ist Dein Problem. Renderer sind Dein Problem? Dann verbessere die Renderer. Mir ist es auch wurscht, wie Du es nennst, Kreuzung, Einmüdnung, T-Kreuzung, Y-Kreuzung, Abbiegende Vorfahrtstraße, etc.. Das kann alles einwandfrei getaggt werden. Ich sehe da keine Probleme. Du kannst in JOSM sogar metergenau taggen, wenn Du möchtest. Und wenn Die Mittellinie auf zwei Metern bei der Einmündung eben nicht durchgezogen ist, dann machst Du einen Knoten links und einen rechts vom Knoten der Einmündung und tagge dazwischen den "no"-Wert. Wo ist Dein Problem? Jetzt sag nicht der Rednerer! :-) >> 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? Weil die durchgezogene Mittellinie dem Querverkehr verbieten würde weiterzufahren. Deshalb gibt es keine durchgezogenen Mittellinien _in_ Kreuzungen mit vier Straßenanteilen, also die durchgezogene Mittellinie _kreuzt_ niemals eine andere Straße. Das gibt es auch in Parkhäusern nicht. Sonst darf der Querverkehr nicht weiterfahren. Deine Zeichnungs-Fälle sind Einmündungen, bei denen sich die Mittellinie natürlich auch nirgends mit einer anderen Straße kreuzt (nur baulich gesehen, nicht von der Namensgegbung her, die hier völlig unrelevant ist!). Die durchgezogene Mittellinie kann in einer Straße, die einen Bogen macht, natürlich durch diesen Bogen hindurchlaufen, ohne Unterbrechung, klar. Die Straße, die in dieser Kurve einmündet kann auch eine durchgezogene Mittellinie haben. Aber niemals ragt diese bis zum gemeinsamen Mittelpunkt hinein! Sondern sie hört vor der eigentlichen Einmündung (baulich gesehen) auf, weil sie sonst eine Fahrspur der kurvenförmigen Straße kreuzen würde und diesem Verkehr das Weiterfahren verbieten würde. Doch auch das ist einwandfrei taggbar. Wo ist Dein Problem? Die Straßenbreite, die vorgibt, wo die durchgezogene Linie der einmündeneden Straße enden müsste? Schreite sie ab, schätze sie. Es ist der Abstand vom Mittelpunkt der sich treffenden Straßen bis zum Ende der durchgezogenen Linie der einmündenden Strtaße. Aber selbst wenn Du nur eine kleine Unterbrechung zeichen würdest, wären die Konsequenzen für Anwendungssoftware die gleichen. Wichtig ist, dass eine Unterbrechung vorhanden ist, sonst darf man an der Stelle nicht weiterfahren. Wie breit die Unterbrechung ist ist Abiege-Regel-Technisch unerheblich. Es könnte nur wichtig werden, wenn mal Straßenbreiten-Tags von Renderern umgesetzt werden. Doch dann lässt sich so etwas auch schön durch Verschieben des Knotens, an dem die durchgezogene Mittellinie aufhört, wieder korrigieren. Wird schon. > 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. OK - und was hat das jetzt für eine Konsequenz für Dich/mich? Dann tagge die durchgezogenen Mitellinien so, wie sie verlaufen und gut ists. Wieso kann Deiner Meinung nach die durchgezogene Mittellinie dort nicht getaggt werden, bzw. warum sollte das ein Beispiel dafür sein, dass es kein sinnvolles Tagging wäre? Jede Anwendung (Routingsoftware genauso wie Renderer) müssen sie nur so wie in der Wirklichkeit richtig interpretieren. Die Rdnerer mögen das in Zulkunft vlt. durch eien Lupenfunktion für Kreuzungen machen, Routing-Software kann es interpretieren, sobald eingeführt. > 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? Ich meine, dass ich da, wo keine _durchgezogene_ Mitellinie vorhanden ist, den Wert "no" tagge. Was ist falsch daran? Ich verstehe aber obigen Satz nicht. Was meinst Du mit: > Du meinst also, dass man auf dem way, auf dem die Mittellinie nicht > durchgeht, und > obwohl die bis zum Rand der Querfahrbahn durchläuft? Das widerspricht sich doch? Läuft die _durchgezogene_ Mittellinie nun durch, oder nicht? Mit _durchgezogene_ meine ich, dass sie eine einzige Linie ist. Eben die, die verbietet, dass man sie überfahren darf. Sie ist da durchgezogen, wo sie durchgezogene ist und dort wird am entsprechenden way-Abschnitt ein "yes"-Wert getaggt und an dem way-Abschnitt, wo die Mitellinie _nicht_ eine _durchgezogene_ Linie ist, sondern eine unterbrochene, dort Tagge ich den "no"-Wert (nur um yes-getaggte herum, um die dass Bewusste taggen sichtbar zu machen). Was ist daran so schwer zu verstehen? >> 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. Doch ich fand Deine Beispiel gut, weil sie zeigten, dass man die Wirklichkeit sehr gut abbilden kann. Mit abbilden meine ich _nicht_ wörtlich: Dass sich daraus ein gutes "Bild" im Sinne von "Strich auf gelber Fahrbahn" im Renderer ergibt. Sondern ich meinte, dass die Wirklichkeit da genau wiedergegeben werden kann und ich Dein Problem damit nicht verstehen kann. Ich bin ja geduldig, also kein Problem. > 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. Das ist ein Problem der Renderer und nicht des Taggings. Man lässt ja auch Radwege, die nur durch eine Linie von der restlichen Fahrbahn getrennt sind beim taggen nicht weg, nur weil der Render das nicht befriedigend darstellen kann. > 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. Ja und - was hat das mit dem taggen zu tun? Die Darstellung ist das Problem der Rednerer. Andere Anwendungen, wie z.B. Routing-Software kann das durchaus sinnvoll nutzen (es würde auch nicht stören, wenn nicht vorhanden, wenn dann wenigstens die Abbiegeregeln durch turn_restriction-Relationen eingetragen wären.) Aber es ist möglich das einwandfrei zu taggen und genutzt werden kann es auch. >>>> 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. Deshalb Doku lesen und/oder einer örtlichen OSM-Gruppe anschließen und die ersten Gehversuche dort unternehmen. Wenn ich auf taggs stoße, die ich nicht kenne, lese ich nach, was sie bedeuten. Das steht schon in den Verhaltenstips für Neueinsteiger, die sowieso Pflichtlektüre sind. Es gibt noch andere Beispiele wo das eigene Tagging Auswirkungen auf andere Dinge hat. Doku lesen, Doku lesen. Wenn ich an meinem Auto rumschrauben würde, obwohl ich davon keine Ahnung habe ..... Klar, man kann es Anfängern erschweren oder erleichtern. Ich sehe das Taggen der durchgezogenen Mittellinie als einfache Bereicherung an, da sie an bestimmten Stellen (Beispiele wurden im lauf der Diskussion genannt) sogar einen Mehrwert vor Relationen bieten, die nun wirklich erst für fortgeschrittene User geeigent sind. Du argumentierst, dass Neuuser Fehlerquelle sein könnten beim Drehen von Wegen (wegen der Auswirkungen auf forward und backward), schlägst aber unbewusst vor, an diesen Stellen Abbiegerelationen zu erstellen, denn das wäre die Konsequenz ... Auch da wird er sich Hilfe holen oder die Doku sehr genau lesen müssen. So wie ich auch, als ich darauf das erste mal sties. >>> 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. Die Richtung in der Du in JOSM zeichnest, also wo Du Deine Maus zuerst ansetzt gibt die Richtung vor. Wie soll JOSM wissen, dass es die Richtung anders herum zeichnen (vorgeben) muss. Und ab welchen Winkeln (wir können in 360°-Winkeln Richtungen einzeichnen), legst Du fest wie herum die Richtungen verlaufen müssen? Neee, lassen wir das. Ausserdem ist es offtopic. >> 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 ;-) > Ich mache mal einen eigenen Thread dazu auf. Deshalb äußere ich mich jetzt nicht hier weiter darüber :-) Ich wünsche eine schöne Woche, steffterra _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
