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
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...https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014...
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)
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.
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.
