Laufendes Proposal "direction"

Derzeit läuft die Abstimmung für das Proposal direction. Das Proposal wurde in der letzten Wochennotiz schon verlinkt. Da sich aber noch nicht viele beteiligt haben, obwohl die Frist nur bis Sonntag läuft, möchte ich hier noch einmal dafür werben.

Das Proposal schlägt vor, ein Tag “direction” einzuführen, das an Nodes und Areas zur Angabe der “Richtung” des getaggten Objekts dient - gemeint ist z.B. die Tür einer Telefonzelle, die beschriftete Seite einer Werbetafel, die Vorderseite einer Sitzbank oder die Blickrichtung an einem Aussichtspunkt.

Als Werte sollen möglich sein:

  • Gradangabe zwischen 0 und 360 Grad, gerechnet ab Nord im Uhrzeigersinn

  • Abkürzungen für die Himmelsrichtungen für grobe Angaben (z.B. “N” oder “SW”)

  • ausgeschriebene Himmelsrichtungen

Gerade die letztere Möglichkeit wird von einigen Abstimmenden verständlicherweise als redundant angesehen. Falls das der einzige Punkt ist, der euch stört, würde ich vorschlagen, dies im Abstimmungskommentar anzumerken.

Alternativvorschläge, die Richtung etwa über eine Relation mit zwei Knoten zu modellieren, halte ich für übermäßig komplex. Das gilt auch für die in den Begründungen zu Gegenstimmen ebenfalls genannte Modellierung der Objekte als Way - man kann selbstverständlich eine Bank auch als Way einzeichnen und sich darauf einigen, dass z.B. die Lehne immer links ist. Allerdings wäre das für viele der betroffenen Objekte eine Änderung der derzeitigen Tagging-Praxis und damit meiner Meinung nach mehr Aufwand, als der beschränkte Nutzen des Richtungs-Mappings rechtfertigt.

Die Idee des direction-Tags sehe ich hingegen als einfache und praxistaugliche Lösung, die daran nicht interessierte Anwendungen nicht weiter stört. Das Tag ist sher vielseitig einsetzbar - bei welchen der denkbaren Einsatzzwecke es dann tatsächlich Verbreitung findet, bliebe der Detailverliebtheit der Mapper überlassen.

Apropos Detailverliebtheit - zur Motivation gibt’s hier noch ein paar 3D-Bänke mit direction- und backrest-Tags. :wink:

Sorry, aber dieses Proposal ist so etwas von grausam vorbereitet. So etwas sollte IMHO erst gar nicht zur Abstimmung zugelassen werden.

Proposals sollten schon einige Monate vor der Abstimmung eine vollständige und verständliche Wiki Beschreibung mitbringen, die auch von Otto Normalmapper verstanden werden kann. Erst dann kann eine Diskussionsphase beginnen. In diesem Proposal ist beispielsweise nicht ein einziges konkretes Objekt mit seinen Taggings aufgeführt. Ferner sind nicht die Vor- und Nachteile zu alternativen Methoden wie etwa der Richtungsrelation aufgeführt.

Wir nähern uns bei OSM immer mehr einem Proposaldickicht, das kaum jemand mehr zu überschauen vermag. Wikipedia macht es vor, wie sehr User mit solchen Regelwerken vergrault werden, die nur wenige ausgeheckt haben. Es macht doch keinen Sinn, hier immer abenteuerlichere Dinge regeln zu wollen, die nur von wenigen Spezialisten verstanden, besprochen und abgestimmt werden. Folglich hält sich niemand daran. Eine weitere Folge ist, dass man viele Objekte nicht mehr anfassen mag in der Sorge, etwas an dem undurchdringlichen Wust von Taggings zu zerstören. In vielen Fällen kann man nicht mehr unterscheiden, ob nun etwas fehlerhaft getaggt ist oder ob es noch an Verständnis für die Sache fehlt.

Daher empfehle ich, die Abstimmung abzubrechen und zunächst eine anfängertaugliche Wiki-Beschreibung zu erstellen. Mindestens fünf verschiedene Objekte sollten dabei mit Fotos oder Bildern illustriert sein mit kompletten Tagging dazu. So kann auch Otto Normalmapper verstehen, worüber überhaupt abgestimmt werden soll. Dann kann man erneut in die Diskussionsphase eintreten, an der dann potentiell auch Otto Normalmapper teilhaben kann, um frühestens in einem halben Jahr mit der Abstimmung zu beginnen.

Proposals machen keinen Sinn, wenn sich beispielsweise nur 20 Personen daran beteiligt haben.

Zuletzt noch zum Inhalt des Proposals an sich:

Die ganze Sache mit dem “face” ist doch sehr fragwürdig und in vielen Fällen vom persönlichem Empfinden abhängig. Insofern dürfte es da jede Menge Missinterpretationen geben.

Bei einem (Stop)schild sind viele eher geneigt, die Fahrtrichtung anzugeben, als die “face”-Richtung. Und wo ist das “face” eines Ortsein/ausgangsschildes? Gerade bei Straßenschildern sind oft nur zwei Richtungen möglich. Es würde also vollkommen die Angabe ausreichen, in welche der beiden möglichen Richtungen das Schild weist. Bei der Lösung laut Proposal muss man sich jedesmal eine Gradzahl sowie deren “face”-Seite und deren Bezug auf die aktuelle Lage der Straße vergegenwärtigen. Man kennt ähnliche Dinge etwa aus Eignungstest. Das ist vollkommen inpraktikabel und nichts für eine große Masse von Mappern.

Insgesamt sowohl vom Inhalt als auch von der Durchführung des Proposals - sorry - für die Mülltonne.

Gruß
Tirkon

Das kann doch garnicht sein, denn den Tag “direction” gibt’s ja schon.
http://wiki.openstreetmap.org/wiki/Key:direction

Dann findet man auch noch Jenes:
http://wiki.openstreetmap.org/wiki/Proposed_features/lane:x:direction
http://wiki.openstreetmap.org/wiki/Relation:direction

Den bestehenden Tag um Werte zu ergänzen o.k., aber nicht doppelt und dreifach!
…und um bestehende Werte zu ergänzen bedarf es doch sicherlich nicht eines Proposals?

Mangelnde Beteiligung mag wohl auch daraus resultieren, dass der User wieder mal vergaß das Proposal an der korrekten Stelle zu veröffentlichen.
…oder wozu gibt’s die Seite http://wiki.openstreetmap.org/wiki/Proposed_features ?

mfG Michael

Wenn du die Regeln für Proposals nicht magst, die keineswegs ein halbes Jahr, sondern nur 2 Wochen Diskussionsphase fordern, dann kann man darüber sicher diskutieren. Es ist aber diesem Proposal doch nicht vorzuwerfen, dass es sich einfach an die derzeit üblichen 2 Wochen gehalten hat.

Die Qualität der Illustration finde ich ausreichend, um die Idee des Proposals zu verstehen. Insbesondere die Zeichnungen sind in meinen Augen durchaus hilfreich. Fotos wären im konkreten Fall doch eher sinnlos, weil man dort ja Himmelsrichtungen in der Regel gar nicht erkennen kann. Solltest du einen Vorschlag haben, wie man Fotos einsetzen kann, um die Erklärungen zu verbessern, wäre das sicher nützlich für die Dokumentationsseite. Die Wiki-Beschreibung erstelle ich gern, wenn das Proposal angenommen wurde - dann auch mit Beispielen und deutscher Übersetzung.

Wenn es um die Richtung von Verkehrsschildern geht, kann man auf die Richtung der Straße Bezug nehmen. Bei vielen anderen Objekten, die nicht an eine Straße gebunden sind, geht das aber nicht. Mir geht es hier um diese anderen Objekte, und dem Proposal-Autor sicherlich auch - denn er hat gleichzeitig das Relation:direction-Proposal zur Abstimmung gegeben, das er als “für Verkehrsschilder geeignet” bewirbt.

Es gibt “direction” als Zusatztag für Mini-Roundabouts. Das steht nicht in Konflikt zu diesem Proposal, das “direction” als Zusatztag zu ganz anderen Objekten einführen will.

Relation:direction ist das Alternativ-Proposal mit einer Relation aus zwei Nodes, das ich in meinem Eingangspost kurz angesprochen habe. Das ist auch im direction-Proposal unter “See Also” verlinkt.

Aber was hat das eingeschlafene lane:x:direction mit dem Thema zu tun (außer, dass das Wort “direction” darin vorkommt)?

Das Proposal wurde auf der Tagging-Mailingliste angekündigt und war - für die, die keine Mailinglisten mögen - wie bereits erwähnt auch in Wochennotiz #58 verlinkt.

Bei mindestens zwei verschiedenen “direction”-Zusatztags soll’s keinen Konflikt geben?
Das wage ich aber zu bezweifeln.

Das mag aber nur für Deutschland gelten, oder gibt’s die Wochennotiz noch in einer internationalen Version, was mir bisher entging?

Ich habe dafür gestimmt, weil ich ein Tag für die Richtung grundsätzlich gut finde. Ich mappe viele Höhlen und das ist ein gutes Beispiel, wo man so was brauchen kann. Außerdem passt die Syntax gut zu jener, die ich mir für viewpoint_direction=* wünsche. (Die Syntax dort muss allerdings eine Übermenge sein, da dort Bereichsangaben nötig sind, z.B. “15-120,180-270”).

Einige Bedenken habe ich trotzdem, und ich nütze diesen Thread um sie anzuführen:
1.) Der Keyname ist strittig: Vielleicht nicht das richtige Vokabel (siehe Kommentar von Brycenesbitt auf Talk-page), und schon für was anderes in Verwendung. Es ist immer gefährlich, wenn die Bedeutung eines Tags von anderen Tags abhängt. Manchmal kommt es zu Kombinationen, mit denen man nicht gerechnet hat.
2.) Die Windrichtung ist die Richtung, wo der Wind herkommt. Bei Meeresströmungen gibt man hingegen die Richtung an, wo die Strömung hingeht. Das zeigt, dass es für jede Richtungsangabe 2 Möglichkeiten gibt. Z.B. bei einer Höhle kann man die Richtung angeben, wie man herausschaut oder wie man hineinschaut. Höhlenkundige geben üblicherweise ersteres an, aber Höhlenunkundige wissen das nicht. Und bei vielen anderen Objekten gibt es überhaupt keine Konvention.
3.) Einige im Proposal angeführten Beispiele sind schlecht gewählt: Bei Cliffs wird die Richtung bereits über die Linienrichtung definiert, bei “a view” ist ein eigener Tag viewpoint_direction=* nötig, und bei “sign” gibt es die bei den Verkehrszeichen angesprochenen Probleme.
4.) Die Skizze bei “Point features” sieht nach Kindergekritzel aus, das macht keinen guten Eindruck. :wink: Zverik sollte es doch schaffen, sich einen Gimp oder Inkscape herunterzuladen?
5.) Die Windrose zeigt Richtungen wie NNW, die nicht zu den kardinalen zählen und daher laut verbaler Beschreibung gar keine zulässigen Tagwerte sind.

Bei Vorwegweisern vor Autobahnausfahrten sind sogar 3 Richtungen möglich: Die Richtung zur Ausfahrt (d.h. vorwärts), die Richtung der Ausfahrt selber (d.h. nach rechts) und die “face”-Richtung (d.h. rückwärts).

Ich bin sowieso dagegen, Verkehrszeichen zu mappen.

hab dort auch meinen senf dazugegeben. meiner meinung nach werden hier fälschlicherweise unterschiedlichste values in einen topf geworfen, die nicht zusammengehören. während “forward/both/backward” eher zur beschreibung von access restrictions verwendet werden, beschreiben die meisten anderen werte wiederum die physische ausrichtung eines elements. spätestens wenn man mal in verlegenheit kommt, beide informationen auf ein element mappen zu müssen, wirds problematisch. darum plädiere ich mal wieder für den access namespace, dann könnten “direction” und “access.direction” in frieden nebeneinander koexistieren.

Prinzipiell richtig. Die Frage ist allerdings welche Alternative besser wäre. Brycenesbitt hat “heading” vorgeschlagen. Laut Wikipedia bedeutet das “the direction a person or vehicle is facing, usually similar to its course”. Dieser Definition nach passt es hier nicht so ganz. Ich könnte mir auch “facing” vorstellen - aber meine Sprachkenntnisse reichen nicht aus, um das abschließend zu beurteilen

Zu deinen Punkten 2 und 3: Beides korrekt, das eine Problem hatte ich ja selbst schon auf der Proposal-Talk-Seite angedeutet. Es läuft aber, denke ich, ohnehin darauf hinaus, dass man die jeweilige Konvention beim Haupt-Tag dokumentieren muss.

Hm, auch richtig, aber sicher ein leicht zu behebendes Formulierungsproblem. Ich habe das mal auf der Talk-Seite zum Proposal angesprochen.