Railway=station as an area?

[Kovoschiz]

1. It doesn’t have to be railway=site . Could be something else. But the existing constraint of railway=site on “others” is unnecessary if you expand it to all sites. railway=station has ~94k points being the vast majority, doesn’t stop us from discussing whether areas can be used for it.
2. Then using railway:site= won’t be a good idea either, for confusion with railway=site

[Kovoschiz]

1. Perhaps half of the railway=platforms are drawn as lines, likely influenced by history as well. Does this prevent them from being changed to areas? Instead, other details are invented viz railway=platform_edge . You can make a new tag for the linear referencing. That would be clearer and more specific than defining railway=station as that. Using railway=station doesn’t remove the need for a railway=milestone . And how can you check which railway=station have been positioned according to the official linear referencing, rather than a random center someone picked?
2. 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. There may also be multiple place= of the same level in 1 boundary=administrative . As I mentioned, I’m in favor of making a new railway= for the operational area, but I find an railway=station + public_transport=station area appropriate.
3. I don’t understand what you are trying to compare from that section. I did suggest rendering with label in =site alongside perimeter .

[gymate]

@Kovoschiz

the existing constraint of railway=site on “others” is unnecessary if you expand it to all sites.

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.

@Kovoschiz

railway=station has ~94k points being the vast majority, doesn’t stop us from discussing whether areas can be used for it.

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

* Almost always—since 2009, to be exact.

@Kovoschiz

using railway:site= won’t be a good idea either, for confusion with railway=site

I see. Do you have any other suggestions?

[gymate]

@Kovoschiz

Using railway=station doesn’t remove the need for a railway=milestone .

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

@Kovoschiz

Eg milestone=station can be invented, and it can be linked in the type=site as station or label (the area would be perimeter ).

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.

[dieterdreist (Martin Koppenhöfer)]

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.

[dieterdreist (Martin Koppenhöfer)]

@gymate

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

• Almost always—since 2009, to be exact.

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

[stevea]

“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.

[Kovoschiz]

• =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.

[Kovoschiz]

• 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.

[gymate]

@Kovoschiz

There are only 1673 node[railway=station]["railway:position"] . This treatment is not mentioned in Tag:railway=station - OpenStreetMap Wiki yet.

I’ve fixed this.

Edit: @DaveF also removed this.

[gymate]

@Kovoschiz

railway=site : It can be similarly allowed on both points and areas.

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

@Kovoschiz

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 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!

[clay_c (Clay Smalley)]

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.

[gymate]

@clay_c

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.

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

@clay_c

As for platforms, we use ref=* instead of local_ref=*

Done!

@clay_c

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.

Indeed! Also done.

[Kovoschiz]

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.

[Kovoschiz]

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= :

• UK: 83 instances. It’s common to use railway:track_ref= for the track outside the station. At through stations, this entangles. Even if something else is used for up/down and fast/slow, these seem to be a valid railway:track_ref=
  • Milton Keynes Central: =Reversible * fast and slow track between fast and slow tracks paired by use. Way: ‪West Coast Main Line‬ (‪278034652‬) | OpenStreetMap
  • Faversham, and Ramsgate Stn: up and down =* Passenger Loop Way: ‪Chatham Main Line‬ (‪217385910‬) | OpenStreetMap
  • London Bridge Stn: Up and dn =*CS , and =DN CX , for Cannon Street, or Charing Cross Stn Way: ‪South Eastern Main Line‬ (‪35400802‬) | OpenStreetMap
• Germany: ~410 instances, seems mostly 3-digit railway:track_ref=
  • Frankfurt Hbf
    • A local_ref=1a Way: 154494960 | OpenStreetMap
    • I don’t know what slashing 2 numbers means when there is only 1 =stop Way: ‪Main-Weser-Bahn‬ (‪154495027‬) | OpenStreetMap
  • Dusseldorf Hbf Way: 636968130 | OpenStreetMap
• France: ~1050 instances
• Switzerland: 220 instances

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

[gymate]

@Kovoschiz

Can you explain why allowing =site on both points and areas requires “retagging”?

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.

@Kovoschiz

Using railway:site= suggests it is related to railway=site .

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

@gymate

If one would change the value of the railway=* tag on the railway operating site’s node*, they might forget to change this one too.

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

[gymate]

@Kovoschiz

I considered area:railway= similar to area:highway= .

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.

[Kovoschiz]

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?

[skyper]

@gymate

@clay_c

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.

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

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.

@gymate

@clay_c

As for platforms, we use ref=* instead of local_ref=*

Done!

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

[alan_gr (Alan)]

@skyper

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

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.