This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.

[openrailwaymap] Level Crossing suggestions

Michael Reichert nakaner at gmx.net
Tue Feb 3 17:55:27 MET 2015


Hi Erich,

Am 2015-01-28 um 00:37 schrieb Erich Pfistner:
> 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. 

Is the data quality of FRA as bad as the data about railway lines? Have
a look at Pratt, Kansas (I randomly zoomed in and encountered the
error). https://www.openstreetmap.org/#map=16/37.6406/-98.7490
If you look at FRAGIS (ArcGIS.js has no permalink feature there), you
will see a red line between the railway line in the south and the line
in the north through the residential area and houses.

Because other mappers (and I, too) consider copying data from Federal
Railroad Administration as an import, you should ask OSM Import mailing
list before adding a large amount of crossing information to OSM from
FRAGIS. (No one would care if you copy a handful of crossing because you
correct tagging of railway line, but if you start to add several dozens
of crossings, people would scream "Import! Where is the discussion?"
They will ask you how good the data is (have you checked quality in
field?), how it is licensed (seems to be no problem), how you want to do
it (workflow description; maybe source code of used scripts), which tags
you want to use and, maybe, how you will keep the data up to date in future.

From my German point of view, I am 95% against imports because Germany
is 95% import free [1] and has been mapped manually.

Are you really allowed to use these datasets? I have not found any page
there which says how they are licensed? It would be a showstopper if the
license is not compatible to OSM Contributor Terms.

> 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.

Is this number written at a sign at the crossing? If no, I would not map
it and would prefer tagging a reference number instead which links to
the database entry at Federal Railroad Administration.

>    - 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.

I don't think that this should be mapped. Why shall I call state
goverment in case of an accident at a level crossing? Don't copy the
whole database. :-)

>       - 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.

I would prefer crossing:quiet=yes/no because zone sounds like a track
section, e.g. one mile through a residential area where sensitive
lawyers have their homes. :-)

>       - 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.

We have such traffic-lights-railway-crossing combinations in Europe,
too. But up to know, there is no special tag.

>       - 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>

Yes, wigwags need an differnt tag.

By day: http://youtu.be/ynKeE_XAWmM?t=57s
At night (another crossing): http://youtu.be/coEvaOfTqOI?t=9s

Do wigwags show a red light by day? Is it bright enough bo be visible by
day? If yes, you can tag crossing:light=yes.

In Germany, car drivers would probably overlook wigwags. :-) We still
have lots of accidents at level crossing which have no barriers (in West
Germany barrier-less crossing only have red flashing lights and saltires).
https://www.youtube.com/watch?v=5l-WvUi_3Co
https://www.youtube.com/watch?v=Eod_kJMHul4
http://youtu.be/PSW5vhliBBM?t=1m
Such crossings still exist on branch lines on secondary roads and on
main lines on small roads (like this track).

> 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.

I do not think that it useful to tag how much lights are mounted at the
crossing. This number should be mapped if the mapping of this area is at
a level where every traffic sign and street light is mapped. At the
moment I see only two usecases for mapping each (flashing) light pole at
a level crossing – train simulators and car race simulators with real data.

> 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.

When designing ORM tagging scheme, Alex tried to avoid relations to keep
mapping easy, especially for newbies. The railway mapping community is
small, we should do everything to keep the entrance steps low. I suggest
to use the methode introuduced by proposal "Tagging for complex
junctions" in 2014.
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions
Lets enlarge this proposal for combined highway-railway-intersections. I
have mapped an example:
https://www.openstreetmap.org/#map=19/49.14069/9.19136
An image taken from south of the level crossing:
http://www.abload.de/img/05jef5t.jpg

Best regards

Michael



[1] Our largest imports are/were addresses in Cologne (still running for
over a year or longer), Berlin (just finished) and Rostock (about 4–5
years ago), boundaries everywhere and WMS services of one large state
and a few cities.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150203/42e2247d/attachment.sig>


More information about the Openrailwaymap mailing list