Railway=station as an area?

[clay_c (Clay Smalley)]

@Kovoschiz

But the question then becomes how do you indicate the linearly referenced station location (around the “middle”) you asked for on such through stations, when the ticket hall is not centered (off to one end, as far as one extreme end or even beyond the platforms), or the building=train_station exists with a different length.
If both requirements (linear referencing, and ticket hall) can’t be satisfied together on all stations, should you really use railway=station for both purposes?

The linearly referenced position is already approximate to some degree. In the US and Canada, most values of railway:position=* are rounded to the nearest tenth of a mile (= 528’ ≈ 161m). There’s a lot of leeway here—I think station buildings and platforms should take precedence over the linear referencing position when determining where to place station nodes.

@Kovoschiz

Problem 2. When a station is the start of multiple lines, and they have zeros at different positions, where do you put the railway=station ? How do you indicate all the zeros of each line?

Are there any real-life examples of this?

Moreover, I would expect the label placement of such a complicated station to be superseded by the building or platforms.

[Kovoschiz]

I will give an extreme case. For the north-south oriented Tokyo Station, the Keiyo Line platforms are east-west, 400m to the south. Node: ‪東京‬ (‪6396868335‬) | OpenStreetMap
That’s assuming all others line-up. The Sobu-Yokosuka Line platforms are diagonally oriented, to the northwest. Node: ‪東京‬ (‪7093706976‬) | OpenStreetMap
They are all connected inside a paid zone. Of course, these can still be argued whether separate =station points can be created for them. (The other 2 existing =station points are for Shinkansen in a different paid zone, and another by a different company)
I’m not sure what should be used for the precision, or railway:position= . At the Keiyo Line example, there is both 0km Type A post, and 0.0km Type C post per 100m (Type B is half-km), besides the 0.000km for railway:position:exact= I suppose. 東京駅のゼロキロポスト＋α　～　在来線・地下編（京葉線）　～ - 歩・探・見・感 https://cdn-ak.f.st-hatena.com/images/fotolife/c/citywalk2020/20240310/20240310144419.jpg
As another comparison, the zero for a bay platform terminus can yet not be at the end. In Odakyu Shinjuku Station, it’s 40m away. 小田急の新宿駅にある0キロポストはなぜ変な位置にあるのか : Odapedia ～小田急のファンブログ～ https://livedoor.blogimg.jp/odapedia/imgs/e/0/e0284cd6.jpg (the end is on the left side in the background)
So what I want to suggest is =station doesn’t really correspond to the linear referencing function you were emphasizing. I believe what’s actually needed is an attribute eg linearly_referenced=yes to show a =station point is at that position, and another feature eg linearly_referenced:railway=station for the station sign when the =station is separate as linearly_referenced=no (Or use =milestone somehow, as how I asked about it). Distinguishing routing and linear referencing will clearly express the situation on their own. Then =station can be focused on the routing target.

[dieterdreist (Martin Koppenhöfer)]

None of these routing services can take station entrances into account.

but this is a shortcoming of these routers, try to route to Rome Fiumicino Airport and you get led several kilometers off the terminal buildings. If we keep “helping” Routers with nodes to represent stations this will not change so quick

[gymate]

Maybe. But even if that were fixed, the other issue about rendering the label would still persist.

[SomeoneElse (Andy Townsend)]

@gymate

None of these routing services can take station entrances into account.

Something of an aside from the whole “railway=station as an area” question, but as of about an hour ago the mkgmap maps created here will route to train station buildings. It’ll avoid issues like this where a router will terminate vertically below the station rather go to an entrance.

[Kovoschiz]

Thunderforest Transport (and Cycle), and OPNVKarte renders it acceptably, in the main section opposite the mall. Only CyclOSM, and Humanitarian have similar results. Map Compare | Geofabrik Tools
I uphold the argument about Drawing (although not lying) For Renderer, and Router, but there can be a transition period as railway=station has been specified and existed as points, and considering the number and prominence.
On the other hand, even then, @dieterdreist still needs to consider whether the =station area should be drawn for the operational border (currently to be area:railway=station) , or public passenger area (missing now from the requirement of railway=station + public_transport=station combination)

[dieterdreist (Martin Koppenhöfer)]

On the other hand, even then, @dieterdreist still needs to consider whether the =station area should be drawn for the operational border (currently to be area:railway=station) , or public passenger area (missing now from the requirement of railway=station + public_transport=station combination)

IMHO railway=station for the operational site and public_transport=station for the passenger area(s)

[gymate]

@Kovoschiz

Thunderforest Transport (and Cycle), and OPNVKarte renders it acceptably, in the main section opposite the mall.

I wouldn’t consider 175 metres from the nearest platform (and 600 metres walking distance from the nearest station entrance) acceptable. It’s quite misleading. Anyone arriving there would find themselves in front of this wall:

[SomeoneElse (Andy Townsend)]

… just to throw in some routing examples …

to the station building

to the “station area”

[gymate]

@clay_c

I feel like I’m going in circles making the same points over and over.

Me too.

@dieterdreist

IMHO railway=station for the operational site and public_transport=station for the passenger area(s)

You’ve already made this point here and I still agree with @Kovoschiz and @alan_gr on this:

@Kovoschiz

It’s not a good idea to separate them. No other mode has a public_transport=station alone without the corresponding feature.

@alan_gr

with the public transport tags as originally proposed, there was no way to tell that a station is a train station (as distinct from, say, a bus station) unless it has the railway=station tag. (I know some people get around this by adding train=yes, which was not part of the proposal).

So saying now that public_transport=station has a different meaning to railway=station is a fairly significant change.

I also summarised my opinion here:

@gymate

I agree with you that railway=station shouldn’t be separated from public_transport=station. The reasons are:

1. Changing how OSM Carto renders these tags would be quite a big change.
2. train=yes was not part of the public_transport=station part of the public_transport=* proposal.
3. The train=* key is most likely to be missing from the OSM Carto database.
4. Currently 36,192 public_transport=stations that are also railway=stations are missing the train=yes tag. And OSM Carto developers say that “we can’t render these properly unless mappers add bus=yes / train=yes etc. to each object.”

If you disagree with these arguments, please respond to them directly. (Which you’ve already done, to which I’ve also replied.)

[SomeoneElse (Andy Townsend)]

@gymate

I suggest that we use railway=yard for these—it was created for this purpose

Yes - example here.

[Kovoschiz]

That’s what I guessed. However besides separating railway=station + public_transport=station being non-ideal, as seen from the backlash at most it can only be area:railway=station for the operational border (which is more feasible here), then ultimately allowing railway=station + public_transport=station for the public passenger area in the long term.

[Kovoschiz]

May I say it’s acceptable for rendering. I only want to suggest the result can be different. As seen from the Mkgmap example, it should be technically possible to render, and route (if not an entrance= or =subway_entrance ), to the largest building=train_station inside a =station .
On a side note, railway=station has station= =train etc defined. So effectively, station= is being used with public_transport=station as well, aside from train=yes etc.

[gymate]

@Kovoschiz

it should be technically possible to render, and route (if not an entrance= or =subway_entrance ), to the largest building=train_station inside a =station .

Yes, but at what cost? @BáthoryPéter told me at the April OSM Hungary Meetup that this implementation would be far too expensive for basically any renderer’s backend.

Not to mention railway operating sites without building=train_stations.

@Kovoschiz

As seen from the Mkgmap example

(Not sure if mkgmap_style_ajt does this. @SomeoneElse only mentioned routing, not rendering. And as I understand the commit, it only adds an option to route to building=train_stations—it doesn’t select the largest or replace the corresponding railway=station element with it.)

[SomeoneElse (Andy Townsend)]

@gymate

it only adds an option to route to building=train_stations—it doesn’t select the largest or replace the corresponding railway=station element with it.)

With regard to rendering, both “stations” and “station buildings” are shown as stations, but it’s obvious which is which based on what you see when you either move the cursor over the object on screen, or search for it.

With regard to routing you’ll either pick a destination from the screen (after moving the cursor there) or more typically via a search menu. After this change the “ground transportation” menu now has “station buildings” as well as “stations”, but there aren’t that many railway stations.

@gymate

Not to mention railway operating sites without building=train_stations.

Yes, that is an issue - and there are also false positives doing it this way - this is actually a tourism-only station that would normally be excluded, and this should be excluded (but currently isn’t) for being only historic.

[dieterdreist (Martin Koppenhöfer)]

… just to throw in some routing examples …

to the station building

to the “station area”

what about: to the next public entrance of the station area?

[dieterdreist (Martin Koppenhöfer)]

then ultimately allowing railway=station + public_transport=station for the public passenger area in the long term.

just because train=yes which could solve the “problem” wasn’t in the “original proposal” we have to combine public_transport with railway=station? And introduce area:railway=station which is the same as railway=station but explicitly tagged as an area?

[gymate]

@dieterdreist

what about: to the next public entrance of the station area?

That would be this route.

[gymate]

@dieterdreist

just because train=yes which could solve the “problem” wasn’t in the “original proposal” we have to combine public_transport with railway=station?

Not only because of that.

• 78% of railway=stations are combined with public_transport=station. This is the established method of tagging railway=stations.
• Separating public_transport=station from railway=station and using train=yes with public_transport=station would only work if all public_transport=stations (incl. all other transport modes) had one of these *=yes tags. And that would take a lot of work.

@dieterdreist

And introduce area:railway=station which is the same as railway=station but explicitly tagged as an area?

Yes—see the area:highway=* tags, which follow the same logic.

[dieterdreist (Martin Koppenhöfer)]

Yes—see the area:highway=* tags, which follow the same logic.

not really, because area:highway is about a way to add the road surface to a linear highway, while area:railway=station would be a way to express the same as a node. Going by this logic, we could have area:amenity and all other kinds of keys for things that can be mapped as node or areas (almost everything, besides things that are actually points, e.g. saddles or peaks).