Talk:Tag:railway=platform edge

Non-standard multipolygon semantics

The documentation as currently written gives special semantics to multipolygons (beyond merely representing areas) by requiring that platform edges have to be relation members. I feel we should avoid these kinds of "side effects", as it means that multipolygons and other areas could no longer be parsed in a generic way by data consumers, and might no longer work the same way if we were to finally implement an area element in the API.

To remedy this, I suggest to only require that edges share nodes with the platform area. Multipolygon members would trivially fulfill this, so it wouldn't require changing how the platforms are actually being mapped. --Tordanik 18:00, 26 February 2018 (UTC)

I have now edited the page accordingly. --Tordanik 17:15, 23 April 2019 (UTC)

More hassle than it's worth

Why not just split the platforms so they each have individual references? https://overpass-turbo.eu/s/Vf7

This appears to be another example in OSM where the 'solution' to circumvent a 'problem'* is more hassle than fixing the original problem.

* Actually it doesn't solve it, as indicated in the wiki. If a platform edge has multiple refs it still requires ambiguous tagging: ref=4;5 (all numbers, separated by semicolons). Quite ridiculous.--DaveF63 (talk) 21:15, 18 June 2020 (UTC)

I recommend this tag be flagged as deprecated. It adds no benefits that mapping individual platforms as closed ways provides, and it's more difficult to map.--DaveF63 (talk) 21:15, 16 June 2022 (UTC)

Deprecation without a better replacement is not solving the problem. It's not much more difficult. I would argue drawing the entire island platform, then drawing the edge is easier than drawing two, or splitting it. (with JOSM's follow mode and parallel + split area tools in mind) --- Kovposch (talk) 04:13, 16 June 2022 (UTC)

Boarding point and door position is a further detail someone can add. --- Kovposch (talk) 04:13, 16 June 2022 (UTC)

What problems do you find with Tag:railway=platform_edge#Island_Platform_with_Two_Track_References_Behind_Each_Other? --- Kovposch (talk) 04:14, 16 June 2022 (UTC)

No, a platform is a platform (despite the common language of referring to platform edge as a "platform", elsewhere it would be "track"; boarding sections can sometimes be referred to as a sub-platform or sub-edge as well). A platform edge is a platform edge. Splitting an island platform arbitrarily down the center is unphysical and not based on reality. Platform edge doors are also very much a thing.

Functionally, this allows attributes on the island to be shared as one. Routers can more simply guide users to that island. Features on the island can be queried as in one area.

It is possible to have an island "platform" separated by walls in between, turning it to a pair of back-to-back side platform. This creates ambiguity on whether is one or two spaces, even if you require a barrier=* to be drawn between it. --- Kovposch (talk) 04:13, 16 June 2022 (UTC)

Mapping single platform as two because its sides are named goes against https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element Mateusz Konieczny (talk) 00:06, 24 July 2026 (UTC)

It really depends what you mean by "platform". An island platform which has tracks on either side, even though it may be one area I'd still consider as two different platforms because of the different platform numbers, eg. Platform 1 on one side and Platform 2 on the other side. For example https://www.openstreetmap.org/way/77091010 and https://www.openstreetmap.org/way/85691684 are drawn as two different platforms even though on the ground it's just one area you can walk across. By the way I just realised roads don't follow that rule in OSM, we split the road way every time the speed limit or parking changes... and duplicate the name hence have multiple elements for the single "road". Aharvey (talk) 00:24, 24 July 2026 (UTC)

I know mapping a single platform with tracks on either side as two platform objects is a common practice in use at least in Finland, in the UK and also in Sweden if I recall correctly. Sometimes the platforms are split into several parts where the platform is on a bridge or where some of the properties change. It should be appreciated that in OSM there are multiple ways to map things. Reasons behind different mapping styles differ. Sometimes there are real-world use cases like routing in public transportation route planners. Jplahti (talk) 21:58, 29 July 2026 (UTC)

@Mateusz Konieczny What do you mean by " its sides are named "? Can you provide an example?

Platforms should be mapped & tagged as per @Aharvey's examples. It is just two clear, closed polygons. Creating the equivalent as relations for platform_edges would end up with seven entities and tags duplicated & merged. I've seen examples in Britain where the person who created platform_edge cam back six months later to make further amendments, got confused by his own previous edits & made a right pigs ear.

@Kovposchsaid "Routers can more simply guide users to that island." Not true. A closed polygon is easy to navigate to. Name these routers which find it so difficult. DaveF63 (talk) 10:14, 8 August 2026 (UTC)

https://www.openstreetmap.org/relation/11031496 is a single platform with named sides, see https://www.openstreetmap.org/way/795625112 and https://www.openstreetmap.org/way/514880630 - and mapping this platform as two areas would be invalid Mateusz Konieczny (talk) 11:34, 8 August 2026 (UTC)

Those are two platforms & mapping them as 2 closed polygons is valid. DaveF63 (talk) 12:37, 8 August 2026 (UTC)

Nope, it is a single platform. ("Peron" = "Platform"). Tagging track 4 and 6 codes as platform edges is pushing things as actually codes are assigned to railway tracks, not to platform edges. Tagging railway tracks as two platforms would be 100% wrong Mateusz Konieczny (talk)

https://overpass-turbo.eu/s/Vf7 in this case you may in fact have different platforms touching each other and if that is true splitting it is correct. This does not make platform edge useless in other cases Mateusz Konieczny (talk) 11:36, 8 August 2026 (UTC)

The example you provided are "different platforms touching each other". DaveF63 (talk) 12:44, 8 August 2026 (UTC)

No, it is a single platform with one code. And tracks on its sides have own codes. If you would map it as two platforms where "peron 4" code would go ( https://www.openstreetmap.org/relation/11031496 ) ? Mateusz Konieczny (talk) 16:18, 8 August 2026 (UTC)

Say how to deal with potential ref=3A;3B

ref=4;5 (all numbers, separated by semicolons)

OK, but let's say we are dealing with 3A and 3B instead. Well then I would just leave ref=3, putting the details into railway=platform_edge only. Jidanni (talk) 04:02, 15 January 2023 (UTC)

It is sad railway platforms use ref=* for platform numbers, but e.g. buses use local_ref=*. Or actually different wiki pages say differently.

It is also weird why public_transport=stop_position nodes are tagged with local_ref=* in the examples. Aceman444 (talk) 12:50, 2 March 2025 (UTC)

One dimensional platforms

Currently platforms are modeled as unclosed ways or areas

True. But then only the latter is mentioned:

The platform is mapped as an area

OK but let's say we have encountered the former, and don't wish to change it.

So maybe mention for unclosed way platforms one can use railway=platform edge in combination with ref:left=* and ref:right=*[1]. Jidanni (talk) 04:17, 15 January 2023 (UTC)

(https://community.openstreetmap.org/t/two-sided-railway-platforms/7316/18?u=jidanni says no.) Jidanni (talk) 18:45, 16 January 2023 (UTC)

In such case I would map three lines (one for first edge, one for platform, one for edge). Or even better, if you bother with platform edges then map platform as an area Mateusz Konieczny (talk) 00:08, 24 July 2026 (UTC)

Clarification on "How to map"

Asking just to be sure.

In Poland, tracks/edges are numbered independently from the platforms, as can be seen for example here.
Such case is currently not covered neither by the wiki article text nor the example illustrations.

Should it mean that railway=platform gets ref=* number of the platform, and railway=platform_edge gets ref=* number of the track?

Regards, --Dzamper (talk) 22:16, 3 January 2024 (UTC)

Yes. Basically the documentation is a balance for compatibility, and reflects how the word "platform" is used for both the platform island and tracks of the edges in English.
But I disagree with Tag:railway=platform_edge#Cases_Where_You_Don't_Need_This_Tag example 2. That's a longitudinal case for the practice of splitting an island platform that this is trying to replace. There should only be 1 railway=platform + ref=1a;1b , and 2 railway=platform_edge .
—— Kovposch (talk) 11:51, 4 January 2024 (UTC)

I think railway=platform + ref=1a;1b should be split to railway=platform + ref=1a and railway=platform + ref=1b as that provides the most detailed information. Warin61 (talk) 00:22, 18 January 2024 (UTC)

railway=platform_edge is the detailed one that shows which side is used. Splitting railway=platform doesn't show the accessibility and facilities in common.
—— Kovposch (talk) 06:20, 18 January 2024 (UTC)

Tag is not recognized by Public Transport version 2

When used within PTv2 as a 'platform' PTv2 throws errors. My preference is to simply tag the platform area .. where there are 2 platforms - split them. Too easy? Warin61 (talk) 00:18, 18 January 2024 (UTC)

Whether and how railway=platform_edge should be included in public_transport=stop_area and route=* is unrelated to how they should be drawn. That's partly PTv2 falling behind the times, and validators not deciding what to do with them.
>1k are already included as platform , some being railway=platform_edge + public_transport=platform . A few as platform_edge , or empty role.
—— Kovposch (talk) 06:54, 18 January 2024 (UTC)

The page does not say whether platform_edge should be included as 'platform' members in the PTv2 relations. So if you include the public_transport=platform objects into the relations as usual, there will be no "error". Aceman444 (talk) 12:46, 2 March 2025 (UTC)

Effective length

Is there a way to tag the effective length of a platform, i. e. the maximum length, a train could have, to approach a platform edge? --Mappalup (talk) 13:33, 5 April 2024 (UTC)

Not really, as train may be longer than platform at which stops (with passengers instructed to go backward/forward until they reach wagons on platform). And effective length of platform edge is mapped by marking it as a lone so no extra tag is needed Mateusz Konieczny (talk) 11:38, 8 August 2026 (UTC)

data user

Is there an application that uses this data ? I would like to test pedestrian routing to platform X at station Y Marc marc (talk)

Finland's Digitransit project uses this data for pedestrian routing. https://matka.fintraffic.fi/?locale=en --Jplahti (talk) 18:41, 2 December 2025 (UTC)

Missing platform types

There is no provision on this for how to map bay platforms of both single track (ie. one platform with two platform edges on each side of the track) or double-track (two tracks, each with separate opposing platform edges, but share the same physical U-shaped platform) variants.

ref vs local_ref

There's an argument for using ref=* for the network wide stop identifier and local_ref=* for the local identifier within the station, so platform numbers like 1,2,3 would be tagged with local_ref=* Aharvey (talk) 01:11, 14 March 2026 (UTC)

It follows railway=platform supposedly. You would have to change them together, else they are inconsistent with each other.
I guess the logic is railway=stop needs to be handled system-wide, but railway=platform only needs to be treated per-station. Therefore the former is ref=* + local_ref=* , the latter ref=* only.
—— Kovposch (talk) 08:05, 14 March 2026 (UTC)

Agreed, the reference for railway=platform and railway=platform_edge must go together. If you're tagging a ref=* on railway=stop for a system-wide identifier, how do you then associate the platform with the stop?

For example 6553012209 6553012209 is a railway=stop with a network-side identifier ref=206451 and then local_ref=1 as the platform number of the stop. This can then be matched with 1488714335 1488714335 tag as the associated platform edge for the stop. So to me looking at this example, using local_ref=* for the platform number makes more sense. --Aharvey (talk) 01:35, 15 March 2026 (UTC)

You make no argument. You state what you'd like to see, but not why. There was a similar discussion on Talk:Key:local ref (which is where this discussion should be), where no one stated clearly what "the operator-wide or network-wide number or reference code" actually was. For the platform tag there are only 1103 cases worldwide where the two tags aren't equivalent (just 82 in Australia), & many of those appear to be errors rather than separate databases. For platform_edge there are only 17! (4 in Aus.). I've long suspected this tag was conceived by those advocating PTv2, but have never really comprehended the purpose of either PTv2 or relations. As already stated I believe platform_edge is a pointless entity. There is nothing that tag claims to achieve that can't be done by mapping simple closed polygons for each referenced platform. It was a tag created by those who just have to create something new & shiny - "Hey mum, look what I made". It does nothing to improve OSM's database quality. --DaveF63 (talk) 22:54, 14 March 2026 (UTC)

I noticed what I thought was a bit of discrepancy and inconsistancy between usage of ref=* and local_ref=*, and wanted to raise it for discussion to see what others in the community think. I don't mean to say it should be one way or the other, only I can see reasons for doing it either way, and would like to see a community consensus around it to provide mapping guidance to mappers. You're looking at actual tagging numbers, but in my case I'm hesitant to start changing tags without a consensus and guidance documented on the wiki.

> There is nothing that tag claims to achieve that can't be done by mapping simple closed polygons for each referenced platform

It tells data consumers which side of the closed polygon is the platform edge, in some cases you might be able to do some geospatial processing to work out which edge runs parallel to a nearby rail line, but usually we try to map and tag things to avoid such geospatial processing by data consumers. Then not all cases that works, for example an island platform wedged between two rail lines, but one rail line doesn't stop at the platform, without platform_edge you don't know which side of the platform you board. --Aharvey (talk) 01:30, 15 March 2026 (UTC)

Provide examples of "the operator-wide or network-wide number or reference code". Platform_edges are linear ways, not closed polygons. Explain how you can't work out which railway=platform closed polygon is nearest to the rail track yet can be done with a platform_edge linear way?

> an island platform wedged between two rail lines, but one rail line doesn't stop at the platform,

The route that doesn't stop won't have a railway=stop node. railway=stop should have a ref tag that corresponds with the platform ref. Platform_edges are meant to have nested relations to differentiate between stop areas & route relations which makes things more complicated than they need to be. For railway=platforms they're not required making it much simpler.

--DaveF63 (talk) 03:31, 15 March 2026 (UTC)

> Provide examples of "the operator-wide or network-wide number or reference code"

I did, up in my reply to Kovposch.

> Platform_edges are linear ways, not closed polygons.

Yes correct.

> Explain how you can't work out which railway=platform closed polygon is nearest to the rail track yet can be done with a platform_edge linear way?

It's not about working out which railway=platform way area is nearest to the rail track, it's about which segments of that closed way are for the platform edge, and which track/stop is it attached to.

> The line doesn't stop won't have a railway=stop node. railway=stop should have a ref tag that corresponds with the platform ref

Yes correct. If the railway=stop node is using a network wide ref, and the platform using a local platform number, then they'll need to be aligned with respect to ref=* vs local_ref=* hence my thinking that it makes sense to use local_ref=* for platform numbers, leaving ref=* for the network-wide identifier.

> platform_edges are meant to have nested relations to differentiate between stop areas & route relations which makes things more complicated than they need to be. For railway=platforms that's not required making it much simpler. Many edges are mapped incorrectly such as this one, where the route relations aren't correctly placed on their specific edge but plonked within the nested relation for the whole platform. It also doesn't have a stop area relation.

I'm not considering relations at all here, this is just about where you use railway=platform_edge as a linear way along part of (ie. sharing nodes) of a railway=platform area to denote which parts of the platform are the edge, and linking the platform edge, platform and stop together via a consistent ref. Using relations is separate to this.
-- Aharvey (talk) 03:44, 15 March 2026 (UTC)

If platform edge is signed with code 3 and has some 4672467247248282824646754474783828 guid in some database, then it should have ref=3 and that unique code should go into some separate tag Mateusz Konieczny (talk) 00:12, 24 July 2026 (UTC)

And if it's signposted with Stop ID 1234 Stand A? then the next platform down is Stop ID 1234 Stand B, but further down it's Stop ID 1235. This happens for bus stops and hence we use ref=* for the network wide stop identifier and local_ref=* for the local platform identifier, but for train stations we're using ref=* for the local platform identifier, so ref=* and local_ref=* are used differently depending on if it's a bus platform or train platform, so I can see the arguments for applying ref=* and local_ref=* more consistently across both bus, train and other public transport modes. Aharvey (talk) 01:33, 24 July 2026 (UTC)

So "Stop ID" is prominently signed but it is neither specific to a platform and single bus stop will have multiple stop IDs? Mateusz Konieczny (talk) 04:38, 24 July 2026 (UTC)

Yes, I've given the examples previously in this discussion where both the Stop ID and the Stand numbers are signed, you could have multiple highway=bus_stop but they all form part of a single bus station, where each platform within the station has the same Stop ID but different Stand numbers, hence both ref=* and local_ref=* are signposted on the sign. Aharvey (talk) 04:58, 24 July 2026 (UTC)

Sorry I was wrong, in the case I was thinking of with different Stands, they do have different Stop IDs for example https://www.openstreetmap.org/node/1354677118 and https://www.openstreetmap.org/node/4341871592. My point was that in this case we use ref=* for the network wide ID (Stop ID) and local_ref=* for the Stand number, which is local to the station area only. Train platforms, for example Platform 1, 2, 3 are also local only to that station, not network wide, so we could be using local_ref=* for the platform number like 1, 2, 3. I thought it would be nice to make that distinction. Aharvey (talk) 10:35, 25 July 2026 (UTC)

I do not have experience with such cases but this looks like (1) really annoying situation (2) this proposed solution being quite ugly. But maybe alternatives also would be ugly. I definitely dislike this one Mateusz Konieczny (talk) 12:19, 25 July 2026 (UTC)

Around here in Finland especially in Helsinki region where similar ID system is in use, mappers have chosen to not use railway=platform_edge at all but map platforms as distinct objects instead. I.e. island platforms with tracks on either side are divided into two railway=platform areas with the appropriate ref=* and local_ref=* values and the same ref=* and local_ref=* values are used in public_transport=stop_position nodes as well. There are many ways to accomplish things in OSM. Jplahti (talk) 22:08, 29 July 2026 (UTC)

wait, why platform edges are supposed to get platform number instead of own codes

"unless platforms have their own numbering scheme independent of platform edge numbering scheme (e.g. in Poland), then platform number (e.g. ref=2)."

why platform edge with code "Tor 3" on platform 4 should get ref=4 ?

Mateusz Konieczny (talk) 00:10, 24 July 2026 (UTC)

Was added in https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dplatform_edge&diff=prev&oldid=2640910 Mateusz Konieczny (talk) 04:42, 24 July 2026 (UTC)

@Dzamper: - why you think that reference number of platform should be tagged on platform edge rather than reference number of platform edge? Why you claim that this is tagging used in Poland? Mateusz Konieczny (talk) 04:44, 24 July 2026 (UTC)

@Mateusz Konieczny I absolutely do not, please note that is a bullet point for "The platform is mapped […] with the following tags", the word "platform" is even in bold. The tags for the platform edge are listed further down. Dzamper (talk) 12:43, 24 July 2026 (UTC)

Oh right, sorry. though it is incredibly confusing to start how to map from mapping other feature (unlike basically any other how to map page). Maybe it can be flipped to start from mapping platform edges? @Dzamper: Mateusz Konieczny (talk) 16:41, 24 July 2026 (UTC)

Tried to make it less confusing Mateusz Konieczny (talk) 06:15, 8 August 2026 (UTC)