Rendering `reporting_marks` on OpenRailwayMap

Communities United States
,
1

Hello mapping colleagues from the US,

I filed an issue on the ORM GitHub to render the Key:reporting_marks on the map.

I posted my understanding of how the map should look with this information based on previous discussions made by the community on different mailing lists and wiki pages.

Basically it has been suggested to render it as follows:

  • Display only the primary operator’s reporting mark at low zoom levels (0-13)
  • Display all operators reporting marks at higher zoom levels (14-16)
  • Display all operators reporting marks and the name=* tag at zom levels 17-18

I would greatly appreciate it if you could give feedback

2 Likes
2

The GitHub issue in question is here: Render `reporting_marks` key for North American rail · Issue #100 · OpenRailwayMap/OpenRailwayMap-CartoCSS · GitHub

3

Oh shoot! :sweat_smile: I forgot to post that.
Thanks for posting it

4

Was there any (more?) resolution of the distinctions and/or harmonization between tagging and rendering of reporting_marks (a North American-specific tag) and the short_name=* tag, which is “more global?”

5

reporting_marks=* indicates the operator, not the name. So maybe operator:short=* is a better fit.

6

Clay, I like yours too. Enough to say that any downstream parser might now consider both operator:short=* / operator=* and short_name=* tags alike (or pretty similar, or slicing with a high-precision knife of semantics — so we’re learning something right here and now). It seems likely ORM tips (heavily?) in the direction of rendering with the reporting_marks=* tag; that’s the issue (on GitHub).

I ask @wolfy1339 and any/all others, what do you think?

My opinion? Yes, ORM rendering reporting_marks=* (the tagging is certainly happening) makes sense to me. Such rendering will actually happen on ORM if so, in North America, as the tagging is (t)here. Supporting it over the continent-wide region where it happens, that makes sense. Our tagging is plastic, we “flex like this.” And this tag means a certain thing where we so denote (soon, maybe rendered in ORM). This is similar to Kanji (characters) being displayed with Japan.

Somebody (@Ferrocarriles_de_México, Geochicas, if you plural are around, someone from our LATAM community…) who knows more than I do about ferrocarriles en México (rail in México) is deeply welcome to chime in here. ¿Preguntas, alguien?

It’s nice to sharpen up our semantics of how we tag with greater precision. There really is such a thing as distinguishing operator=* of the line (with North America’s “particular method” of denoting a two-to-four character alphabetic moniker, we call these reporting_marks=*) from its name=* or short_name=*. And “around here” that’s done frequently, so this makes sense.

People talk about things (here sometimes, amongst ourselves…) about a certain specific topic, it gets noticed and incorporated as a certain amount of consensus. Wheels do turn around here! (Including at global, continental, national, regional and local levels).

Thanks, everybody. I enjoy this journey called OSM. Quite literally, together we make it work.

7

There is a resemblance between operator:short and reporting_marks, I can agree to that.
However, they don’t always line up. Take for example CPKC, according to current tagging guidelines,

operator=Canadian Pacific Kansas City // Full name of the operator
operator:short=CPKC // Operator's short name
reporting_marks=CP // Reporting marks
8

That may be outdated—CPKC’s new reporting mark after the merger is indeed CPKC.

9

Yes, that 100% IS outdated (@clay_c 's info is correct). However, in the USA there may still be similar examples where these two tags diverge for any given operator, though, offhand, I don’t know of any myself. That’s not saying much, as I’m “simply an OSM rail mapper,” so please be aware that these two tags should remain distinct so they mean the same thing across the world in the entirety of our project. I consider these two tags diverging an unlikely possibility, though a possibility nonetheless.

It took a while — well into 2023 — as did the merger, but our wiki documentation has now caught up with documenting that CPKC is a real thing now. As for actual tagging on ways of CPKC’s railway=rail in OSM, well, I haven’t checked (taginfo or Overpass). But assuring all rail is correctly tagged with CPKC is likely a fair-sized job to complete.

This rather begs the question, how “should” we tag in the USA? I’d say (continuing to) tag with reporting_marks=* is correct (in North America), and whether the operator:short=* tag is different or not, it is an optional tag if the former tag is extant.

Now, to put the icing on the cake and call the whole stack rather complete, getting reporting_marks=* to render in ORM (as described in Issue #100 on GitHub) would be what’s needed to make pretty rendering, getting more accurate every day. Clay is correct when he says that people looking at a North American rail map would expect to see lines tagged with reporting_marks=* as is proposed (in Issue #100) and I also agree that the selected zoom levels seem appropriate. I add my agreement that’s a nice proposal and I hope to see it implemented, too.

1 Like
10

These markings denote the operator for all what I understand. Operator or owner are also tagged elsewhere using the normal tagging. But nothing of that is rendered yet. The only thing that is yet rendered is railway=owner_change.

For me personally it doesn’t make sense to add these markings to the infrastructure layer, especially if they would replace the line names. This would make more sense to put in it’s own layer (and then move owner_change over to it). Adding a new layer is subject to the usual problems: machine load for rendering, disk space…

11

It doesn’t replace line names. It’s what one would expect on a North American map.

I understand you don’t want to render operators, that’s fine for elsewhere in the world.

12

I also considered if / whether putting reporting_marks=* (as operator of trains, not infrastructure) might best be rendered in its own layer in ORM. That certainly is another possibility, actually quite well-stated here.

Now we have here an implementor of ORM saying that such a new layer is a “better” place to render reporting_marks=*, especially as these denote (an) operator(s) of trains and not infrastructure, while the proposal (Issue #100) is for reporting_marks=* to render in ORM’s infrastructure layer. I didn’t consider the “inherent apparent contradiction” here, but now I do.

North American rail mappers (I include myself): what do we think of an ORM author potentially implementing Issue #100, but in another layer? There are (clearly stated) time and resource constraints on this, which could delay its implementation, yet consider that we’d gain the ability to display both infrastructure name and train operator (in North America, with the reporting_marks=* tag) in two layers with the simple click of a radio button in ORM to switch layers. With the way the current proposal is written, we’d get both in one layer (and regionally, only in North America where these tags are extant), but only at different zoom levels. And I agree that this can be confusing, and even easily stated to be incorrect, as while “in the infrastructure layer, displayed are not infrastructure operators, but train operators.”

Personally, I find @Dakon 's remarks quite sensible, though I understand this brings its own difficulties.

@wolfy1339 , I think it’s possible to get what you are looking for, just in another layer, while “not confusing” the way the rest of the world tags (in OSM) and sees (in ORM) its rail.

13

Maybe there could be a compromise here? I totally understand that reporting_marks concerns operators, and that the proposal as it currently stands would maybe be better for for a new layer of ORM.

Maybe we can only show the primary operator, which in most cases is the owner of the infrastructure? This would align with how maps would show this in North America, and wouldn’t require much code for it’s implementation, and wouldn’t require that much processing or space.

The implementation would basically be the same as ref

I’d like to share this screenshot of how a railmap looks in North America.

This is from the Railway Association of Canada’s Rail Atlas:

Screenshot_20231219-180928
Screenshot_20231219-1809281080×1894 523 KB

14

It’s for sure an imagination exercise: consider ORM having a new “Operators” layer with the ability to checkbox-toggle operator:short and (or) reporting_marks, operator=*. And other, smarter, logic, into the future of an extensible user interface (UI) layer (for operators and such).

The semantics (of this discussion, and it’s a good one) meet this visual, UI syntax. In ORM.

I’m frowning that another map product (Rail Atlas) is seen here. I can’t unsee it, but OSM shouldn’t mimic another product for the sake of looking like it. OSM is about “what is” and on the ORM visualization side “seeing it” (usefully, I find ORM a wonderful layer overlay).

We do like to see reporting_marks=* displayed on a map in North America. Along with other things that OSM tags. Together. So, we can build (operator-related UI) with a layer in ORM specific to those tags being “checked on or off” in various ways.

Blow some bubbles with that gum, everybody. UI design can be fun.

15

I only included it as an example. I don’t wish to mimic it, ORM does a good job (mostly) for our North American rail needs, IMO.

It’s simply an example of how another map shows the data. To show that people don’t necessarily know the name of the line but that the primary owner is well known instead.

I do see how the operator layer could work. It’s why I suggested only rendering the reporting_marks of the primary operator/infrastructure owner.

People seem to already tagging for the renderer by using the ref key to show the primary operator in Carto and ORM.

My suggestion could help with that by rendering the tag in a lightweight fashion, as then people would see the data they expect to see on a map

16

You (would, do) need to further specify what you mean by “what is done with ref:*” although what you say above (“Seem to already (be) tagging for the renderer using the ref key”) is a good start. It’s understood that “people would see the data as they expect to” has to be a bit reverse-engineered, as we’re roughly doing here.

Again, what we’re doing is a rough sketch of how ref=* (now), operator=* (and short), reporting_marks=* (and other logic) might be built into an ORM layer. By “other logic” I include more of what the base layer elements will be. So far, it’s pretty lightweight UI for pretty lightweight logic. However, (additionally) describing everything you know about how this might or might not fit into many larger schemes of things is helpful right now. This is a global map and its design demands us to think that way.

This discussion is at least tri-national (Canada, Germany, USA…) although I always consider topics about OSM rail to be quite international, really global. Clay and I have been mapping rail together for many years.

17

Ok, seems like I misunderstood something here. This is about markings on the trains, not about something like a signal post or whatever that tells something about the infrastructure?

Then I have a clear opinion [*]: don’t render it is. ORM is about infrastructure, we don’t care about trains :stuck_out_tongue: I especially acknoledge that train operations in nothern America seem to be different from what I would call “normal” as we have it over here in Europe, but that has something to do with that most rail infrastructure here is operated by sort-of public operators, while the tracks in the US seem to be mostly private property. So over there it seems not only to be “could I reach that point by rail” but also “who would own that rail, so I could even get a chance to purchase the right to use it”. That still may be a valid thing to show even on ORM, but I would really like to keep that out from the infrastructure layer as that would become too crowded. But this: opinion.

*) while I am one of the developers that doesn’t mean that I can rule things out. I may have a louder voice, but no regulative power. At the end we want that people use what we create.

18

Maybe we can only show the primary operator, which in most cases is the owner of the infrastructure? This would align with how maps would show this in North America, and wouldn’t require much code for it’s implementation, and wouldn’t require that much processing or space.

That is totally not the case. The disk space comes from “have to store a new tile”, i.e. a square png image. The processing is mostly to gather all the relevant objects in that given drawing area. The actual contents of the PNG are basically completely irrelevant (with the exception of completely empty tiles), and the actual drawing is only a minor fraction of the processing time. So what is drawn, be it ref, reporting_marks, or FIXME comments is completely irrelevant.

19

While it is true what you are saying, that is it’s original/intended purpose but it has been used into simply referencing the operator.

It is used even by the operator’s themselves on station mile signs, which are trackside signs denoting a named location (ie: station, siding switch, junction, yard main track switch)

Let me quote the wiki here:

And as OSM maps rail features, not railcars, by using this tag to mean “the one or more companies who operate a railway-related feature,” it will only usefully be applied to rail features that OSM maps, primarily but not exclusively railway=rail.

In North America, we don’t really have line reference numbers (ref=*) like you do on Germany (or the rest in Europe), we reference our lines by operator.

You can think of it being sort of equal to loc_name, as that is what is used colloquially to refer to the line.

As for map crowding, that’s why I suggested only rendering the primary operator instead, it’s. The full list as tagged can be a seperate layer.

1 Like
20

As another North American rail mapper, I think there is an emerging consensus that reporting_marks=* being “revealed” in a new layer of ORM is likely the most harmonious way for all of this to unfold. Yes, there are costs as well as a timeline associated with that/those, but I think we’d prefer a “more correct” resolution to this than one which is hastily-decided.