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
_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us
