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.

[2martens]

We are currently evaluating OTP and the question of elevator realtime information is interesting to us. As far as I know, OTP uses OSM data to handle indoor routing, including elevators. We would need a way to provide a realtime update for the elevator status so an accessible route does not go via an elevator that is out of use.

GTFS-RT seems like the place to go as a fourth type of realtime information.

[ckraatz]

SimplifyTransit is helping agencies create real-time alerts about elevator outages specifically. My rationale:

1. Elevators, in particular, are essential to the navigation of transit systems by people with disabilities as well as those with strollers, luggage and bicycles. Escalators aren't as helpful to these riders, so I treat those separately.
2. Elevators are frequently out of service and most agencies aren't doing enough to tell riders.
3. The Pathways.txt and levels.txt files are so complex that large and mid-size agencies don't have the resources, knowledge or capacity to create this data accurately and "exhaustively" (the requirement, and an apt word choice!).
4. GTFS-realtime Service Alerts is clearly ready to expand to additional entity selectors, whether they're in stops.txt, pathways.txt, or facilities.txt. No need for a new real-time feed in my opinion.

Some ideas and questions:

1. Could we give agencies an easier way to model their elevators if they don't have the capacity to build a full pathways.txt and levels.txt? I think that would deliver more than 80% of the value with less than 20% of the data.
2. If an elevator is a station entrance (entry point from the street), could we define it in stops.txt? And maybe add a new location_type like "elevator" for greater clarity? (this is what I did when I was at VTA, before pathways.txt, and what we're doing for Caltrain)
3. Could we just model all elevators as "nodes" in stops.txt rather than in pathways.txt, and expand the location_type list to include elevators? Pathways.txt could then just model "edge-type pathways" that have a lateral dimension like corridors, stairs or bridges and agencies could model all their elevators (the only pathway_mode that seems to be entirely vertical) much more easily. Additionally, GTFS-rt Service Alerts already accepts stops as informed_entities.

Sorry if I'm missing a lot of the prior discussion on this, and thanks for any feedback!

[leonardehrenfried]

If you want something simple, couldn't you make the stop (platform) the informed_entity so that broken elevation shows up as a text message when using the stop?

[ckraatz]

If you want something simple, couldn't you make the stop (platform) the informed_entity so that broken elevation shows up as a text message when using the stop?

My understanding is that the informed_entity should be the entity that’s directly affected, which would be the elevator. For example, if a bus stop is out of service, the stop is the informed_entity, not the route(s) it provides access to.

• The platform isn’t affected for those who wouldn’t use the elevator anyway.
• What if there are two elevators and only one is out of service? The platform is still accessible.
• What if there are multiple platforms or an entire station the elevator provides access to? Does the alert publisher have to think through all of that?

I’m also trying to make this easier for the dispatchers or other very busy staff who create these. If it’s too hard for producers, they won’t do it. That's the current state of affairs, for multiple reasons including lacking simple publishing tools and the tremendous complexity of pathways.txt. I've found the simplest way to train front-line staff is to tell them to apply the alert to the smallest unit of affected service possible (the affected elevator itself).

The philosophy behind GTFS(rt) seems to be that data consumers take care of the rest programatically.

[ckraatz]

I'm curious if there's a need to expand or alter the scope of stops.txt to include not only stops, stations, entrances and platforms but all entities in a transit service that can be represented by a single lat/long.

Could the experimental facilities.txt (where some agencies like MBTA and Sound Transit model elevators that exist outside stations, in parking structures for example) be an indication that the existing "stops" schema needs to evolve, rather than creating additional new files that add complexity?

What if stops.txt (with the same name, or with a new name like facilities.txt or locations.txt to reflect its evolution) were expanded to contain all the location_types it currently has, plus all the facility_types in facilities.txt, plus any pathway_types that can be modeled with a single lat/long (just elevators)?

What if pathways.txt and levels.txt modeled the linkages between points that resided in stops.txt or its successor?

I appreciate feedback on these questions and ideas, and I'm also curious if we could work through the flaws in this thinking in a way that simplifies getting real-time elevator information to the riders that need it.

[leonardehrenfried]

Could you point out which parts of pathways you find complex compared to what you're suggesting? Are you proposing to add elevators that contain no routable information like "connects node A on level 0 to node B on level -1"?

[ckraatz]

Could you point out which parts of pathways you find complex compared to what you're suggesting? Are you proposing to add elevators that contain no routable information like "connects node A on level 0 to node B on level -1"?

The part of pathways that seems complex, given how even large agencies have struggled to create it, is describing how the dots connect and the requirement that it be exhaustive.

The routable information (the lines) for elevators makes sense to be in pathways.txt. My interest is in having all the dots (elevator entrances and doors) being modeled in stops.txt, but with more specific location_types rather than being generic nodes.

And maybe elevators need to be modeled with a more obvious parent/child type of relationship. What if there were a parent elevator with child elevator_doors at each level? Then a producer could select the "parent elevator" as the informed_entity and that GTFS-rt Service Alert would apply to all its doors programmatically.

An elevator fully modeled in stops.txt (or an expanded successor) can still have a stop_description that specifies what it does and what levels it serves.

[leonardehrenfried]

If there is no "connection" between elevators and stops, how would a routing engine figure out what the correct elevator is to reach the stop?

[ckraatz]

If there is no "connection" between elevators and stops, how would a routing engine figure out what the correct elevator is to reach the stop?

I​t makes sense to me that the connections between elevator doors and stops/platforms​ would still come from pathways.txt. I understand Pathways ​to be the lines that connect the dots. The dots seem more like stops/locations/facilities​ with a single lat/long. I’m not proposing a change to the lines, only the dots.

If pathways.txt is onerous for most agencies, which seems to be the case even for large agencies, then riders will continue to have neither real-time info about elevator outages nor pathways for routing engines.

I'm hoping there could be a pragmatic solution that would start by modeling elevators quickly and easily as "dots" in stops.txt, and then an iterative, progressive enhancement approach to connect all the dots with pathways.txt.

• ​Could ​all the dots of an elevator be modeled ​w​ith a new architecture in stops.txt in which a new location_type like elevator_door is subordinate to its elevator, ​and has a description of its level and location? Then pathways.txt, once available, could connect those elevator_doors?
• You’re correct that stops.txt can't currently associate an elevator with specific platforms​ (Transit pointed this out to me as well). ​Could we add that explicitly to elevator_doors in stops.txt? Maybe an access_to field that could list multiple stop_ids (ie platforms) related to each elevator_door?​
• Pragmatically, I see little harm in a GTFS-realtime Service Alert that tells all accessibility-interested riders about an elevator outage at the station they're using. The alternative is the status quo: no alerts at all, or even less targeted alerts.

[leonardehrenfried]

You can probably guess from my line of questioning that I'm not a fan of having a parallel track for defining elevators. If you have to provide an access_to field, then you might as well just use pathways.
We have one way (pathways) and I'm not in favour of creating another one. The complexity of pathways is just reflecting the fact that providing in-station navigation needs a lot of attention to details. Presumably your agency doesn't have access to a high quality visual editor for defining the pathways.

However, I do have a suggestion for you. There is a high quality visual editor for maintaining detailed geographic information: OpenStreetMap.

It's likely that the stations and elevators in question are already mapped in OSM. OSM's editing tools are far superior to anything I have seen from commercial vendors so I would just treat it as the source of truth and update it as needed. If your elevators have some form of assigned IDs then you can tag them in OSM.

For getting that information into your routing engine you have two choices:

1. You can write a program to convert the OSM information into pathways.
2. Most routing engines (other than Google) use OSM anyway so they will make use of your updates without having to do anything. Then however, you have to teach the routing engine to associate the OSM-supplied with the realtime elevator status from your GTFS-RT feed.

Now your agency might say "Anybody can edit OSM, I can't trust it. We need official data!". To this line I would respond that I don't know of a single agency in the world that can produce "official data" that is of higher quality than OSM. On top of it, correcting one of the many mistakes in the "official data" is an exercise in frustration as the process is often very painful. OSM will result in a much more dynamic workflow, believe me.

[ckraatz]

@leonardehrenfried I understand where you're coming from, and agree with the principle of using or iterating on the data/tools available rather than reinventing the wheel.

I fully support your proposal to extend the GTFS-realtime Service Alerts EntitySelector to allow pathway_ids, not just elevators and escalators but any pathway_id. How do we move that forward?

SimplifyTransit supports modeling elevators in any adopted GTFS data entity that can be an informed_entity in GTFS-realtime Service Alerts.

Pragmatically, I see the expectation to model elevators in pathways.txt, which agencies seem to find onerous, as a constraint that ultimately hurts riders. I’m open to simple, realistic, fast and potentially iterative ways to get elevators into GTFS.

My product, SimplifyTransit Alerts, will publish GTFS-rt Alerts about elevators modeled according to any adopted or even experimental GTFS standard (station entrance stop_ids, pathway_ids, facility_ids).

SimplifyTransit Subscriptions allows riders to subscribe to SMS/email elevator alerts personalized to the stations they use, automated based on a GTFS-rt Service Alerts and GTFS feed (we'll configure the import to whichever way elevators are modeled in GTFS).

This discussion is so far very centered on routing engines and specifically OTP. That is not the only, or even most important, channel for GTFS-rt elevator alerts:

• There are multiple common routing engines in transit (Google Maps and Transit being the most widely used, OTP, Apple Maps and Moovit being less widely used).
• If riders only get alerts when they’re planning a trip, they’ll miss important information or it’ll be too late. Push channels like SMS/email (ie SimplifyTransit Subscriptions) help them plan ahead.
• Digital signage, station audio announcements, and agency websites all need these alerts too.
• An IVR system should be able to access GTFS-realtime Service Alerts about elevators.

How would an elevator in a parking structure outside a station be modeled in GTFS-pathways? Or would it? MBTA and Sound Transit have modeled those in facilities.txt.

[jfabi]

I can speak a little to the @mbta experience with elevator outages in case it offers some inspiration.

Our personnel can utilize our solution for alerts and select a specific elevator or escalator to close. The Alerts protobuf that is published includes these alerts with the effect ACCESSIBILITY_ISSUE and the informed entitites being the various route-stop combinations in the station. The translation from elevator/escalator to valid route-stops is handled entirely through facilities.txt, with facilities_properties.txt providing route-stop exceptions and guidance templates for populating alerts. We have a separate, "enhanced"/non-standard feed that adds the facility_id as an additional selector to route_id and stop_id. @sam-hickey-ibigroup

This meets most of @ckraatz's use cases except for trip routing: Digital signage is tied to station/stop IDs, as is our email/SMS subscription service (subscribers select the stations they wish to receive elevator and/or escalator alerts for).

Digital screen found at certain rail stations.

Subscription page for elevator and escalator-related outage email and SMS alerts.

In the absence of pathways or an extension like facilities.txt, one could today include a generic node stop_id as an informed entity in an alert, which can then be related back to a parent station for various applications. Perhaps there could be an added field to stops.txt enumerating a subtype of generic node (eg, whole or end of an elevator, staircase, etc) to assist with alert creation.

[jfabi]

Aside: One of the main blockers I'm reading in this thread is around the resources needed for agencies to produce complete pathways for stations.

Are there any resources that we, as a community, can offer to parties in terms of guides and even tools to ease the burden? For example, it could include expanding the existing guide to clearly indicate the minimum-required elements in pathways.txt (for instance, simplifying walkways, omitting length and traversal_time). This resources page includes a couple of items related to pathways, but I think there are at least one or two other (commercial) solutions out there.

[leonardehrenfried]

@jfabi I'm repeating myself here but many stations are already mapped very precisely in OSM and I believe the best would be to make use of it and write an open source converter from that to pathways.

It has the advantage of not needing a new interface for inputting the data.

[ckraatz]

@jfabi I'm repeating myself here but many stations are already mapped very precisely in OSM and I believe the best would be to make use of it and write an open source converter from that to pathways.

It has the advantage of not needing a new interface for inputting the data.

@leonardehrenfried that does sound promising. Is an open-source OSM>pathways converter something you’d be open to working on?

@jfabi thank you for sharing MBTA’s approach.

The level of experimental and custom work you’re describing, much of it in IBI’s software and entirely outside GTFS, is to me a symptom of limitations in how GTFS approaches “points” in the graph. Do you think your “facilities ecosystem” could be leveraged to expand the scope and power of what we currently call stops.txt? It already contains much more than just “stops”: generic_node, station_entrance, parent_station are all clues to me that it’s a file that wants to grow into something more, if you’ll pardon the personification. 😁

You’re correct that the creation of pathways data is a blocker for many agencies. I’m also curious if there’s a way to produce a “minimum compliant” pathways file, even as an agency’s starting point to be iterated on, that would serve the needs of routing engines too.

[leonardehrenfried]

@leonardehrenfried that does sound promising. Is an open-source OSM>pathways converter something you’d be open to working on?

Yes, but I just remembered that using OSM data will place attribution obligations on consuming apps. Maybe even more but I'm currently researching that.

[bdferris-v2]

I'm late to the discussion, but a couple points:

1. I'm generally not opposed to expanding EntitySelector to support path_id, though I acknowledge that there will likely be fewer data providers who can leverage it in practice.
2. I know there is a philosophical question about whether alerts should actually be able to affect routing. In practice, they already do for many consuming applications (including Google) and while I think there is room for better documentation of best practices in that regard, I don't propose to change that. Thus, I'd be ok with consuming applications using a path-specific elevator alert to modify routing.
3. It was noted that OSM could be an option for helping agencies better model station walking networks. There are actually plenty of things that OSM could theoretically be helpful with, but the OSM data license continues to be the main blocker on our end. I wish it was otherwise, but we'll likely continue to push back on direct usage of OSM for this reason.

[SteveGladstone]

Jumping in because we here at the Maryland Transit Administration are set to roll out our complete Pathways architecture for our subway system any day now. We're also able to pull in operational status via the PLCs on the elevators and escalators at each station. Given how old our stations are, things may go up or down on a daily basis and it would be great to manage that in realtime for our customers.

(replacement of all that aging equipment is TBD)

From an implementation perspective, our thought was to keep it simple an apply the same rules for transit service to the pathways nodes. Stop closures via Service Alerts utilize NO_SERVICE and since all the pathway nodes at included in stops.txt, the same setup makes sense to us. When the PLC reports a non-operational status, we'd generate a Service Alert with that stop_id as the FeedEntity and set the Effect to be NO_SERVICE. Then similar to stop closures, any trip planning involving that node gets removed from consideration due to the effect.

Doing it that way isn't the most intuitive because of the words used (NO_SERVICE vs the GTFS-PathwayUpdates various PathwayStatus values), but conceptually is the same and reduces the implementation burden for 3rd parties. In theory they already re-route users when there are stop or route disruptions; this would do the same thing.

Now there is the issue of making sure the agency's Pathways setup is fully fleshed out with all the possible combinations so alternative routing is feasible (assuming such exist). That shouldn't hold back this process though.

Does that make sense? Is there any real downside to doing it this way other than the language abstraction and expanding how NO_SERVICE gets used (sorta)?

[kylerchin]

+1 for Catenary , I would really like this in.