[Talk-us] Rail USA (after about six weeks)

[stevea]

Regarding OSM's "Great USA Rail Update (of 2014-5)," the two most 
important initial target tasks seem to be properly naming a 
subdivision or line and gathering together commonly-named members 
into a route relation.

The first task can be done (as in California recently) by using a 
Public Utilities Commission crossing spreadsheet which identifies 
road/rail crossings, importantly naming the rail "line" with the road 
crossing.  By following these as existing OSM data, usually from 
TIGER (sorted numerically by milepost), one can properly name rail 
segments in OSM.  Often, the name= tag is the rail operator (e.g. 
Union Pacific Railroad or BNSF).  By changing this name= to 
operator=, then adding a name= tag as the name of the subdivision or 
line, we better tag for OpenRailwayMap (ORM), and it can be argued, 
for OSM.

Regarding the tiger:reviewed=no tag:  if you don't visually analyze 
(for example, with Bing imagery) the rail segment, but simply change 
its tags as above, leave tiger:reviewed=no alone.  If you DO improve 
the rail segment, perhaps by adding more nodes along curves and/or 
better aligning it to an imagery layer, remove this tag, don't set it 
to tiger:reviewed=yes -- a superfluous and therefore useless tag.  If 
you encounter a tiger:reviewed=yes tag, simply delete it.

If a usage= tag has already been added to the rail segment, let it 
guide you.  For example, if a short line railroad (a few miles to 
dozen or two miles) has usage=industrial, that is likely what it is. 
However, the tag usage=freight causes the rail line to not render in 
ORM, so replace usage=freight with usage=industrial.

Set a rail segment to usage=main if it is part of a large (hundreds 
of miles) named subdivision or line, especially if it crosses state 
lines.  It can be helpful (though isn't a necessary strategy of 
building USA rail) to get mainlines identified early on, as they 
define a high (though secondary) level of the ORM renderings with 
named orange lines.  ORM's primary level rail, high-speed, (red) 
doesn't exist in the USA, except for Amtrak's Acela service in the 
Northeast Corridor.  We still haven't achieved an Acela rendering in 
ORM!  Will you help?

After identifying mainlines, rail continue to render in ORM (from 
TIGER data) as black lines:  simple rail, not well-identified, 
without a usage tag.  It is up to you to determine better usage= tags:

usage=industrial for spurs to quarries, factories, lumberyards, ports...,
usage=military for spurs to military areas (causes ORM to not render the line),
usage=tourism for lines which primarily serve tourists (causes ORM to 
not render the line),
usage=mainline as described as above,
usage=branch as described below.

Use usage=branch on shorter "connecting" rail segments which either 
branch off of the mainlines to a "dead end" destination, or which 
connect mainlines together.  ORM renders usage=branch (tertiary 
level) as yellow.

While doing this, you'll encounter rail segments which (in 
approximate order of occurrence) are sidings, make up rail yards, 
branch off as short spurs and act as crossovers.  Sidings are 
parallel tracks (often in or immediately adjacent to stations) which 
allow one train to pass/overtake another.  Tag these service=siding. 
Rail segments which allow cars to be switched and/or parked, often 
with many parallel tracks in a small area, get the tag service=yard. 
Track segments which branch off a main or branch line for a short 
distance (usually to an industrial area) get the tag service=spur. 
Short segments of track which switch traffic from one parallel track 
to another get the tag service=crossover.  These tags are often in 
addition to others such as name= and operator=.  However, it is 
usually true that usage=* + service=* don't make sense together.  The 
ORM tagging page says (slightly paraphrased):

Inside railway stations, use usage=* only for main tracks (not for 
siding, yard tracks etc.). This also applies for crossover or 
overtaking tracks outside of the railway stations. Always use usage=* 
only on main tracks. As an exception, you may use usage=industrial on 
siding and yard tracks, and crossovers in industrial areas such as 
harbors and mines.

Some rail segments have had odd tags applied to them (often by 
TIGER), such as railway=spur.  This particular tag causes ORM to not 
render and should be replaced with railway=rail + service=spur.

The railway= tag can be:
railway=rail for track which is used on a regular basis,
railway=light_rail for city railway and tram-like underground or 
suburban trains,
railway=subway for underground rail in larger cities, powered mostly 
by third rail (sometimes surfaces),
(Do not map ordinary railway which goes underground with 
railway=subway, tag tunnel=yes + layer=-1),
railway=tram for mostly on-street tracks (commonly motorcars share 
traffic lanes with trams),
railway=narrow_gauge for track with a gauge narrower than is typical 
to the USA,
railway=miniature for small railways in parks for entertainment or 
tourists, mostly narrow gauge,
railway=construction for track actually being built now (e.g. 
railway=construction + construction=light_rail),
railway=[disused, abandoned, razed] for track being phased out of 
usage -- see the ORM tagging page, and
railway=proposed for the path of a fully public-approved rail project 
with a distinctly well-mapped route.

The second task, gathering together commonly-named (rail segment) 
members into a route relation, is important, as it allows subsequent 
manipulation of the entire subdivision or line as a unit.  It is much 
easier to use JOSM's relation editor's feature of selecting all 
relation members to change a name= or usage= tag than it is to 
manually select each rail segment and download the next one from its 
end node (repeat for potentially hundreds of segments in a single 
subdivision).  Please, do your best to gather similarly-named rail 
segments which really do belong together into a single relation. 
Once done, this makes additional editing much simpler.  This includes 
building these named route relations into service routes, like 
"Sunset Limited" or "California Zephyr" as passenger rail routes (as 
a relation separate from the one which simply gathers all named 
subdivision segments into a subdivision relation).

In short:  First, name the tracks properly.  This is relatively easy 
(though tedious) thanks to TIGER data, though they can be 
noisy/inaccurate.  Next, assemble these into usage= groupings, 
preferably with a route relation.  The segments must have the usage= 
tag, not the relation.  Then, assemble together main+main or 
main+branch segments into passenger rail relations.  You might find 
that some of this (especially the latter) is already done in your 
focus area, and your "lower level" editing (naming and grouping) 
causes confusion or breakage of the "higher level" passenger rail 
routes.  Just persevere with the lower-level editing, and the 
higher-level route relations can then be better expressed.

In California, I might say rail as rendered by ORM is perhaps 65% 
complete (excluding minor attributes such as signals).  A mainline 
and branch structure of thousands of miles can be seen to be largely 
done (except for greater Los Angeles, which is highly complex, 
fraught with historical errors and being improved now).  Most urban 
rail systems (subway, light_rail, tram, as blue, green and pink, 
respectively) are complete, though they are not all named and 
gathered into relations properly.  California still has a long way 
yet to go, but our rail looks much better in ORM over the last six 
weeks, thanks to the work of more than just myself.  And it seems to 
be getting continually improved.

How is OSM rail coming along in YOUR state in the USA?  It makes for 
a great community project!

Best regards,

SteveA
California