Am 14.04.2015 um 21:13 schrieb Michael Reichert: > Am 2015-04-14 um 19:43 schrieb fly: >> Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: >>> 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?
Nein, nur meiner Logik entsprungen. > 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. Habe ich das im Wiki überlesen ? Welche Gründe sprechen denn dafür ? Mapped Ihr dann auch noch den Masten ? Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher komplizierter. Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir können jedes Signal einzeln eintragen. Sehe ähnliche Probleme auch beim Mirkromappen von traffic_sign und traffic_signal, wo es wohl über kurz oder lang auch Relationen bedarf, wenn ich zB mehre Zeichen übereinander an einer Straßenlaterne befinden und ich die Höhe (height) eintragen will. >> 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]. Was war denn jetzt an meinen Vorschlägen jetzt falsch ? state:main:forward=* resp. state:main=* height[:TYPE][:DIRECTION] resp. height[:TYPE] Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? (railway:signal:main:state=*) > 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. Und genau da frage ich, welche anderen Tags sollten den an so einem Punkt noch vorhanden sein, welche sich nicht auf railway=signal beziehen ? Mir fällt da nur so was wie man_made=mast/pole ein, aber wir taggen ja nicht die exakte Position. > 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). TMC ist ja wohl ein Beispiel, das ich lieber nicht erwähnen würde. Das neue Schema sieht da schon besser aus, allerdings bin ich auch noch nicht dazu gekommen es richtig auszuprobieren. > 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. Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und versuche dann mein Glück Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen. Habt Ihr mal die Möglichkeit Tags an die Linien (railway=*) zu setzten gedacht, so wie wir das auch bei Straßen mit maxspeed, maxheight und ähnlichen Verkehrschildern machen ? Ciao fly _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
