Proposal: Add elevator/escalator real-time status - extend `EntitySelector` to select pathways instead of only nodes

[opyh]

Hey! 👋

Are there any plans, documents, or issues to extend GTFS RT with elevator/escalator service disruptions already? Sozialhelden e.V., an NGO from Berlin, Germany, have covered a lot of German elevator status information in APIs but it would be much better if you could mark an elevator as broken via GTFS pathways.txt and a GTFS RT EntitySelector. This would allow providers to mark a pathway, instead of just stops, as unusable.

Here are some UX mockups how this could look to an end user:

To me it seems almost all infrastructure is ready for this.

I could try to provide a feed for the Verkehrsverbund Berlin Brandenburg (VBB) beta pathways.txt data set – there is real-time info for around 600 facilities. Any objections, feedback, or ideas? :)

[gcamp]

Gets a 👍 for me. As far as I know, the pathways spec was specifically designed with that future feature in mind.

[opyh]

Just to clarify: the idea of this proposal is different from GTFS-PathwayUpdates. Isn't it easier to re-use GTFS RT instead of having an additional .txt files, as it already provides an infrastructure to attach service disruptions to any entity?

[skinkie]

I would certainly support the concept but I think handling this as 'alerts' becomes something a lot of debate will start about. Hence I think there must be a distinction made between a message for an escalator such as "tomorrow this escalator will be serviced" versus "this pathway is blocked / not routable".

[opyh]

@skinkie This differentiation would already be possible with GTFS RT – it would be up to app developers to decide how to integrate alerts in their UX.

Of course it doesn't make sense to send a notification for every alert, but only to people that currently need it - or want to subscribe notifications for a specific elevator they need every day, e.g. on the way to work.

We are working on exactly this as a prototype with the BVG right now, but it would make more sense to have this integrated into a global standard so everybody can build apps that allow this.

[e-lo]

I would suggest a change/addition in the GTFS-PathwaysUpdates document to discuss there about how it would be an option for how to implement similar functionality.

A PR exists in the MobilityData/transit repo to implement this

[opyh]

Thanks for the reference! This means we could already start with an example dataset for this. I'll have a look next week.

[skinkie]

@skinkie This differentiation would already be possible with GTFS RT – it would be up to app developers to decide how to integrate alerts in their UX.

UX =/= JourneyPlanner. I don't want to infer that a path cannot be traveled because an alert happened to be of some category.

[barbeau]

This is another example of the existing debate about whether Alerts should influence trip itinerary results when routing or just be considered human-readable info - see #246

[opyh]

@skinkie I'm curious - how you would solve the case 'my app should navigate around an elevator that is broken for 20 minutes and display a notification' instead, as an integration in the existing GTFS infrastructure?

From what I understand until here, I guess it's a good idea to produce both kinds of datasets (static/RT) as a prototype?

[skinkie]

@skinkie I'm curious - how you would solve the case 'my app should navigate around an elevator that is broken for 20 minutes and display a notification' instead, as an integration in the existing GTFS infrastructure?

Have an interface defining the pathways in the network, and their unavailability. If I take the car network as example, I have driving times for each section. It would be lovely to have a similar system for pathways as well.

From what I understand until here, I guess it's a good idea to produce both kinds of datasets (static/RT) as a prototype?

Exactly. @barbeau already pointed out where we discussed that. Several people make statements there I fully agree on.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derhuerst]

Still relevant.