Remove validation rule asking to add highway=footway to railway/public_transport=platform

[Nakaner]

In #6042 @quincylvania wrote:

man_made=pier
public_transport=platform
railway=platform

Features with these tags are expected to be part of the pedestrian network, but without highway tags it is more difficult for routers (and iD's validation) to support them. iD should add highway=footway automatically and recommend upgrading features lacking this tag.

I agree that they are part of the pedestrian network but calling it more difficult for routers to support them is a weak argument. It is easy to check two key because routers already check two key: highway and route (the latter for ferries and car shuttle trains).

Instead of making life easier, it makes it more difficult. Platforms are not just footways. They have different rules as normal footways in many countries. Many railway companies explicitly forbid cycling on their premises or require people to buy a ticket before entering the platform (without having barriers at the entrance!). Some routers intentionally not include platforms in their routing network because they are often not connected to the network. Others are working on treating them differently. For example, there is a pull request for GraphHopper treating platforms as push sections for bicycle routing.

As a developer of a routing quality assurance service, I would like to be able treat platforms differently without changing how GraphHopper works with the highway=* tag.

The difficulty to treat public_transport=platform as a part of the routing network should be fixed in the iD core, not by making mappers change tagging.

There are at least more than 10,000 railway platforms in Germany not having a highway=* tag and the German community (and I presume other communities in neighbouring countries as well) has been accepting the absence of highway=footway on platforms for at least six years.

The current implementation of the validation rule is buggy. Platforms can be mapped as nodes (usually bus stops only but exceptions exist), lines and areas. Currently, iD asks me to add highway=footway to a platform mapped as an area. That's wrong because the whole area is a platform, not its outline but highway=footway is a tag for linear features.

Therefore, the whole validation rule asking mappers to add highway=footway to railway=platform or public_transport=platform should be removed.

[Nakaner]

The same applies to leisure=track where iD suggests to add highway=footway.

• as a line: https://www.openstreetmap.org/way/173313008
• as a closed way: https://www.openstreetmap.org/way/516501138
• as an area with area=yes: https://www.openstreetmap.org/way/153292480

This sub-issue was initially reported by user AB-inf-x-chg-AB in German.

[quincylvania]

Hi @Nakaner, thanks for telling us about your use case.

The overall motivation behind these and similar recent changes is to replace implicit tagging with explicit tagging. Implicit tags make it harder for consumers to handle OSM data with certainty. A feature with highway=footway + access=customers + bicycle=dismount is much less ambiguous than public_transport=platform alone.

As for adding highway tags to areas, this is consistent with existing presets like Pedestrian Area. Routers can route along the edge or even across these features, or ignore them altogether.

[DaveF63]

Hi @quincylvania
Who else, beside yourself, took part in #6042 discussion?

You have your logic backwards.
A platform is, by default, accessible by people. It's what they are designed for in the real world.

And please don't knee-jerk close threads when there's clearly a discussion to be had. It comes across as supreme arrogance.

[Nakaner]

@DaveF63 You meant #6042, didn't you?

[DaveF63]

Yes. Thanks. Updated.

[westnordost]

Please reconsider this.

I can't think of any use case where adding explicit data that can always be inferred implicitly from recorded data is a good idea.

Following your argument, this would be "tagging for the router", an anti-pattern in OSM. Worse, it is tagging for a supposed consumer:

It is trivial for any router software or other consumers to consider public_transport=platform ways and areas for pedestrian routing and as far as I know, routers already do that.

I think @Nakaner already mentioned this, but a footway on a public transport platform has actually a detrimental effect because consumers may want to treat public transport platforms differently from footways.

For example, a quest in StreetComplete asks whether foot- and cycleways are segregated or shared. It doesn't make sense to ask that for public transport platforms or sport tracks.
When data consumers are looking at footways, they primarily expect footways, not other things that should be equally routable as footways. Paved brownfields may also be traversable by pedestrians, that doesn't mean they are footway areas.

The moral of the story: We only map what is on the ground.

[matkoniecz]

Adding footway tag to platform mapped as areas is weird and something that was not done before.

Platforms mapped as areas like https://www.openstreetmap.org/way/234100234#map=19/50.06524/19.95277 are not squares, adding highway=footway to them is incorrect.

Bus stop platform should not interupt footways, but platform itself has no need for footway tag on its area as it is not a square

[tohaklim]

I think there are two separate issues here, incorrect footway area tags (as for a linear feature) and shoehorning of router hacks into existing features (I was thinking all of the mature routers support these cases out of the box already).
It’s unfortunate to see iD pushing undiscussed/undocumented uses for tags (see also crossings)

[ghost]

I agree that adding highway=footway to platforms is not only redundant, but (as pointed out by Michael) is bad because platforms often have different access restrictions than highway=footway. iD's validation rule should be removed.

[boothym]

The overall motivation behind these and similar recent changes is to replace implicit tagging with explicit tagging. Implicit tags make it harder for consumers to handle OSM data with certainty.

Surely unless you add highway=footway to every single platform on the map, you won't have explicit tagging? Given how long it will take people to add the tag to all the platforms using iD, wouldn't it be easier for routers to treat platforms as routable on foot by default?

[AllroadsNL]

highway=platform is the tag on ways over the platform, where also tactile_pavement is tagged on.

[Nakaner]

@quincylvania This topic is subject of a discussion on the Tagging mailing list. https://lists.openstreetmap.org/pipermail/tagging/2019-May/045462.html

[bhousel]

Hey all, I've locked this topic. Inviting other people to jump on the thread just to express disagreement is not very helpful.

I'll try to respond to all the serious points in the thread but tl;dr - I agree with @quincylvania .

There exists no master list of all the routable features in OSM. This is because people are always making up tags. It is unreasonable to expect mappers and data consumers to "just know" what all the tags are that are routable.

For example - consider a path connected to a pier connected to a ferry - you either need to just happen to know that man_made=pier is routable (implicit tagging), or you need to add a highway=* tag to it (explicit tagging). Those are the only two options, and the first one is really untenable.

Mappers will never know all the magic made-up rules for where people can walk. Developers can not know this either. Even if the handful of people on this thread all decided right now that "from now on man_made=pier is routable" that's one extra rule that we need to add to all of our documentation and code. Let's not do that.

This same issue has come up several times in recent memory.
"Your software should just know that highway is allowed to cross building=roof"
"Your software should just know that bridges without a level tag can cross waterways"
"Your software should just know not to split ways with a transit:lanes tag"
"Your software should just know that service tags can mean different things depending what they are attached to"
"Your software should just know that attraction=roller_coaster can either be an outline around the attraction, or a line along the track itself "
"Your software should just know that rail platforms should connect to paths"
"Your software should just know that golf cartpaths are really highways"
"Oh and piers too"
"Oh and jetways"

iD is taking a very consistent approach in that for issues like this, where we can replace an implicit rule with an explicit one - we add the extra tag. In cases where a tag has multiple meanings, we only support a single unambiguous use. We don't expect people to "just know" what all OSM's made up rules are.

Some things that don't really factor at all into our decision:

• how long a tag with implicit semantics has been in use
• how many softwares (renderers / routers or whatever) already support the implicit rule
• how frequently the tag is used
• what a handful of people on a mostly dormant mailing list think
• what one person has written on the osm wiki
• how many downvotes you encourage people to put on our issue list
• what they are saying about us in the weekly osm tabloid

Aside: None of this is new. One of my first experiences with OSM was watching the Craigslist devs get shamed for rendering buildings with building=no then having people on mailing lists complain that their software was broken because they should "just know" what all the rendering rules are. We can do better to make OSM a welcoming project for data consumers - renderers, routers, or whatever anyone wants to build - and iD as a project will continue to simplify and demystify the tag situation however we are able do so.

Some people will disagree, and that's ok.