Hallo, Am 2015-04-14 um 19:43 schrieb fly: > Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: >> Am Mittwoch, 8. April 2015, 20:36:13 schrieb Martin Koppenhoefer: >>>> Am 08.04.2015 um 15:17 schrieb fly <lowfligh...@googlemail.com>: >>>> >>>> Warum eigentlich railway: als "name space" ? >>> >>> ich finde so einen namespace dort nicht schlecht, wo es um Spezialistentags >>> geht. Hauptsignale und Ähnliches wird wohl nicht jeder eintragen, und durch >>> den Präfix wird auch demjenigen, der diese Spezialtags nicht alle kennt, >>> schonmal ungefähr ein Kontext vermittelt (Eisenbahn in diesem Fall), ohne >>> dass er gleich die genaue Bedeutung im Wiki recherchieren müsste >> >> Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig >> namespace-Tags begegnen, dann ist es doch leicht anders: >> >> emergency=fire_hydrant >> fire_hydrant:type=underground >> >> railway=signal >> railway:signal:... > > railway:signal:main:state:forward=*
Lass mich raten, das Signal stammt von rayquaza und ist – für OpenRailwayMap-Verhältnisse – schon ewig gemappt? Das sind Versuche, Signale zu mappen, die für verschiedene Richtungen gelten und am selben Mast hängen. Es hat sich nie durchgesetzt (das railway:signal:<TYP>:state:forward/backward=* werten wir nicht aus und wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, der andere für die andere Richtung. > Wenn möglich sollte doch der ein oder andere Tag auch mit weniger > Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). > > state:main:forward=* > > bzw wenn möglich sogar nur > > state=* > height[:TYPE][:DIRECTION] > Eindeutig ist das ganze doch schon durch railway=signal > >> Das macht die Zuordnung "interessiert mich der key" für den Benutzer etwas >> einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der Reihe[1]. > > Welche Benutzer*innen meinst Du ? > > Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen > Schlüssel schon eine Menge Platz aus und die wichtige Information steht > am Ende. > >> Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine >> große >> Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das >> überblicken kann, zu Kollisionen mit anderen Taggings führen würde. > > Wolltest wohl "zu keinen Kollisionen" schreiben > > Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in eckigen Klammern): - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) [distant] - ein Geschwindigkeitsanzeiger [speed] und/oder Geschwindigkeitsvoranzeiger [speed_limit] - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger [route](bei Streckenverzweigungen und mancherorts auch bei Gleiswechseln) - eine Haltetafel [stop] (die mit dem H) - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals [minor]. Für eine vernünftige Erfassung muss man von jedem Signal nicht nur erfassen, was es ist (z.B. Geschwindigkeitsvoranzeiger Zs 3v), sondern auch die Signalisierungsart (Schild, Formsignal, Lichtsignal), die möglichen Signalbilder bzw. anzeigbaren Kennziffern/-buchstaben usw. Das railway:*-Präfix zeigt dem Nicht-Eisenbahnmapper, dass das Tag mit Bahn zu tun hat. Funktioniert bei TMC ja auch (ok, ich lese auch jedesmal die Doku, bevor ich da etwas ändere, tue das aber auch bloß einmal pro Jahr). Viele Grüße Michael Lektüreempfehlung: http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert für Nicht-Bahnaffine. -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
