OpenRailwayMap / OpenRailwayMap-CartoCSS

CartoCSS port of the OpenRailwayMap styles, originally written in MapCSS
GNU General Public License v3.0
15 stars 20 forks source link

Render `reporting_marks` key for North American rail #100

Open wolfy1339 opened 1 year ago

wolfy1339 commented 1 year ago

In North America, we use the reporting_marks tag to identify lines, not just to identify the owner/operator of the line.

If you look at the following extract from the discussion on the talk page of the tag, you will see why that tag is important to be rendered for North American railways, https://wiki.openstreetmap.org/wiki/Talk:Key:reporting_marks#Confusion_between_OSM_and_wikidata

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. [ ... ]

These are not just equivalent to operator:short, they are official registered company codes. They would be rendered similarly to how the ref key is rendered.

Hopefully you can understand why this is important for North American rail, and why we would want to see it rendered on the map

See also https://github.com/OpenRailwayMap/OpenRailwayMap/issues/853

besentv commented 10 months ago

My knowledge is very limited on railway outside of Germany, Poland an France. Could you maybe draw an example by hand, then I could look into implementing it.

wolfy1339 commented 10 months ago

Sure. I'll try to make a small example

wolfy1339 commented 10 months ago

Basically, the reporting_marks key is semicolon separated when there are multiple operators on a track. The first entry is the primary operator (and usually the owner) of the infrastructure, and should be the first to be displayed with a rendering similar to how the ref key is currently.

Other entries, should come after the first in parenthesis like so: PRIM (SEC, Third)

The entries should always be uppercase.

At low zoom levels, display the first entry of the tag, and at high zoom levels display the more verbose data.

This information should be displayed before the name=* tag.

The examples will be this particular way: https://www.openstreetmap.org/way/101904668 Example at high zoom: image

Example at low zoom: image

besentv commented 10 months ago

So at levels 0-13 only "CN" Then maybe 14-16 "CN (VIA, ...)" And 17-18 "CN (VIA, ...) Drummondville Subdivision" ?

wolfy1339 commented 10 months ago

I think that sounds good.

besentv commented 10 months ago

You could also ask what the others might think about this, before I lose my braincells over the code :D

claysmalley commented 10 months ago

As a railway mapper in the US, I support rendering reporting_marks=* in this way. This matches my expectations for how North American railroads should be labeled on a map.

Generally, I put only one company in operator=* and operator:wikidata=*, as it is always one company that dispatches the trains and operates the signals and switches along a particular railroad segment. Without reporting_marks=*, we don't have a clearly defined tag to indicate the multiple companies that actually operate the trains. In many cases, the primary train operator will be the same as the operator of the underlying infrastructure, but there are quite a few companies that only operate infrastructure and have no trains of their own to run. The average North American viewer would probably rather see the train operators (reporting_marks=*) rather than the infrastructure operator (operator=*) on a map.

besentv commented 10 months ago

I feel like this could cause a mess, labels should imo stay concise.

wolfy1339 commented 10 months ago

Can you explain what you mean by not being concise?

The reporting_marks=* tag is the only one we are talking about here.

It is not often where you see many operators on the same line. So that shouldn't be an issue.

We could set an upper limit on the number of reporting marks rendered if that becomes an issue.

wolfy1339 commented 9 months ago

See also discussion on discourse: https://community.openstreetmap.org/t/rendering-reporting-marks-on-openrailwaymap/106191/8

besentv commented 9 months ago

Alright, I can try implementing it like discussed sometime, but my time is really limited right now, so it might take a while.