Railway=station as an area?

[stevea]

On that wiki page, under References, I expected to see “diagram 2” (the fully themed one) we just all achieved. Seems like a “chef’s kiss” place to put that diagram (or link it from the wikiverse). I mean, we all stand by that, link it up. If you point to this topic (in the wiki), I’ll offer an A+. Nice work everybody!

[gymate]

@stevea

On that wiki page, under References, I expected to see “diagram 2” (the fully themed one) we just all achieved. Seems like a “chef’s kiss” place to put that diagram (or link it from the wikiverse).

I’ll embed the diagrams—once I’ve uploaded them—in all relevant wiki pages for sure!

@stevea

If you point to this topic (in the wiki), I’ll offer an A+.

Good idea, thanks—will do!

[gymate]

@gymate

I’ve also made a simplified one hiding all objects in the illustration that depict optional or complex tagging methods:

I’ve uploaded this illustration to the wiki.

@gymate

So I’d like to propose the following tagging scheme illustration updated with your suggestions:

I’ve realigned and unified the colors of the bottom text boxes and put all tags in them on separate lines:

I hope you like these tiny improvements! If yes (a thumbs up is enough), I’ll upload this version shortly and embed both illustrations in all relevant wiki pages.

[stevea]

Let’s call it a good first coat of fresh paint. A little wet, places where tidying of specificities might get tightened up, sure. Thumbs up.

[gymate]

Thanks a lot for the feedback!

@gymate

And I think that colors don’t really need an explanation on the illustration as they’re just visual guides for grouping tag categories, but they could be featured on the Wiki file page .

I’ve added info about the colors on the files’ wiki pages.

@gymate

I’ve realigned and unified the colors of the bottom text boxes and put all tags in them on separate lines:

I’ve uploaded this version to the wiki.

@gymate

and embed both illustrations in all relevant wiki pages.

@stevea

If you point to this topic (in the wiki), I’ll offer an A+.

I’ve embedded both illustrations in the following wiki pages, added links to this topic and edited them accordingly:
Railway stations
railway=station
railway=halt

I’ve also moved the Stations and stops section from OpenRailwayMap/Tagging to these tags’ pages to avoid confusion due to mismatched tagging schemes:
railway=station
railway=halt
railway=tram_stop

[rurseekatze]

Thank you @gymate for your work so far.

Please excuse my late reply. This is a complex issue that requires enough time to think about. Now I have finally found the time.

As there is a lot of discussion here to read through, I will comment on single posts and the questions where you mentioned me later.

First some general information about mapping stations as nodes vs. areas and why I preferred nodes in the past but now think that areas are the better solution:

The area of a station differs significantly depending on whether you look at it from the perspective of public transport or railway operations. In addition, every public transport station is a train station, but not the other way around (e.g. freight stations). A public transport station includes the platforms, the station building, and overall the areas that are accessible to passengers. The railway infrastructure differs from this: the station building is irrelevant here, but the station area may still include yard tracks, signal boxes and engine sheds. The station is defined by certain signals and switches, so that it can be significantly larger than what the passenger perceives as the station.

In summary: It makes sense to capture both views with separate objects in order to be able to clearly distinguish between the two topics (public transport and infrastructure).

In the past we tried to combine both views in a single feature (partly also for backwards compatibility with renderers), but then you end up mapping a node as a compromise to satisfy both views. But this brings new problems like not being able to query the signals of stations because there is no information about the extend of the station. Which then requires workarounds like the railway facility relations.

Today I think the far better solution is to clearly distinguish between railway operations and public transport view and map both as detailed as possible, which means mapping them as areas.

The updated illustrations and wiki pages are definitely going in the right direction and making things more clearer by separating between both views. But I would still have a few suggestions:

Facility relation

I would suggest abolishing railway=facility. We (mainly Nakaner and I) introduced this at the time in order to be able to map stations as points on the one hand and to be able to do queries such as “which station does this signal belong to” on the other hand.

railway=facility never really caught on because mapping it was time-consuming and there was no application back then that used it. I’ve actually never really used it myself, too. But the main reason might be that the tagging design was bad:

• I agree with some other comments here that mixing railway=facility with public_transport=stop_area was not a good idea. This resulted in complex and confusing tagging like type=public_transport + public_transport=stop_area + railway=facility for passenger-stations and railway=facility without any type=* for non-passenger stations (by the way impossible to create intuitive tagging presets for that). It also resulted in mixing public transport members such as stop_positions and subway_entrances with features such as the landuse from a railway operations perspective.
• The facility relation duplicates a lot of tags of the railway=station feature.
• The facility relation maps one real world feature as two features in OSM, which is not a good practice.

Now with the recommendation to map railway=station as areas (for the infrastructural boundaries), I no longer see any need for the workaround with railway=facility and propose to deprecate it. It is just redundant information because the information is either already mapped at the station area or can be queried with a simple geometric query without having to maintain a relation and manually adding each signal (can be a lot in bigger stations).

Landuse

Tag:railway=station - OpenStreetMap Wiki suggests:

Do not tag the station area with landuse=railway as this is already implied by railway=station.

It seems illogical to me that there is no land use within the station boundaries, but outside there is. For me it appears a bit like “you do not need any landuse=residential if there are building=detached because they implicate landuse=residential”.

I would avoid such implications as they make using the data difficult. It is necessary to know such rules when rendering a map. And instead of considering just all features with landuse=* to render a landuse map, it is necessary to also consider stations features.

I would prefer to add landuse=railway` at the station area.

local_ref

I would suggest to replace ref=* at the platforms by local_ref=*. This reflects the local character of this id in contrast to global or operator wide identificators in ref. Would also be more consistent to use local_ref both at platforms and stop_positions as it contains the same data.

Backwards compatibility

A problem I see is the compatibility with existing data users, for example OSM Carto. OSM Carto renders railway=station, but should better use public_transport=station instead to avoid the known problems with unexpected labelling.

[rurseekatze]

I hope my previous post describes the thought process and answers all questions regarding railway=facility.

railway=site was used for all kinds of “stations” which do not fit into the other categories (yard, crossover, junction, service_station, halt, station): subparts of stations (“Bahnhofsteile” in Germany), interlockings securing movable bridges (“Deckungsstelle” in Germany) or manual block posts between stations (“Blockstelle” in Germany).

railway=site should not be confused with type=site.

[gymate]

@rurseekatze

Please excuse my late reply. This is a complex issue that requires enough time to think about. Now I have finally found the time.

Yeah of course, no worries! Thank you very much for your reply.

@rurseekatze

I would prefer to add landuse=railway` at the station area.

I agree!

[gymate]

@rurseekatze

I would suggest to replace ref=* at the platforms by local_ref=*. This reflects the local character of this id in contrast to global or operator wide identificators in ref. Would also be more consistent to use local_ref both at platforms and stop_positions as it contains the same data.

Yeah, it would be a good idea to use the local_ref key for railway station platform letters (e.g. in Slovakia and Czechia) or numbers (at most places).

[gymate]

@rurseekatze

It is just redundant information because the information is either already mapped at the station area or can be queried with a simple geometric query without having to maintain a relation

Yeah this would be much easier, but is there a query to download only the elements of a single station where it overlaps (or is overlapped by) another one? E.g. the RER station Charles de Gaulle — Étoile on layer -5 which is overlapped by Métro 2 on layer -3? Because this query for the elements of the RER station also downloads the tracks of Métro 2 (when it works) which could lead to duplicate reference numbers.

Currently this is a rare occasion as most railway=stations are mapped as nodes, but if most of them were mapped as areas, this would be much more common.

[drolbr]

Hi,

in general, I recommend to first look only at ways and then split by
level. You can then get level by level going through the numbers

way(680443640) ->.searchArea;
way(area.searchArea)[level=-5];
out geom;

If you wonder how to get the numbers in the first place then you can use

way(680443640) ->.searchArea;
way(area.searchArea);
make info level=set("{"+t["level"]+"}");
out;

If you want to edit the data then you could use

way(680443640) ->.searchArea;
way(area.searchArea)[level=-5];
(._;>;);
out meta;

but the caveats of Sparse
Editing
apply. Another approach would be to download full data and use the JOSM
level filtering instead.

Relations and nodes are insofar of lesser interest here because they
usually do not carry a level indicator.

[gymate]

@drolbr

If you wonder how to get the numbers in the first place then you can use

way(680443640) ->.searchArea;
way(area.searchArea);
make info level=set("{"+t["level"]+"}");
out;

Thanks, I didn’t know about this! The query results in the following XML element:

<info id="1">
    <tag k="level" v="{-2};{-3};{-5};{}"/>
</info>

So—as far as I understand—this only shows which layers (or in this case, levels) have any elements that are covered by the search area. It doesn’t say which layer is the railway=station on.

@drolbr

way(680443640) ->.searchArea;
way(area.searchArea)[level=-5];
out geom;

And this one only works if you already know the layer number of the station.

So, I guess, the solution is to

1. download all railway=stations in the desired area
2. get their layer=* (e.g. using Python)
3. run a new query to download all elements that
   • are covered by each railway=station and
   • are on the same layer=*.

This means that a query for all 872 railway=stations in the world currently mapped as areas—which is roughly equal to the number of stations and stops (806) the Schweizerische Bundesbahnen has altogether—would be 6843 lines long.

This can’t be run in a browser calling overpass-api.de because it produces an URL that’s too long for the server (Error 414). But it can be run using overpy in a Python script, for example. (It takes an average of 1 minute and 40 seconds for the server to respond.)

So it’s possible, but I think that a built-in Overpass API feature would be nice to make this easier.

[gymate]

@rurseekatze

Now with the recommendation to map railway=station as areas (for the infrastructural boundaries), I no longer see any need for the workaround with railway=facility and propose to deprecate it.

I agree with this one too. I’ll update the illustrations accordingly.

[gymate]

Here it is:

@rurseekatze Please let me know if I have misunderstood anything.

[stevea]

Sweet, succinct. Two thumbs up, A+, making an “OK” with two thumbs and forefingers. I nod my head.

[gymate]

I’ve added two missing train=yes tags and updated both illustrations.

[gymate]

I corrected the instructions for adding labels to areas and multipolygon relations on the railway=station Wiki page. I tagged the following stations accordingly:

• Kimle-Károlyháza (as an area)
• Rajka (as a multipolygon relation)

I also added these to the Wiki as examples.

And I’ve opened an issue on GitHub regarding OSM Carto rendering railway=station labels twice.

[alan_gr (Alan)]

I’m a bit confused by the Carto issue. As a station should only have one railway=station object, it seems like a good thing that Carto renders two labels where there are two objects, as mappers are more likely to realise there is duplication.

I am also a bit concerned that the page is moving beyond clarifying current practice towards prescribing a new approach. It now gives high prominence to railway=facility which is rarely used in some (most?) countries. It now reads almost as if it is compulsory.

[gymate]

@alan_gr

It now gives high prominence to railway=facility which is rarely used in some (most?) countries. It now reads almost as if it is compulsory.

Thanks for the heads-up—I’ve removed all references to railway=facility from the railway=station Wiki page as agreed above.

I’ll also mark railway=facility deprecated on its Wiki page, if you agree.

[gymate]

@alan_gr

As a station should only have one railway=station object, it seems like a good thing that Carto renders two labels where there are two objects, as mappers are more likely to realise there is duplication.

It’s not intended as a duplication but as a correction to the rendering location of the label in the area (to avoid issues like these):

@Kovoschiz

Again, I will emphasize label in =site or type=label can be used for the meaningful and representative centerpoint if needed.

But @Kovoschiz, please correct me if I misunderstood your suggestion!