[Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*

[Chuck Sanders]

After a sidebar with a couple of other folks on the list a few minutes ago,
I realized I hadn't clearly wrapped up my conclusions from this part of the
discussion and what followed.  In light of the online meeting tomorrow to
discuss, I want to take a moment as suggested to clear this up, since it
was one of the main topics under discussion this past month.  In essence, I
quickly abandoned my original suggestion below of using the ref tag instead
(which already has rendering support, but has other uses in the US that are
more appropriate) for reporting marks.  Here's the brief synopsis:

End goal: In North America, the primary OpenRailwayMap rendering needs to
show the operators prepended to the route number and name, as this is the
industry standard that map users expect and require.  The most common form
is the reporting marks, an official short form.

Recommended method:  Include reporting marks in the following regional tag,
as described on https://wiki.openstreetmap.org/wiki/Key:reporting_marks

Use of the regional tag (rather than a more common tag with other possible
uses) will simplify future rendering support; because the tag will serve
this specific purpose, it will not be accidentally misused in a way that
might cause improper labelling to appear on a non-North American part of
the map.

Future steps:  Work with the rendering team to format this information for
view and prepend it to the current labels of [ref] [name].

If we can get the reporting marks populated and get rendering support even
just on the current main routes, the rendered map would actually quickly
become usable in the US, which might also encourage more new contributors
to the cleanup/detail work.  We could get most main routes tagged within a
couple of weeks by selecting using existing relations.

Thanks,
Chuck
VA, USA

On Fri, Jun 12, 2020 at 7:21 PM Chuck Sanders <nathhad at gmail.com> wrote:

> In the interim this week, I got the wiki page up for tag:reporting_marks,
> and started using the tag in my area as a bit of a test - we had the
> thought that if there proved to be a better tag to hold this info, since
> this is a "novel" tag, it'd be easy to query out places we'd used it and
> just switch it to the more appropriate tag.  Meanwhile, we could at least
> start entering the info we needed to eventually make the rail map show the
> information North American rail users expect.
>
> Turns out, there IS a better tag already, and it's *really* obvious, if
> you know much about European rail networks ... which I don't, on the
> whole.  The best tag to use was already in the default tag scheme, but I
> glossed over it based on its description, since nothing like it is used in
> North American rail networks.
>
> Long story short, in NA rail networks, we should be storing the reporting
> marks in the ref=* tag on the way, and in a "pretty" way, as this tag is
> directly rendered as part of the label.
>
> I missed this, because the description of that tag in the
> OpenRailwayMap/Tagging page is just, "The reference number of the railway
> line the track belongs to."  There's no such thing as a track reference
> number anywhere in NA, it's literally a foreign concept on this side of the
> Atlantic.  I suspect the description is so short, because it turns out the
> fine folks in Germany (where this tagging scheme was first developed)
> number their railway routes like we number highways in NA. This became
> blindingly obvious when I took a better look at both some of the better
> developed areas of the German map (which are WAY beyond the point we're at
> here, unfortunately for us at least), and started poking through the MapCSS
> style definition for the ORM renderer.
>
> I tried this out locally yesterday, and gave the server time to re-render
> the tiles.  If you put the reporting marks in the ref tag, which is
> otherwise used for absolutely nothing in NA and likely never would be, it
> works *beautifully* on the ORM render. A line with ref
> <https://wiki.openstreetmap.org/wiki/Key:ref>=NS
> <https://wiki.openstreetmap.org/w/index.php?title=Tag:ref%3DNS&action=edit&redlink=1>
> and name <https://wiki.openstreetmap.org/wiki/Key:name>=South Branch
> <https://wiki.openstreetmap.org/w/index.php?title=Tag:name%3DSouth_Branch&action=edit&redlink=1>
> renders perfectly as "NS South Branch" at zooms >= 15, and as just "NS" at
> zooms 12-14, and with no tag at zooms <12. This is *exactly* the labeling
> style expected on a standard North American rail map - finally! And no
> modifications to the renderer necessary to make it work perfectly. I've
> uploaded samples at Zoom 12
> <http://www.aturnofthenut.com/wp-content/uploads/2020/06/2020_06_12_18_37_29_OpenRailwayMap-12.png>
> and at Zoom 15
> <http://www.aturnofthenut.com/wp-content/uploads/2020/06/2020_06_12_18_40_25_OpenRailwayMap-15.png>
> for comparison.
>
> For any non-NA readers who might be just as confused about the
> desirability of that tagging style as I was about nice, sensible railway
> route numbers, that has been the default labeling of rail maps in NA for
> around 150 years.  The label is occasionally the spelled out operator name,
> but most commonly (better than 90% of examples) the operator reporting
> marks, which serve as a standardized shorthand.  Even the names, as we tag
> them in the name field, are rarely used to refer to the lines, and are
> essentially never used on mapping here.  They're the absolute last-choice
> designator, and you *really* have to hunt to find any rail map in the US
> (including by the operators) that labels any line by name.  This is in
> large part because railway lines in the US have always almost exclusively
> been privately owned, so in almost all cases the operator is effectively
> synonymous with the route name (especially up to about 1950; before the
> huge wave of national mergers started, each operator had one major route
> that was just known by their operator name).  You never see a map labeled
> by route names, it'd be the reporting marks with either an informal
> descriptive name (e.g. NS Washington-to-Atlanta line), or most often a
> double reference that gives the current and pre-mergers operator (e.g. NS
> ex-SOU), because that ex- operator takes you back to 1950 where it
> identifies a single line.  That's the US industry standard.
>
> So, this tag scheme gets us the best of both worlds - a map that's
> actually usable by a North American rail map consumer (which the current
> map is very much not due to lack of operator labeling), a name which is
> still consistent with the general OSM and ORM guidelines for wanting to
> apply some sort of name, and all of it with zero change needed to the ORM
> rendering settings to produce a usable map.  No special style, it's
> perfectly usable as-is with the default worldwide rendering style.  You can
> pan from Germany to the US and get a map that's exactly what people in the
> region expect to see and use, all with no special settings.
>
> The only thing we'll have to do a little different is the presentation of
> the ref data, because it's directly rendered.  Rather than semicolon
> delimiters like we proposed for reporting_marks, when there are multiple
> operators (one owner, one or more with trackage rights), the appropriate
> way to fill out the field would be e.g. "NS (AC, NPBL)" where NS is the
> owner-operator and the other two are trackage rights holders.  This is
> another NA mapping standard that's about 150 years old, and is essentially
> mandatory to make this a functional rail map for this part of the world.
>
> All that said - input?  Are there any objections to going that route,
> since it both solves so many problems, and simplifies fixing the big
> rendering issue we currently have?
>
> I have to say thanks to Volker, too, for his input on this last week - it
> was his suggestion to look for a more "international" tag that actually
> spurred me to dig through the completed European maps and the rendering
> definitions this week to see if this wasn't an already-solved problem that
> we Yanks just hadn't realized yet.
>
> Chuck
> Virginia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20200703/b917a835/attachment-0001.htm>