validator could consider a public_transport=platform way as routable

[stragu]

Hi all

This is clearly related to the discussion in #6409, but I haven't followed the discussion in detail and I am not aware of what made the developers change their mind on the suggested addition of explicit highway=footway tags by the validator.

In any case, I came across the disconnected_way issue in this object, because its connection to the whole network goes through a way tagged as public_transport=platform.

I'm wondering if the validator should consider the way tagged as public_transport=platform as a routable way. It seems to me it would be quite common to have detailed public transport stations in which, to cross from one side to the other of the building, you would have to walk on sections of platforms. The debate might be more relevant for areas, but isn't this straight-forward for a way?

And just taking the opportunity to thank you all for the great work on the editor 👍

[1ec5]

It would help to know which routers consider public_transport=platform on its own to be routable. The validator rule is essentially designed to inform the user about problematic routing that could occur, so it ideally wouldn’t get ahead of actual router support. I didn’t see any explicit references to this tag in the OSRM, Valhalla, OsmAnd, and OpenTripPlanner repositories, but I’m not as familiar with the OsmAnd and OTP codebases.

[stragu]

@1ec5 OsmAnd does seem to use it:

The only other mobile app I have is Organic Maps, which doesn’t even render a way tagged as such in its default rendering (and doesn’t use it in routing).

[1ec5]

Thanks for looking further into the matter. I’m not fully caught up on the discussion in #6409 either, but this does seem like a tricky situation.

Your example of Greenslopes platform 1 is tagged as highway=bus_stop on a way. This is invalid tagging, or at least not recommended, according to the wiki’s highway=bus_stop and public_transport=platform pages. I wonder if OsmAnd happens to route along this platform by coincidence due to the presence of a highway=* tag, but not because of highway=bus_stop or public_transport=platform specifically. OsmAnd doesn’t route over other ways tagged public_transport=platform without highway=bus_stop. The inconsistency may be a bug worth reporting in the appropriate OsmAnd repository (I’m not sure which).

I tested some popular OSM-based routing engines on this way and two others with different tag combinations. The consensus among routers seems to be that platforms aren’t inherently routable. Some come up with very circuitous routes, going out of their way to avoid the platform, while others come up with no route at all, suggesting an as-the-crow-flies path between two waypoints.

	Greenslopes 1	San Antonio 2	Meadowview
Tags	public_transport=platform highway=bus_stop	public_transport=platform railway=platform	public_transport=platform
BRouter v0.16.0	✅	❌	❌
GraphHopper	❌	✅	❌
Magic Earth v7.6.7	❌	❌	❌
Openrouteservice	❌	✅	❌
OsmAnd v4.0.6	✅	❌	✅
OSRM v4.6 (Organic Maps)	❌	❌	❌
OSRM v5.23 (FOSSGIS)	❌	✅	❌
Transit v5.10.4	✅	✅	❌
Valhalla (Mapbox)	❌	❌	❌

Magic Earth v7.6.7

OsmAnd v4.0.6

OSRM v4.6 (Organic Maps)

Transit v5.10.4

Note: Basemap is Apple Maps, but pedestrian route geometry is reportedly OSM-based.

Valhalla (Mapbox)

	Airport	Windward
Tags	public_transport=platform railway=platform	public_transport=platform
OpenTripPlanner v1.5.0 (MARTA)	❌	❌

Maybe this is just a matter of routers being slow to take up the public_transport tagging scheme, which was introduced relatively late compared to the tags that they do consider inherently routable. OSM is stuck in a yearslong limbo of public_transport=platform being widely dual-tagged with legacy tags – thanks in no small part to #4585 adding it to presets – but few data consumers supporting that tag on its own as an alternative to the legacy tags. Project-OSRM/osrm-backend#5410 and valhalla/valhalla#3691 request support for routing over platforms; there may be similar requests against other routers and renderers. If you’ll excuse the pun, I think more traction on these issues would make editor and validator developers feel a lot more comfortable treating platforms as inherently routable.

Another possibility is that data consumers are expecting platforms to be mapped as areas only. In the absence of area routing (osmlab/osm-planning#17), they may also expect the likely paths through those areas to be mapped as footways, just as in pedestrian plazas.

Even though tagging for the renderer router is frowned upon, the mere presence of this routability validator rule means some mappers will rely on it to be informed about any potential routing issues. So even if a mapper does care that the station they’re mapping is usable by the current generation of routers, the lack of this warning may lull them into a false sense of security.

What if the validator rule’s warning message were more transparent about what’s considered routable? Maybe it could determine that a particular public_transport=platform way is the gap in the routing network and point out that some routers may not consider it routable. This would have a side benefit of making the warning more actionable.

iD/modules/validations/disconnected_way.js

Lines 163 to 176 in 1ee45ee

	function isRoutableWay(way, ignoreInnerWays) {
	if (isTaggedAsHighway(way) || way.tags.route === 'ferry') return true;
	return graph.parentRelations(way).some(function(parentRelation) {
	if (parentRelation.tags.type === 'route' &&
	parentRelation.tags.route === 'ferry') return true;
	if (parentRelation.isMultipolygon() &&
	isTaggedAsHighway(parentRelation) &&
	(!ignoreInnerWays || parentRelation.memberById(way.id).role !== 'inner')) return true;
	return false;
	});
	}

iD/data/core.yaml

Lines 1756 to 1763 in 49f5d03

	disconnected_way:
	title: Disconnected Ways
	tip: "Find unroutable roads, paths, and ferry routes"
	routable:
	message:
	one: "{highway} is disconnected from other roads and paths"
	other: "{count} routable features are connected only to each other"
	reference: "All roads, paths, and ferry routes should connect to form a single routing network."

---

By the way, osm.org also has a routing feature that you may find convenient in debugging routing issues. Click the Get Directions button next to the search bar. You can select from a couple different providers to reduce the temptation to tailor your tagging to a particular routing engine’s quirks.

[stragu]

@1ec5 : thank you, this is the most thorough testing and review I have seen anyone do for any bug report I have ever created! It paints a very clear picture of the situation. 🙂

Thanks for the reminder to use osm.org to test the different routing engines, I should have thought of that earlier (especially given that I have done it in the past!).

So, if I understand it well, in a nutshell:

• The tag public_transport=platform is not currently widely used as a routable element by routers
• The warning is useful to notify mappers that the section will unlikely be routable in apps
• Furthermore, routers might assume all public transport platforms to be areas, and will therefore ignore them when routing
• The situation might change in the future, as many people think ways and areas tagged with public_transport=platform could logically be used by pedestrians

Is that an accurate summary?

I am wondering, as a small improvement to the validator message, if the text could be changed slightly, for example:

"{count} commonly routable features are connected only to each other"

Or, in a more verbose way:

"{count} routable features are connected only to each other (or are connected to the rest of the network by a feature not commonly considered by data users as routable)

In any case, I have reported the wish to see public transport platforms to be routable by OsmAnd, as it was not mentioned on any repository. Curious to see what the developers think of this one.

[1ec5]

I think this is a good summary overall. I honestly don’t know if or when the situation might change, since it depends on a number of software projects that don’t move in lockstep, some of which are no longer actively maintained (like the outdated version of OSRM embedded in Organic Maps). There may also be downsides or technical constraints that hadn’t occurred to us mappers. Since compiling the table above, I discovered that Openrouteservice does route over public_transport=platform ways – but curiously, it only works with the wheelchair profile, not the pedestrian profile. Filing feature requests against the routing engines, as you’ve started to do, is the best way to get everyone on the same page and move past the handwaving that took place in the past.

"{count} commonly routable features are connected only to each other"

I think this would be a good and easy stopgap fix. The explanatory text below it could elaborate if “commonly” is too ambiguous. This should just be a matter of modifying the strings here; please feel free to open a PR with suggested wording:

iD/data/core.yaml

Lines 1756 to 1763 in 49f5d03

	disconnected_way:
	title: Disconnected Ways
	tip: "Find unroutable roads, paths, and ferry routes"
	routable:
	message:
	one: "{highway} is disconnected from other roads and paths"
	other: "{count} routable features are connected only to each other"
	reference: "All roads, paths, and ferry routes should connect to form a single routing network."

Maybe it could determine that a particular public_transport=platform way is the gap in the routing network and point out that some routers may not consider it routable. This would have a side benefit of making the warning more actionable.

To elaborate on this idea, routingIslandForEntity() would maintain two routingIsland sets and two waysToCheck queues. It would store the gap way (a public_transport=platform way or perhaps any other way that’s likely to be undertagged) in a local variable and add it to the alternative routing island:

iD/modules/validations/disconnected_way.js

Lines 106 to 110 in 1ee45ee

	if (entity.type === 'way' && isRoutableWay(entity, true)) {
	routingIsland.add(entity);
	waysToCheck.push(entity);

And check both queues in parallel:

iD/modules/validations/disconnected_way.js

Lines 97 to 103 in 1ee45ee

	graph.parentWays(node).forEach(function(parentWay) {
	if (!routingIsland.has(parentWay) && // only check each feature once
	isRoutableWay(parentWay, false)) { // only check routable features
	routingIsland.add(parentWay);
	waysToCheck.push(parentWay);
	}
	});

In addition to the main routing island’s members, it would also return the gap way that resulted in populating the alternative routing island:

iD/modules/validations/disconnected_way.js

Lines 140 to 141 in 1ee45ee

	// no network link found, this is a routing island, return its members
	return routingIsland;

This would give the warning code the opportunity to identify the gap way explicitly, which would be helpful in case of a large routing island:

iD/modules/validations/disconnected_way.js

Lines 25 to 32 in 1ee45ee

	message: function(context) {
	var entity = this.entityIds.length && context.hasEntity(this.entityIds[0]);
	var label = entity && utilDisplayLabel(entity, context.graph());
	return t.html('issues.disconnected_way.routable.message', { count: this.entityIds.length, highway: label });
	},
	reference: showReference,
	entityIds: Array.from(routingIslandWays).map(function(way) { return way.id; }),
	dynamicFixes: makeFixes

This extra checking could significantly impact performance, but it would only be active under limited circumstances.

[stragu]

Since compiling the table above, I discovered that Openrouteservice does route over public_transport=platform ways – but curiously, it only works with the wheelchair profile, not the pedestrian profile.

Have you reported the issue to OSRM? Sounds like something they would want to sort out.

This would give the warning code the opportunity to identify the gap way explicitly, which would be helpful in case of a large routing island

That would be a great improvement. I did end up spending some time trying to figure out where the issue was as it all looked connected at first sight.

Regarding a potential PR, I will give that a go! Cheers 🙂

[1ec5]

Have you reported the issue to OSRM? Sounds like something they would want to sort out.

Touché. I think you meant Openrouteservice, though. It seems to be a different routing engine: GIScience/openrouteservice#1081.

[stragu]

@1ec5 I think there might be an inaccuracy in the testing of OsmAnd routing. I tested it and I got:

• routable on ways with both public_transport=platform and railway=platform (test with Corinda station)
• I noticed that your third screenshot uses the car profile instead of the pedestrian profile. However, I found a way with only public_transport=platform in my area and could confirm that OsmAnd does not route over it. For example: Normanby platform

Cheers

[stragu]

@1ec5 do you want to amend your table in #8760 (comment) ? It's a great summary to point to in other reports :)

[1ec5]

I noticed that your third screenshot uses the car profile instead of the pedestrian profile.

I reran the test and corrected the table above. But now I’m confused, because OsmAnd is definitely routing over public_transport=platform (Meadowview) but not public_transport=platform railway=platform (San Antonio 2).

routable on ways with both public_transport=platform and railway=platform (test with Corinda station)

This way is part of a railway=platform foot=yes multipolygon, which is weird. I’m not sure it necessarily disproves the results I got with the platform at San Antonio above.

However, I found a way with only public_transport=platform in my area and could confirm that OsmAnd does not route over it. For example: Normanby platform

Your destination got snapped to a footway. Here’s OsmAnd routing over the platform:

Contrast this with the San Antonio platform, where moving the waypoints closer together allows the origin to snap to the platform but still doesn’t convince the router to traverse the platform:

Anyways, my point stands that public_transport=platform isn’t reliably routable yet, which is the point of the validator warning, even if it’s worded in absolute terms. Even if OsmAnd were to achieve consistency across all these cases, the validator rule isn’t intended to cater to OsmAnd over all the other routers.

[peternewman]

Somewhat linked to this, GraphHopper seems to still be the only one of the routers on the OSM website to route over a platform when I've just tested, however it does raise an alternative issue, they seem to ignore the ticket gates (at least one tagged as barrier=turnstile). For some stations there are footbridges or underpasses you can access from either end, but you need a validated ticket (e.g. tap in on a contactless card) to be on the station, yet GraphHopper will happily route me across this without so much as a warning.

[1ec5]

How was the platform tagged? So far I’ve only found it to route over railway=platform when walking: #8760 (comment).

[jidanni]

All I know is currently a path connecting Railway Platform A to Railway Platform B creates a warning.
All I know is a railway platform is like a big block of butter.
I shouldn't need to create arbitrary paths across it to silence the errors.

[1ec5]

It’s just a warning, not an error. If you don’t have adequate local knowledge, imagery, or traces to resolve the warning, leave it to someone else to resolve the warning.

[jidanni]

All I am saying is I know every inch of that Railroad platform, and it's just a solid platform that you can walk in any direction across. Any path that I would make going across it would be just as valid as any other path in any other random direction going across it.

It's just like if I put an ant in the middle of a dish and then made a path on the map whatever way the ant walked: it's just as valid and, just as invalid as any other path across a random blank area.

It's just like the electrons are passing along a wide copper strip.
Saying that there is an additional wire laid on top of that is simply
not the Ground Truth.

[jidanni]

I just did a test: would a one dimensional (line (unclosed way)) platform also get the error? Yes.

Well, how could that be? Why is a one dimensional platform different than a one dimensional footpath? Both should be routable.

[1ec5]

That would be a question for the routing engines listed above – potentially a good bug report to their developers.

[Dimitar5555]

@jidanni There is a reason for routers to try to avoid platforms. In some countries platforms are part of the paid zone (i.e. you have to validate your ticket/card/travel pass at a machine to enter). You can fix the routing problem by adding highway=footway to the platform. See https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=42.69467%2C23.31501%3B42.69226%2C23.31046#map=17/42.69382/23.31350 for such example.

[jidanni]

Well a footway could also pass through a fare gate or a custom gate. So the router should be sensitive to gates. And the mapper should remember to put the gates on the map.

I mean we're supposed to map the things that are on the ground. And there's no path going across a big piece of pavement that's all the same.

No matter if it's people, or electrons, they all can figure out ways of going across a plane.

But okay, I guess I should start thinking of this in terms of suggested routes.

If I suggest a person take these routes across these items, then I guess I'll start feeling better about it and get used to it. Thanks