Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Nakaner opened this issue May 22, 2019 · 13 comments

Comments

Projects
None yet
10 participants
@Nakaner
Copy link

commented May 22, 2019

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

This comment has been minimized.

Copy link
Author

commented May 22, 2019

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

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

@quincylvania

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented May 22, 2019

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

This comment has been minimized.

Copy link
Author

commented May 22, 2019

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

@DaveF63

This comment has been minimized.

Copy link

commented May 22, 2019

Yes. Thanks. Updated.

@westnordost

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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)

@SelfishSeahorse

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

This comment has been minimized.

Copy link

commented May 23, 2019

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

@Nakaner

This comment has been minimized.

Copy link
Author

commented May 23, 2019

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

@openstreetmap openstreetmap locked as resolved and limited conversation to collaborators May 23, 2019

@bhousel

This comment has been minimized.

Copy link
Member

commented May 23, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.