Railway=station as an area?

I’m not sure about this. If we were to start using railway=site to tag areas that mark the boundaries of railway operating sites (and only those), we would immediately have 9,592 invalid usages on nodes.

Because using it on areas has always* been allowed. It’s just not that popular.

* Almost always—since 2009, to be exact.

I see. Do you have any other suggestions?

I don’t think anyone suggested that. Or am I reading it wrong?

I would prefer if we kept using the existing railway:position=* and railway:position:exact=* instead of a more complicated type=site relation. Eliminating the need to use relations for things that could be tagged more simply was one of the reasons for deprecating railway=facility.

place= being points is a consequence of its meaning, not the reason. It’s an abstract concept for a settlement or community, which can be imagined as its center. Therefore drawing an exact area is unsuitable. This is distinct from boundary=administrative being prescribed from the administration and exactly defined.

a settlement or community has an extent also when there are no formally prescribed boundaries, you can tell what is inside a settlement and what is outside because you imagine some kind of area and limit. These limits can be very precise, like city walls of a palisade, or a modern suburban settlement with gardens and maybe fences adjacent to fields, or it can be blurrier, but mostly you can see the limit of settlements (or they have grown together and there will be administrative limits, or the dwellings are dispersed and there isn’t much of a settlement to represent anyway). I don’t say the centre isn’t useful for places, but there is an area as well, and a point is not the best representation for an area.

this is not what is “allowed”, it is what is done.

1 Like

“Since 2009” says something 15 years later. We pay attention to that. It IS what is done. Nobody is “allowing” anything. We find ways to get along. There really are “ways they do things there” vs. “ways we do things here” going on, it is real.

For the quintillionth time, we all win when / as many heads are nodding. This isn’t a one person wins contest, please.

There is some nodding here, there is some not nodding here. Welcome to OSM. It’s a big place.

2 Likes
  • =milestone : In the above discussion, it was suggested that railway=station should be a point corresponding to the official linearly referenced position on the line. This is then unclear why =milestone shouldn’t be used instead.

  • railway:position= : This is mostly used on points on the =rail track, especially because of the relationship with how it is measured along the track. =station is a standalone unattached point. There are only 1673 node[railway=station]["railway:position"] . This treatment is not mentioned in Tag:railway=station - OpenStreetMap Wiki yet.

  • railway=site : It can be similarly allowed on both points and areas. This can align with other OpenRailwayMap/Tagging - OpenStreetMap Wiki (whether areas should be used by =yard is another question that should be asked). To reiterate my opinion for the routability concern, using the =stop etc points directly is better.
  • railway:site= : If expanding railway=site is not desirable, we should find a term that can be more easily understood in English. “Operating site” is quite oblivious.

I’ve fixed this.

Edit: @DaveF also removed this.

But initially this would still require a massive retagging of 9,589 nodes, which I would advise against.

I respect your opinion, but unless you have a specific suggestion (other than railway=site, which would cause a lot of problems as described above), I recommend staying with railway:site=area.

Here is the illustration updated accordingly:

Please share your feedback on this!

1 Like

Good work! This looks much closer to how I’d expect a basic railway station to be mapped.

I’d advise against local_ref=* altogether. In North America at least, we don’t tag track numbers on the railway=stop nodes because that information is usually present on the underlying way as railway:track_ref=*—tagging this on the stop position would be redundant work for no benefit. As for platforms, we use ref=* instead of local_ref=*, as recommended by the wiki page for railway=platform.

I’d also remove train=yes from the diagram, or change how it’s presented, because all these guidelines also apply to subway=yes, light_rail=yes, etc.

That’s a good point. I’ve updated the public_transport=stop_position wiki page accordingly and removed it from the illustration.

Done!

Indeed! Also done.

2 Likes

Can you explain why allowing =site on both points and areas requires “retagging”?
If you treat railway:site= as a feature, you now invented a new feature other than railway= for some reason. If it is an attribute, you are missing a feature. Using railway:site= suggests it is related to railway=site .
=area has no meaning. There are no other railway:site= defined alongside. It might as well be =yes .
I considered area:railway= similar to area:highway= . That only solves the operational area part. So still, this results in public_transport=station needing to be separated from railway=station / area:railway=station for the passenger area.
The problem with linearly referencing railway=station is that it is not attached on the railway= track. This is goes against the rest of railway:position= uses.

This assumes track number is the same as “platform number”. Besides having to know whether there is a track number, this fails to consider different stops on the same track corresponding to different platform sections. Tag:railway=platform_edge - OpenStreetMap Wiki
If it is recommended that local_ref= only be used on those cases, the data becomes difficult to check. A transit application using =stop and =platform only won’t have the railway:track_ref= on the railway= track. They would need to know this, and do extra processing to join the railway:track_ref= from the railway= track to the =stop .

=stop local_ref= != railway= railway:track_ref= :

Maybe somehow related @gymate recently Adding the track side to route=railway relation members

My main concern is that I do not see the point of using a tag, that is used to indicate the railway operating site perimeter, on nodes.

Currently railway=site should be applied on areas or nodes of railway operating sites that do not fit into any other category (railway=station, railway=halt, railway=yard etc.). Any change to the tag would “dilute” this category, so elements tagged with it would lose some info about them—i.e. that they are operating sites that do not belong in the category of railway=station or railway=halt etc.

Also, if we were to repurpose railway=site, a replacement would be needed for it.

I see your point, but the reason for this is:

Also, the meaning of the railway:(operating)site phrase would cover all categories.

Thanks, I didn’t know about this tag. I think matching an existing format is a good idea, so we could change railway:site=area to area:railway=site, if others agree.

2 Likes

The main concern with this is area:railway= was suggested long ago for the trackbed / ballasted area (smaller than a landuse=railway , or there may be no landuse=railway if elevated; while much of the existing uses are area:railway=tram which will conceptually be inside landuse=highway ). This is similar to area:highway= for roadway areas. The use of area:railway= =station etc purely adopts it as a area representation of the railway= object.
Another option I thought about is using type=boundary + boundary= =railway / something. The requirement of using rel is more complicated.
But regardless of this, what’s the view on public_transport=station again?

I do not like the removal of ref=* and local_ref=* from public_transport=stop_position.

  • These tags are still in use as combination with public_transport=stop_position
  • public_transport=stop_position is used for all kinds of transport modes and there is no corresponding tag to railway:track_ref=* for road based vehicles.
  • Even with railway:track_ref=* in place it adds extra burden to find the pair of platform and stop position as you need to look at the parent object. Sometimes little redundancy does not harm.

Again, this might be true for railways but not for bus stops.

Right, the ref tag is used on about 175k stop positions, including all local bus stops in my region, where it contains the reference used by the city bus operator. Why remove it from the wiki?

More generally, I’m not sure if it is a good idea to change pages that affect all types of public transport as a casual side-effect of a discussion about railway stations (I had overlooked that you said you were doing this until @skyper mentioned it). There are something like 3.6m bus stops mapped in OSM compared to only 0.1m railway stations, so any changes to public transport require a good knowledge of how buses and other forms of transport are mapped in practice.

3 Likes

To clear up any confusion, here are some statistics about current usage of tagging combinations that denote the track number at a railway stop:

Other countries not mentioned appear to have a mixture of the above tagging schemes.

My point about ref or local_ref being redundant on a railway stop is that railway:track_ref, in its original definition, was intended to represent that track number.[1] In countries where it’s common to simply tag railway:track_ref=* and leave the railway=stop without a track number, it would be unreasonable to enforce a tagging scheme that requires each stop to match the track number of the underlying railway.


  1. This definition was expanded about 4 years ago to represent “track number” more broadly. ↩︎

I have reverted the changes of Tag:public_transport=stop_position - OpenStreetMap Wiki, see diff (@gymate).

1 Like