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