Talk:Key:reporting marks

Confusion between OSM and wikidata

As I understand this page, reporting marks are identifiers which represent a given company which operates railway features or rolling stock.
/I assume it's a figure related to one or more company and equivalent to its name or a subset of its assets.
Why should we indicate it on OSM instead of operator=* or operator:wikidata=* which could enable to find reporting marks with wikidata or data items? Fanfouer (talk) 10:21, 13 June 2020 (UTC)

This one thankfully I can give a clear answer on, because it comes down to a fundamental difference in rail mapping standards between North America and elsewhere. Here, the reporting marks themselves are the primary label on rail maps. You'll find them on at least 90% of maps, and the other 10% have the operator name spelled out instead. It's a 150 year old industry-wide standard here, so the tag is needed so that we can finally work on getting the rendering fixed in North America to something functional. (At the moment, the rail map has had a ton of work done to it, but is still unusable to most potential users because of the lack of reporting mark labeling. I almost want to pull my hair out trying to use it myself because of this huge omission, and that from someone working to try to edit and improve it. This is probably something only this area of the world will care about, but here it's critical.) Chuck (talk) 23:17, 14 June 2020 (UTC)

But we put street names with the full text, rather than abbreviating: we write "Northeast Beech Street" not "NE Beech St" like it says on the sign and on most maps. Database users can correlate the full operator name with the reporting mark when they want to render a map or analyze the data. --Jeisenbe (talk) 04:35, 18 June 2020 (UTC)

I pretty agree with Joseph, mappers can deduce OSM name from abbreviation from ground. However, my concen about kind of asset identifiers related to a given company wasn't appropriate. I know better understand what a reporting mark is and I'm not sure it's an actual abbreviation but a real company code, right? Fanfouer (talk) 18:48, 18 June 2020 (UTC)

Yes - company code is a good way to explain it. It's an official, registered company code that's used in an awful lot of official documentation here; that's how it became the default map label, even on government maps. Chuck (talk) 11:32, 19 June 2020 (UTC)

Data format

I opened a follow-up on the mailing list here to discuss data formatting for best rendering. There are two alternate standard display modes for this data on normal US rail maps; entering the data as it's meant to be displayed would make map rendering a lot easier, but would make it harder to display the label in the other standard way. The following examples take a specific very short piece of real track local to me with four secondary operators.

Most common labelling style: NS (AMTK, BB, CA, NPBL)

Second most common labelling style: NS / AMTK / BB / CA / NPBL

At the moment, I'm entering the data visually in the first style, vs. the tag data standard for multiples, which would usually be NS;AMTK;BB;CA;NPBL (the style I wrote out in the wiki here). I've played with the OpenRailwayMap paint CSS in JOSM to pre-pend this field straight in front of ref and name in the label, and it now displays exactly like a North American rail map usually looks, so I know it works. If international ORM were willing to make this minor change, we'd immediately get proper display in North America, and since the reporting_marks tag is North-America exclusive, it would have absolutely no effect on rendering in the rest of the world.

However, I'm not 100% clear that this is the best way to go, since there are alternate map renderings and users. My area has a lot more trackage rights than most, so I figure if I enter the data visually like I have, and we come to a different consensus, it'll mostly be my personal rework to fix the ones I've done this way. I'm very much hoping to get more input on this topic, but haven't yet; especially from anyone who's actually worked on any of the rendering setups.

Chuck (talk) 23:26, 17 June 2020 (UTC)

Use the semicolon separator. This is already done for the ref=* of highways and database users are able to produce visually approprate results, and a semicolon is clearly not part of the actual reporting mark. --Jeisenbe (talk) 04:33, 18 June 2020 (UTC)

Makes sense, thanks! I wish I'd had some luck earlier this week getting anyone who works with the renderers involved in that list question, but no luck yet. Just know from seeing it that you're very right on the highway equivalent issue, and they renderer just fine. Chuck (talk) 11:25, 19 June 2020 (UTC)

Page move, in light of US rail conference call on 7/4?

I've been thinking since the other day regarding the result of the conference call - looks like we had buy in on everything except this specific tag to use, but we were all able to agree on operator:short instead. Since this page is actually pretty decently developed already, but happens to refer to the deprecated tag - what if we just move this page to OpenRailwayMap/Tagging in North America/Reporting Marks, make the small change to call for storing the data in operator:short=* instead, and put a stub in reporting_marks=* to indicate that tag was deprecated, and redirect everyone to the new location at OpenRailwayMap/Tagging in North America/Reporting Marks? Seems to me that gets us to the result we all agreed to Saturday with the least work required. Thoughts? Chuck (talk) 19:11, 7 July 2020 (UTC)

I wrote down operator:short=* in my notes from the conference with Michael as well, but I'm not sure that he offered a "wholesale buy-in" to having operator:short=* so completely replace reporting_marks=*. That may very well be, perhaps my notes are incomplete. Best might be one of those rare times when it is correct to contact Michael directly and ask if this is your correct understanding of the situation. I think he'd appreciate that, and it would give you a chance to ask him (briefly) if we might expect "a certain kind of ORM rendering" as more and more NA rail gets tagged with operator:short=*. Short and sweet, all doable in one question from you, one reply from Michael. Chuck, it's like wishing for something and having a genie appear and grant it for you (you lucky guy!) It's neat and amazing to me how this is unfolding so smoothly. Stevea (talk) 19:21, 7 July 2020 (UTC)

An update, I don't believe that a wiki "move" is quite correct. I believe the wiki should continue to have this page, which should be changed to a simple, brief explanation of what reporting marks are, explaining the latter tag is an ORM functionally semantic equivalent and link to operator:short=*. This is different than a wiki "redirect" as that would not allow us this chance to explain this, though having two pages requires a click on a link from one (here) to the other (operator:short=*). Stevea (talk) 19:30, 7 July 2020 (UTC)

Sounds good! Email sent. With respect to "moving," it'd be just as easy to copy and paste most of the source from here into the new Reporting Marks page, that way most of the important part wouldn't be directly under a Key:reporting marks section for a key we're not using. Then, leave this page as a short stub exactly like you're suggesting. So overall, I agree, if that makes sense. I'll drop in again as soon as I have that confirmation from Michael. Chuck (talk) 22:40, 7 July 2020 (UTC)