realtime elevator status in GTFS?

[Holger Dieterich]

(this is my first post here, since a search in this group has no results.)

Hi,

I try to understand if GTFS-realtime supports realtime information about the status of elevators in subway stations. On https://developers.google.com/transit/gtfs-realtime/ I found disruptions and "Trip updates", "Service alerts" and "Vehicle positions", neither of those seem to fit.

For accessible journey planning it would be great to have elevator status as well. Maybe elevators could be seen as transportation routes and vehicles?

Thanks,

Holger

PS: Some context why I'm interested: I'm the co-founder of http://wheelmap.org and we did a project in Germany around elevator data in public transportation. 

Website (German):

https://projekt-elevate.de/

Some technical considerations for MTAs (English):

https://paper.dropbox.com/doc/Barrier-free-access-to-public-transportation-with-Project-Elevate-Requirements-for-escalator-and-elevator-APIs-2vR8jtiYF0u7hMHNk222p

[Stefan de Konink]

Hi Holger,

On donderdag 5 juli 2018 10:21:09 CEST, Holger Dieterich wrote:
> I try to understand if GTFS-realtime supports realtime
> information about the status of elevators in subway stations. On
> https://developers.google.com/transit/gtfs-realtime/ I found
> disruptions and "Trip updates", "Service alerts" and "Vehicle
> positions", neither of those seem to fit.
>
> For accessible journey planning it would be great to have
> elevator status as well. Maybe elevators could be seen as
> transportation routes and vehicles?

This information is currently not exchanged in GTFS-RT and the current 3
flavors it might not be really the place for it, if you want to be able to
route on elevator or escalator. GTFS (schedules) additionally do not
specify any connections or walking paths or potential time constraints on
entrances.

If I look at the more feature rich standard like NeTEx, also the realtime
update mechanism (in this case SIRI) also do not include the means to
update this information in realtime. And I am personally leaning more
forward to road standards such as Datex II to facilitate the routing
facilities.

If you only want to alert a user, it may be possible to use a GTFS-RT
Service Alert coupled to a specific stop_id, but this is human readible not
an system update that changes the wheelchair accessibility status.

--
Stefan

[Tony Laidig]

Getting a little off topic here, but I believe it is possible to pass along Elevator Status info in SIRI. 

You can create a SituationExchange message with Consequences that make a StopPoint not accessible for those with Reduced Mobility.

As for whether anyone has implemented this, or if a consumer supports it is another question ;)

https://github.com/laidig/siri-20-java/blob/master/src/net/transitdata/siri/ElevatorStatusExample.java

[Stefan de Konink]

On donderdag 5 juli 2018 19:52:52 CEST, Tony Laidig wrote:
> Getting a little off topic here, but I believe it is possible
> to pass along Elevator Status info in SIRI.
>
> You can create a SituationExchange message with Consequences
> that make a StopPoint not accessible for those with Reduced
> Mobility.

Mmm... I didn't know about that one. But this is updating MobilityNeed of
the stop but not linking the elevator id itself. So something has
precomputed that the elevator was the only way to get there being in a
wheelchair and concluded that it had impact.

I read the question as: can I communicate that the elevator itself is
broken as input for the system that has to no conclude something.

So analogue example:


where is the vehicle | trip updates
---------------------+---------------------
elevator broken | mobility need impact

> As for whether anyone has implemented this, or if a consumer
> supports it is another question ;)
>
> https://github.com/laidig/siri-20-java/blob/master/src/net/transitdata/siri/ElevatorStatusExample.java

Still a very good example.

--
Stefan

[Holger Dieterich]

thank you. NeTEx and Siri look very complicated, though.

Is it planned to extend GTFS-RT into that direction? What is the governance structure of this standard? I would like to advocate for adding realtime elevator status.

Thanks,

Holger

[Stefan de Konink]

On dinsdag 10 juli 2018 15:27:38 CEST, Holger Dieterich wrote:
> thank you. NeTEx and Siri look very complicated, though.

Very domain specific, and very well documented.

> Is it planned to extend GTFS-RT into that direction? What is
> the governance structure of this standard? I would like to
> advocate for adding realtime elevator status.

So what would you be willing to standardise?

- where are elevators?
- what is the status of an elevator?
- stop accessibility changes?

--
Stefan

[Ritesh Warade]

Hi Holger,

We (IBI) have developed a system to enter and manage service alerts. As part of that elevator status alerts can be created either manually by users through an UI, or automatically based on information received via a feed. The elevator status info can then be output in a few different ways:

1)      Include it in an OTHER_EFFECT effect alert at the stop level in the gtfs-realtime service alerts feed. Google maps and other apps will show that as an ‘Information’ alert. See example below:

 

 

2)      Include it in an extended gtfs-realtime service alerts feed with reference to a facility id. (we do that via a json version of the gtfs realtime feed). See example below:

 

 

Happy to discuss further

 

Ritesh

 

---

Ritesh Warade

--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/d390fa12-574f-463e-881e-484aa3233701%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan de Konink]

On dinsdag 10 juli 2018 15:45:44 CEST, Ritesh Warade wrote:
> We (IBI) have developed a system to enter and manage service
> alerts. As part of that elevator status alerts can be created
> either manually by users through an UI, or automatically based
> on information received via a feed. The elevator status info can
> then be output in a few different ways:
>

> Happy to discuss further

Both do not affect pedestrian routing.

--
Stefan

[Tony Laidig]

Our earlier emails may have relied on too much in-knowledge. 

What I believe Stefan was pointing out was that the model for GTFS(rt) does not make it clear how elevator status information should be conveyed in a method that can be understood programmatically (e.g. by a trip planner). 

Another way of putting this is how a change in accessibility to a platform/station/stop would impact the trip for the passenger-- without the concept of geographic pathways that denote accessibility status themselves (i.e. barrier/step-free paths through a station versus staircases), it is difficult to interpret this as a standard that can be applied without much handholding. 

[Holger Dieterich]

Yes, thank you and the others in this thread. this is helpful!

I would like to learn of any examples who include elevators in route planning. 

Example: 

• take train 6 and exit at station "foo"
  
• take elevator at the north-east exit to the mezzanine
• take elevator from mezzanine to platform B
• take train 1 and exit at "bar"
• // If an elevator is out of service, re-route the passenger.

Regarding "simple" status info of elevators, we have made a suggestion for transportation organisations. Feedback is appreciated:
https://paper.dropbox.com/doc/Barrier-free-access-to-public-transportation-with-Project-Elevate-Requirements-for-escalator-and-elevator-APIs-2vR8jtiYF0u7hMHNk222p

Eager to learn more,

Holger

[Stefan de Konink]

All your current examples including the word elevator are fully out of
scope of GTFS as whole. Any pedestrian planning is done by other (internal)
sources, such as Google Maps, Bing Maps, OpenStreetMap and others.

There is currently in GTFS no way to exchange the topology of a station, to
facilitate indoor routing. The only thing GTFS is able to say: you can't
use a trip because of its (wheelchair) accessbility status or a stop
doesn't have (wheelchair) accessibility.

In order to make a fully accessibily planner - including realtime
information - there should be a relationship between either the physical
thing that provides the accessibility or the logical element the
accessibility status itself.

From GTFS-RT perspective, it would be very nice to be able to update the
logical element.

Stefan

> 2) Include it in an extended gtfs-realtime service alerts
> feed with reference to a facility id. (we do that via a json
> version of the gtfs realtime feed). See example below:
>
>
>
>
>
>
>

[Andrew Byrd]

On 10 Jul 2018, at 22:19, Stefan de Konink <ste...@konink.de> wrote:

All your current examples including the word elevator are fully out of scope of GTFS as whole. Any pedestrian planning is done by other (internal) sources, such as Google Maps, Bing Maps, OpenStreetMap and others.

There does appear to be a revival of the long-standing pathways.txt proposal though:

https://github.com/google/transit/pull/86

https://www.mbta.com/developers/gtfs/p#pathways

This is not finalized but clearly being developed by several GTFS users/producers. The normal GTFS extension process will need to be completed and I think there are open questions about technical details, such as whether elevators are nodes or edges.

-Andrew

[Sean Barbeau]

Is it planned to extend GTFS-RT into that direction? What is the governance structure of this standard? I would like to advocate for adding realtime elevator status.

Change process for GTFS-realtime is at:

https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md

You can also extend it via extensions if you're doing something very specific to your deployment that wouldn't be useful to the larger community:

https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md#extensions

Sean

[l...@frachet.ca]

Hi Holger,

We are working on extending the GTFS specification toward adding real-time elevator status and in-station routing. The current proposal is at https://github.com/google/transit/pull/86. The static data part of the proposal is done (aka the tables and fields which will be added to the GTFS file) but the GTFS-rt part isn't yet.

To have new feature adopted in the specification we need a data producer and a data consumer, and the proposal was currently lacking a consumer... and here you are!

I'm gonna contact you directly on LinkedIn, and maybe we could make a first draft together of the GTFS-rt part of the proposal, and then post it on the GitHub to have the community discussing it?