Openrailwaymap February 2015

openrailwaymap@openrailwaymap.org

1 participants
4 discussions

priority-Tag
by Merle Roßner 23 Apr '15

23 Apr '15

Hallo, inzwischen ist wieder einiges bei uns passiert: Wir werden jetzt die Relationen an den Schienen auswerten und dementsprechend nicht mehr den Tag priority setzen. Viele Grüße Merle von MentzDV

3 2

Kennlicht-Tagging
by Michael Reichert 18 Feb '15

18 Feb '15

Hallo, auf dem Aktiventreffen in Bad Nauheim haben wir entschieden, dass wir railway:signal:SIGNALTYP:marker_light=yes/no durch den zusätzlichen Value-Eintrag "DE-ESO:kennlicht" in railway:signal:SIGNALTYP:states=* ersetzen. https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014_2… https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014_2… Als ich es gerade eben in die JOSM-Objektvorlage einbauen wollte, fiel mir ein, dass es keine gute Idee ist, auf railway:signal:SIGNALTYP:marker_light=yes/no zu verzichten. Es ist zwar logischer, das Kennlicht als gleichberechtigtes Signal neben Hp 0, Hp 1 (oder was auch immer das Signal anzeigen kann) aufzunehmen, wir vernichten mit einer Abschaffung von railway:signal:SIGNALTYP:marker_light=* jedoch Informationen. Bisher gibt es drei verschiedene Informationszustände in OSM, die ein Signal haben kann (1) railway:signal:SIGNALTYP:marker_light=yes, d.h. das Signal kann Kennlicht zeigen (2) railway:signal:SIGNALTYP:marker_light=no, d.h. das Signal kann kein Kennlicht zeigen (3) railway:signal:SIGNALTYP:marker_light=* nicht getaggt, d.h. es ist unklar Künftig gibt es nur noch zwei Informationszustände. Entweder enthält das railway:signal:TYP:states=* den String "DE-ESO:kennlicht" oder nicht. Wir können also künftig nur noch eine der beiden folgenden Aussagen treffen: (1) Signal kann Kennlicht zeigen (2) Signal kann nicht Kennlicht zeigen oder es ist unklar Im neuen Taggingschema kann man jedoch nicht zwischen "nicht möglich" und "unklar" entscheiden. Das ist in OSM nicht üblich. In OSM können wir meistens zwischen drei Fällen unterscheiden – ja, nein und unklar. Daher schlage ich vor, railway:signal:SIGNALTYP:marker_light durch das internationalere railway:signal:SIGNALTYP:disablement=* zu ersetzen. Folgende Werte wären möglich: no – kein Deaktivierung und somit auch kein Kennlicht möglich DE-ESO:kennlicht – Kennlicht möglich off – Ausschalten (alle Lichter aus) möglich Weitere Werte sind außerhalb der DB möglich, falls dort erforderlich. Es wären mehrere Werte miteinander kombinierbar, z.B. "DE-ESO:kennlicht;off". Das mag in Deutschland vielleicht nicht relevant sein, im Ausland aber schon. Signalsysteme sind nämlich sehr vielfältig. Ich bitte um eure Kommentare zu meinem Vorschlag. Aus den genannten Gründen verzichte ich vorerst auf eine Änderung des Kennlicht-Taggings in der JOSM-Objektvorlage. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

1 0

Deutschsprachige Zusammenfassungen gewünscht?
by Michael Reichert 03 Feb '15

03 Feb '15

Hallo, gibt es hier jemanden auf der Liste, dessen Englisch nicht ausreicht, englischsprachigen Taggingdiskussionen zu folgen? Wenn ja, dann ergänze ich meinen Mails nämlich künftig um eine deutschsprachige Zusammenfassung. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.

1 0

Level Crossing suggestions
by Erich Pfistner 03 Feb '15

03 Feb '15

One of the best data sources for mapping in the U.S. has been the Federal Railroad Administration's GIS Data <http://fragis.fra.dot.gov/GISFRASafety/>; and the most expansive data is the level crossing inventory. There's a few things in there that are documented that don't have tags yet, and I think they are useful. They are: - key=crossing:cantilever - Values: yes/no - Description: Metal cantilever that extends over the road, and usually has a crossbuck/saltire and/or flashing lights mounted to it. - key=crossing:contact:emergency - Values: <string> - Description: A designated contact number for contacting emergency operators. - key=crossing:contact:railroad - Values: <string> - Description: A designated contact number for contacting the railroad. - key=crossing:contact:state - Values: <string> - Description: A designated contact number for contacting state government. - key=crossing:quiet_zone - Values: yes/no - Description: Locomotive engineers/operators are not to sound the horn at these crossings. There is often some sort of additional sound-producing device at these crossings. - Federal Railroad Administration page <http://www.fra.dot.gov/Page/P0689> - key=crossing:traffic_signal - Values: control/interconnected/no - Description: In Urban environments, highway intersections and level crossings are often adjacent to each other and therefore the level crossing is integrated into the traffic signal controller. "control" is to indicate a crossing where traffic signals replace the typical alternating crossing lights and other standard protections. "interconnected" is when the traffic controller program will alter from typical operation when a train is approaching. It could be a red light for traffic in that direction, a temporary no right/left turn restriction, or a number of other scenarios. - key=crossing:wigwag - Values: yes/no - Description: Old type of crossing protection consisting of a pendulum swinging back and forth. There's approximately 100 left in service in the U.S. - Wikipedia page <https://en.wikipedia.org/wiki/Wigwag_%28railroad%29> The inventory reports also list the count of crossing lights, crossbucks/saltires, and other such warning devices. I am unsure if these would be useful enough to tag, however. In addition, the integration of traffic signals at highway intersections with level crossings leads to a problem of grouping together elements of the entire junction, or even just the level crossing with itself. This is a problem with highway junctions in general. I think it could be a good idea to co-opt the complex junction relation from Proposed_features/Junction <https://wiki.openstreetmap.org/wiki/Proposed_features/Junction>. This would also allow level crossings of multiple tracks to be grouped together. They way I would structure it is: - Relation tagging: - key=type=junction - key=junction=level_crossing - key=ref:fra_crossing - Value: <string> - Note: While not an approved value, this is the value I have been using for marking the ID used in the FRA's Crossing Inventory. - Any of the tags used for the level_crossing node, as many of them are better applied to the relation than the node. - Relation roles: - (blank) - Used on: Anything else - Description: Used to include anything else that isn't listed below. The only thing I can think of that could be is the segment of track that is embedded in the roadway. I have tagged this in the past as key=embedded=yes/pavement/metal/wood/plastic (plastic includes rubber). The highway section between stop lines/traffic signals could be added as well, as I suppose those are part of the junction as well. - level_crossing - Occurance: 1 or more. - Used on: key=railway=level_crossing or key=railway=crossing - Description: This is where the railway track intersects a highway or pedestrian path. - traffic_signal - Occurance: 0 or more - Used on: highway=traffic_signals - Description: Any traffic signals that are part of this junction. This assumes that the traffic_signal is not mapped at the intersection of roadways. - stop_line - Occurance: 0 or More, mutually exclusive with traffic_signal - Used on: Nodes tagged with key=highway=stop_line - Description: This is where vehicles are to come to a stop, in cases where a traffic signal would not otherwise be tagged at this position. - location_hint - Occurance: Optionally one. Mutually exclusive with. - Used on: Any node. - Description: A hint to a renderer as to where a good place to put the the junction number or name on the map. Anyways, just seeing what other thoughts you have. I cannot say that all of the terminology used in tags or roles are optimal.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Openrailwaymap February 2015