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)

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)

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)

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)