destination:...-tags

Jojo4u · 2016-10-09 12:49:12

mueschel wrote:

Ich hätte diese Dinge am liebsten direkt mit in das Proposal von Imagic aufgenommen.

Imagic möchte das nicht und schlägt vor ein neues Proposal aufzumachen (https://wiki.openstreetmap.org/w/index. … id=1132467)

Peilscheibe · 2016-10-10 20:39:01

Mal ne Frage zur Datenmodellierung: Die Ziele eines ways oder einzelner Fahrspuren am way zu taggen ist ja prima, das sind Attribute des ways. Aber warum bitteschön sollten Attribute des Wegweisers (hier: Platzierung/Zuordnung von Piktogrammen zu Zielangaben/Zeilen) am way modelliert werden und nicht an einem Objekt, das den Wegweiser beschreibt?

P.

Jojo4u · 2016-10-10 22:15:17

Peilscheibe wrote:

Mal ne Frage zur Datenmodellierung: Die Ziele eines ways oder einzelner Fahrspuren am way zu taggen ist ja prima, das sind Attribute des ways. Aber warum bitteschön sollten Attribute des Wegweisers (hier: Platzierung/Zuordnung von Piktogrammen zu Zielangaben/Zeilen) am way modelliert werden und nicht an einem Objekt, das den Wegweiser beschreibt?

Ich versuche darauf im Wiki einzugehen:

https://wiki.openstreetmap.org/wiki/Proposed_features/More_destination_details wrote:

Important: The scope of destination=* and it's subkeys is to support routing. A "photo-realistic" rendering of traffic signs, especially the geometry of entries on the sign - is not the scope of destination tags on ways.

Ref, Farbe und Symbole unterstützen meines Erachtens bei der Darstellung von Zielen. Die Pfeile sehe ich auch eher bei der Darstellung von Schildern, also nicht auf dem Way sondern auf dem Schild. Für die Unterstützung beim Abbiegen gibt es die Richtungspfeile auf der Straße, also turn(:lanes)=*

mueschel · 2016-10-11 09:15:59

Jojo4u wrote:

mueschel wrote:
Ich hätte diese Dinge am liebsten direkt mit in das Proposal von Imagic aufgenommen.
Imagic möchte das nicht und schlägt vor ein neues Proposal aufzumachen (https://wiki.openstreetmap.org/w/index. … id=1132467)

Ich hatte das eher so verstanden, dass er nicht möchte, dass Änderungen an seinem Proposal einfach eingefügt werden. Aber das kann nur er selbst sagen.

Ein weiteres Proposal aufzumachen halte ich nicht für sinnvoll. Ich versuche gerade, eine Übersicht zu schreiben die beschreibt welche Methoden es gibt und wie sie eingesetzt werden. Also eher eine Beschreibung von "state of the art" als ein weiteres Proposal, das dann wieder jahrelang ohne Abstimmung rumliegt.

mueschel · 2016-10-11 09:20:32

Peilscheibe wrote:

Aber warum bitteschön sollten Attribute des Wegweisers (hier: Platzierung/Zuordnung von Piktogrammen zu Zielangaben/Zeilen) am way modelliert werden und nicht an einem Objekt, das den Wegweiser beschreibt?

Genau das wird gemacht mit der Relation type=destination_sign. Auf die eine odere andere Weise muss der Wegweiser ja den einzelnen Wegen / Spuren zugeordnet werden. Nur über Tags am Schild geht es nicht, und für viele sind die Relationen (berechtigterweise) zu aufwendig und komplex. Als Lösung bleibt das Taggen direkt am Weg wie es jetzt gemacht wird.

Im Prinzip ist es ja nicht anderes als maxspeed auch - wir taggen es am Weg, obwohl es ja eigentlich an ein Schild-Objekt gehört und genau wie destinations Auswirkungen auf die Straße hat.

mueschel · 2016-10-14 21:29:03

Ich habe hier mal alles was es an destination*=* im Augenblick gibt zusammengefasst.
https://wiki.openstreetmap.org/wiki/Use … ionTagging

Beispiele, die auf den anderen Wikiseiten fehlen braucht es natürlich noch. Anmerkungen & Verbesserungen sind natürlich willkommen.

Peter Maiwald · 2016-10-15 16:00:39

Ich versuche gerade den Prozess zu verstehen, den wir gehen müssen, um die hier erarbeiteten Vorschläge ins Wiki zu bekommen. Stimmt das so, wie ich das verstehe? Bitte korrigiert mich.

1. Um diese, in diesem Forumsbeitrag überlegten Änderungen ins Wiki zu bekommen, benötigen wir einen Abstimmungsprozess?

2. Es existiert bereits ein Proposal, welches einige Elemente des jetzigen Vorschlags enthält. Der Ersteller (Imagic) möchte aber keine Erweiterung seines Vorschlags und seit Vorschlag existiert seit 2012 und ist immer noch nicht abgestimmt. Siehe hier: https://wiki.openstreetmap.org/w/index. … id=1132467

3. Um unsere jetzigen Vorschläge ins Wiki zu bekommen benötigen wir also einen extra Vorschlag? Jojo4u hat diesen vorbereitet: https://wiki.openstreetmap.org/wiki/Pro … on_details

4. Jetzt müssten doch eigentlich alle noch nicht abgestimmte Elemente, die mueschel hier sehr ausführlich beschreibt: https://wiki.openstreetmap.org/wiki/Use … ionTagging in das neue Proposal hier: https://wiki.openstreetmap.org/wiki/Pro … on_details

5. Wie zeitnah kann so ein Abstimungsprozess umgesetzt werden, damit der Vorschlag nicht auch 4 Jahre rumliegt?

6. Gibt es Alternativen, um diesen Vorschlag zu etablieren und ins Wiki zu bekommen?

Einige Teile des Vorschlags sind anscheinen schon im deutschen Wiki zu finden:
https://wiki.openstreetmap.org/wiki/DE: … ion:symbol
https://wiki.openstreetmap.org/wiki/DE: … nation:ref

mueschel · 2016-10-15 16:23:29

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele "Spezial-Tags", und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit "nein" stimmen mit Begründungen wie "wer braucht das schon".

Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht "approved" sind.

Peter Maiwald · 2016-10-15 17:11:43

mueschel wrote:

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele "Spezial-Tags", und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit "nein" stimmen mit Begründungen wie "wer braucht das schon".
Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht "approved" sind.

Sehr schön. Die von dir beschriebene Vorgehensweise gefällt mir schon viel besser.
Von den Abstimmungen und den beschriebenen Problemen dabei weiß ich schlichtweg zu wenig, um eine Einschätzung abzugeben. Evtl. sind diese Probleme ja auch dafür verantwortlich, dass die Vorschlagsseite von Imagic in seinem Status verharrt.

Peter Maiwald · 2016-10-16 11:33:18

Ich habe noch einen Sonderfall gefunden, bei dem noch irgendetwas nicht richtig zu sein scheint:

Hier das Foto vom Schild:
https://www.mapillary.com/app/?focus=ph … 29668&z=17

So ist es getaggt:
https://www.openstreetmap.org/way/24598 … 7/13.43007

Und so sieht es in der Auswertung aus:
http://osm.mueschelsoft.de/cgi-bin/rend … country=de

Das Problem ist die rechte Spur, die geradeaus und rechts fahren erlaubt. Geradeaus ist jedoch keine Ziel angegeben (destination:lanes) aber ein destination:ref:lanes=B 109;; (mal nur diese Spur betrachtet). Damit das ref nicht in dem Slot für das erste Ziel rechts erscheint habe ich bei destination:lanes noch ein ; vor den beiden Zielen für Rechtsabbieger eingefügt (für die Geradeausspur mit destination:ref:lanes=B109;; dieser Spur). Das ref sollte dann mit destination:arrow:lanes=through;right;right in dem Slot von through sein.

In der Auswertung mit mueschels OSM Lane Visualizer landet dann aber der Pfeil für geradeaus nicht neben dem ref B 109, sondern in einer extra leeren Zeile.
http://osm.mueschelsoft.de/cgi-bin/rend … country=de

Wo ist der Fehler?

mueschel · 2016-10-16 12:01:42

ref's werden noch nicht "geslottet", die tauchen im Augenblick immer unten auf. Ich werde das demnächst mal ausprobieren, ob das funktioniert oder zuviele falsche Darstellungen bei "normalem" Tagging ohne Slots verursacht.

Jojo4u · 2016-10-22 16:03:24

mueschel wrote:

Ich hatte das eher so verstanden, dass er nicht möchte, dass Änderungen an seinem Proposal einfach eingefügt werden. Aber das kann nur er selbst sagen.

Seine Aussage dazu ist eindeutig: Please write your own proposal if you are not satisfied with this one. I do not propose the colour subkey.

Jojo4u · 2016-10-22 16:14:18

mueschel wrote:

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele "Spezial-Tags", und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit "nein" stimmen mit Begründungen wie "wer braucht das schon".
Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht "approved" sind.

Ich stimme zu. Zum Thema destination: Imagic bringt seine Proposals üblicherweise nicht zur Abstimmung (Voting is bullshit). Sie werden erstellt, getestet, überarbeitet und setzen sich dann durch oder nicht. Der Proposal Prozess ist für komplexe Dinge nicht sehr gut passend da diese sich iterativ entwickeln müssen. Dass abgestimmte Proposals Probleme bereiten (natural=water vs. landuse=reservoir; relation type=parking, PTv2) ist durchaus schon vorgekommen.

Announcement

#51 2016-10-09 12:49:12

Re: destination:...-tags

#52 2016-10-10 20:39:01

Re: destination:...-tags

#53 2016-10-10 22:15:17

Re: destination:...-tags

#54 2016-10-11 09:15:59

Re: destination:...-tags

#55 2016-10-11 09:20:32

Re: destination:...-tags

#56 2016-10-14 21:29:03

Re: destination:...-tags

#57 2016-10-15 16:00:39

Re: destination:...-tags

#58 2016-10-15 16:23:29

Re: destination:...-tags

#59 2016-10-15 17:11:43

Re: destination:...-tags

#60 2016-10-16 11:33:18

Re: destination:...-tags

#61 2016-10-16 12:01:42

Re: destination:...-tags

#62 2016-10-22 16:03:24

Re: destination:...-tags

#63 2016-10-22 16:14:18

Re: destination:...-tags

Board footer