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.

Sign up for GitHub

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

Jump to bottom

Add repeated CarriageDescriptor to VehicleDescriptor to encapsulate carriage specific information #66

Closed
wants to merge 11 commits into from
Closed

Add repeated CarriageDescriptor to VehicleDescriptor to encapsulate carriage specific information #66

Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
b7bb2f6
whatevs
Jul 11, 2017
59f7c4c
Add CarriageDescriptor.
Jul 11, 2017
141479a
Fix up TOC and formatting.
Jul 11, 2017
b228b28
Add extensions and fix documentation for CarriageDescriptor.
Jul 11, 2017
37e1f68
Added CarriageDescriptor to Spanish reference.
Jul 11, 2017
daa7b3c
Fixed anchors in spanish reference.
Jul 11, 2017
c840c75
cleanup.
Jul 11, 2017
75829dd
Revert Spanish anchor fixes. This is in PR #67.
Jul 13, 2017
e811fd4
Merge branch 'master' into gtfs_rt_carriage_info
RachM Jul 14, 2017
9acd8bc
Add carriage_sequence to explicitly define the carriage ordering.
Jul 17, 2017
314773c
Clarify that single-carriage vehicles (e.g. a standard bus) should ha…
Jul 17, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
111 changes: 110 additions & 1 deletion gtfs-realtime/proto/gtfs-realtime.proto
View file
Open in desktop
Expand Up @@ -215,7 +215,7 @@ message TripUpdate {
NO_DATA = 2;
}
optional ScheduleRelationship schedule_relationship = 5
[default = SCHEDULED];
[default = SCHEDULED];

// The extensions namespace allows 3rd-party developers to extend the
// GTFS Realtime Specification in order to add and evaluate new features
Expand Down Expand Up @@ -574,6 +574,115 @@ message VehicleDescriptor {
// The license plate of the vehicle.
optional string license_plate = 3;

// Contains amenities and other information about an individual carriage that
// is part of a vehicle.
message CarriageDescriptor {
// Internal system identification of the carriage. Should be unique per
// vehicle, and can be used for tracking the carriage as it proceeds through
// the system.
optional string id = 1;

// User visible label that may be shown to the passenger to help identify
// the carriage.
optional string label = 2;

// The degree of passenger occupancy of the carriage.
optional VehiclePosition.OccupancyStatus occupancy_status = 3;

// Whether the carriage is wheelchair accessible.
enum WheelchairAccessible {
// It is unknown if the carriage is wheelchair accessible. This is the
// default case.
UNKNOWN = 0;

// The carriage is wheelchair accessible.
WHEELCHAIR_ACCESSIBLE = 1;

// The carriage is not wheelchair accessible.
NOT_WHEELCHAIR_ACCESSIBLE = 2;
}

optional WheelchairAccessible wheelchair_accessible = 4 [default = UNKNOWN];

// Whether the carriage has toilet facilities onboard.
enum ToiletFacilities {
// It is unknown if the carriage has toilet facilities. This is the
// default case.
UNKNOWN = 0;

// The carriage has toilet facilities onboard.
TOILET_ONBOARD = 1;

// The carriage does not have toilet facilities onboard.
NO_TOILET_ONBOARD = 2;
}

optional ToiletFacilities toilet_facilities = 5 [default = UNKNOWN];

// Whether the carriage has WiFi onboard.
enum WifiAvailability {
// It is unknown if the carriage has WiFi. This is the default case.
UNKNOWN = 0;

// The carriage has free WiFi available for passengers to use.
FREE_WIFI = 1;

// The carriage has WiFi available for passengers to purchase.
PAID_WIFI = 2;

// The carriage has no WiFi available for passengers to use.
NO_WIFI = 3;
}

optional WifiAvailability wifi_availability = 6 [default = UNKNOWN];

// Whether the carriage is air conditioned.
enum AirConditioning {
// It is unknown if the carriage is air conditioned. This is the default
// case.
UNKNOWN = 0;

// The carriage has air conditioning.
AIR_CONDITIONED = 1;

// The carriage does not have air conditioning.
NOT_AIR_CONDITIONED = 2;
}

optional AirConditioning air_conditioning = 7 [default = UNKNOWN];

// Whether bicycles are allowed in the carriage.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think BicyclesAllowed would be useful outside of just the carriage use case - agencies have told me they'd like to see this for buses, including real-time capacity of racks, although I'm not aware of any real-time system that currently exposes this via an API.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that a bus amenities/info can be modelled by having a single CarriageDescriptor. Hence this works for buses.

Capacity for the rack is interesting; it could certainly be added at a later stage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, maybe 'Carriage' is the wrong word to use? I want it to be used for all vehicle types, and if that's not clear, we should change the name.

Let me know if you have other name suggestions. Car? Compartment? Section?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if you have other name suggestions. Car? Compartment? Section?

I couldn't come up with anything better and more general than Carriage. I think as long as we make it clear in the spec that this can apply to any transit vehicle this would work for buses too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool - I've clarified the single-vehicle case in the reference as well as the proto.

enum BicyclesAllowed {
// It is unknown if the carriage allows bicycles. This is the default
// case.
UNKNOWN = 0;

// Bicycles are allowed to be transported, but must be stored outside of
// the carriage.
ALLOWED_OUTSIDE_CARRIAGE = 1;

// Bicycles are allowed to be transported, and can be stored inside the
// carriage.
ALLOWED_INSIDE_CARRIAGE = 2;

// Bicycles are not allowed to be transported in this carriage.
NOT_ALLOWED = 3;
}

optional BicyclesAllowed bicycles_allowed = 8 [default = UNKNOWN];

// The extensions namespace allows 3rd-party developers to extend the
// GTFS Realtime Specification in order to add and evaluate new features and
// modifications to the spec.
extensions 1000 to 1999;
}

// An ordered set of CarriageDescriptor. The first element maps to the first
// carriage a user will encounter if the vehicle is travelling in the
// direction of travel. Vehicles with only one compartment/carriage
// (e.g. a bus) will only have one CarriageDescriptor.
repeated CarriageDescriptor carriage_descriptor = 4;

// The extensions namespace allows 3rd-party developers to extend the
// GTFS Realtime Specification in order to add and evaluate new features and
// modifications to the spec.
Expand Down
112 changes: 103 additions & 9 deletions gtfs-realtime/spec/en/reference.md
View file
Open in desktop
Expand Up @@ -20,13 +20,27 @@ Version 1.0 of the feed specification is discussed and documented on this site.
* [TripDescriptor](#message-tripdescriptor)
* [ScheduleRelationship](#enum-schedulerelationship-1)
* [VehicleDescriptor](#message-vehicledescriptor)
* [CarriageDescriptor](#message-carriagedescriptor)
* [OccupancyStatus](#enum-occupancystatus)
* [WheelchairAccessible](#enum-wheelchairaccessible)
* [ToiletFacilities](#enum-toiletfacilities)
* [WifiAvailability](#enum-wifiavailability)
* [AirConditioning](#enum-airconditioning)
* [BicyclesAllowed](#enum-bicyclesallowed)
* [StopTimeUpdate](#message-stoptimeupdate)
* [StopTimeEvent](#message-stoptimeevent)
* [ScheduleRelationship](#enum-schedulerelationship)
* [VehiclePosition](#message-vehicleposition)
* [TripDescriptor](#message-tripdescriptor)
* [ScheduleRelationship](#enum-schedulerelationship-1)
* [VehicleDescriptor](#message-vehicledescriptor)
* [CarriageDescriptor](#message-carriagedescriptor)
* [OccupancyStatus](#enum-occupancystatus)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a design decision made when originally adding OccupancyStatus that VehicleDescriptor should only contain immutable information, while VehiclePosition should contain mutable statuses (discussion starting at https://groups.google.com/d/msg/gtfs-realtime/_HtNTGp5LxM/86U3GGxDbngJ).

This proposal breaks from that design decision by putting OccupancyStatus as a child element of VehicleDescriptor->CarriageDescriptor. You could also argue that some of the other elements are mutable as well (e.g., bathroom closed for cleaning/maintenance, bikes allowed only at certain times of the day).

At the time of the OccupancyStatus proposal, I actually argued for including OccupancyStatus in VehicleDescriptor instead of VehiclePosition, but was overruled :). I bring this up for discussion - please discuss :).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the context Sean!

My reasoning for putting it in VehicleDescriptor:

  • It seems like a property of the vehicle, and I (perhaps naively) thought VehicleDescriptor encapsulated properties of vehicles. I don't see why we should strive to maintain immutability, especially when this isn't mentioned (or enforced?) anywhere.
  • By putting it in VehicleDescriptor, it gets to be in either/both TripUpdates and VehiclePositions.

I didn't realise VehicleDescriptor was intended to be immutable. If people care deeply about maintaining this, then perhaps we should at least document this in the spec?

Keen to hear others thoughts :-)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RachM That was my exact same reasoning for originally proposing OccupancyStatus in VehicleDescriptor. So, I'm also interested to hear others thoughts :).

* [WheelchairAccessible](#enum-wheelchairaccessible)
* [ToiletFacilities](#enum-toiletfacilities)
* [WifiAvailability](#enum-wifiavailability)
* [AirConditioning](#enum-airconditioning)
* [BicyclesAllowed](#enum-bicyclesallowed)
* [Position](#message-position)
* [VehicleStopStatus](#enum-vehiclestopstatus)
* [CongestionLevel](#enum-congestionlevel)
Expand Down Expand Up @@ -208,21 +222,21 @@ Congestion level that is affecting this vehicle.

## _enum OccupancyStatus_

The degree of passenger occupancy for the vehicle.
The degree of passenger occupancy for the vehicle or carriage.

**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future.

#### _Values_

| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| _**EMPTY**_ | _The vehicle is considered empty by most measures, and has few or no passengers onboard, but is still accepting passengers._ |
| _**MANY_SEATS_AVAILABLE**_ | _The vehicle has a large percentage of seats available. What percentage of free seats out of the total seats available is to be considered large enough to fall into this category is determined at the discretion of the producer._ |
| _**FEW_SEATS_AVAILABLE**_ | _The vehicle has a small percentage of seats available. What percentage of free seats out of the total seats available is to be considered small enough to fall into this category is determined at the discretion of the producer._ |
| _**STANDING_ROOM_ONLY**_ | _The vehicle can currently accomodate only standing passengers._ |
| _**CRUSHED_STANDING_ROOM_ONLY**_ | _The vehicle can currently accomodate only standing passengers and has limited space for them._ |
| _**FULL**_ | _The vehicle is considered full by most measures, but may still be allowing passengers to board._ |
| _**NOT_ACCEPTING_PASSENGERS**_ | _The vehicle can not accept passengers._ |
| _**EMPTY**_ | _The vehicle/carriage is considered empty by most measures, and has few or no passengers onboard, but is still accepting passengers._ |
| _**MANY_SEATS_AVAILABLE**_ | _The vehicle/carriage has a large percentage of seats available. What percentage of free seats out of the total seats available is to be considered large enough to fall into this category is determined at the discretion of the producer._ |
| _**FEW_SEATS_AVAILABLE**_ | _The vehicle/carriage has a small percentage of seats available. What percentage of free seats out of the total seats available is to be considered small enough to fall into this category is determined at the discretion of the producer._ |
| _**STANDING_ROOM_ONLY**_ | _The vehicle/carriage can currently accommodate only standing passengers._ |
| _**CRUSHED_STANDING_ROOM_ONLY**_ | _The vehicle/carriage can currently accommodate only standing passengers and has limited space for them._ |
| _**FULL**_ | _The vehicle/carriage is considered full by most measures, but may still be allowing passengers to board._ |
| _**NOT_ACCEPTING_PASSENGERS**_ | _The vehicle/carriage can not accept passengers._ |

## _message_ Alert

Expand Down Expand Up @@ -340,9 +354,89 @@ Identification information for the vehicle performing the trip.

| _**Field Name**_ | _**Type**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|-------------------|-------------------|
| **id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | optional | Internal system identification of the vehicle. Should be **unique** per vehicle, and is used for tracking the vehicle as it proceeds through the system. This id should not be made visible to the end-user; for that purpose use the **label** field |
| **id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | optional | Internal system identification of the vehicle. Should be **unique** per vehicle, and is used for tracking the vehicle as it proceeds through the system. This id should not be made visible to the end-user; for that purpose use the **label** field. |
| **label** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | optional | User visible label, i.e., something that must be shown to the passenger to help identify the correct vehicle. |
| **license_plate** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | optional | The license plate of the vehicle. |
| **carriage_descriptor** | [CarriageDescriptor](#message-carriagedescriptor) | repeated | An ordered list of carriage information. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should define how the carriages should be ordered. The original proposal from NSW Trains was to use a well-defined central point. A more logical one for me is to start with the first carriage in the direction of travel and move back from there.

Copy link
Collaborator

@barbeau barbeau Jul 14, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should define how the carriages should be ordered.

That's a really good point, especially on the accessibility attributes. The whole point of providing this data would be to allow a rider in a wheelchair to position themselves in the proper place on the platform before the vehicle arrives, and if the order isn't well defined, they will end up in the wrong place.

A more logical one for me is to start with the first carriage in the direction of travel and move back from there.

This would be good. Maybe there should also be a required carriage_sequence int within CarriageDescriptor (similar to stop_sequence), that would explicitly define ordering? Otherwise it will be difficult from a consumers perspective to know if implicit ordering is correct.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added carriage_sequence to CarriageDescriptor. Can you take a quick look and see if it looks OK?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely support adding such field, but I'm a bit unsure how it would handle a situation when a train changes direction of its travel during its journey e.g. in a dead-end station.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qwasar Good point. It would be good to know how this scenario is typically modeled with trip_ids in GTFS and GTFS-realtime. If the trip_id changes, which I would imagine it would, then I would expect carriage_sequence to change with the trip_id, which should have a different direction_I'd. One option would be to make GTFS trips.txt direction_I'd conditionally required if CarriageDescriptor is provided to make the behavior and expectations clearer. Consumer could change display for outgoing trip a certain amount of time become outgoing departure.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand your idea. My objection was that it is probably not a feasible solution for cases where such train is modeled as a single trip (which can have only a single value of direction_id). It would require to slice the train journey to several trips arbitrarily just for the sake of export to GTFS. Even so, using direction_id for this purpose still feels wrong to me, as the train (even with the order of carriages reversed) still follows the same direction in the sense of trips.txt's direction_id semantics.

Take the Copenhagen-Karlskrona route as an example:
Copenhagen-Kristianstad-Karlskrona, direction_id=0
Karlskrona-Kristianstad-Copenhagen, direction_id=1
and the order of carriages has got always reversed in Kristianstad.

And if CarriageDescriptor[] would be tight to a TripDescriptor only, then while the train would be in the Copenhagen-Kristianstad section, the feed would advertise misleading order of carriages for the rest of its journey after Kristianstad. That might be quite inconvenient for passengers boarding at stations in that section and checking the status of the train in advance.

Copy link
Contributor Author

@RachM RachM Jul 26, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the example; it's a really good one! I agree my use of direction_id is not appropriate, so let's scratch that idea.

I have a new solution that I think solves our problem; have TWO fields for the sequence:

  • next_station_arrival_sequence: the order that the carriage will arrive at the next station
  • next_station_departure_sequence: the order that the carriage will depart from the next station

For non-dead end stations, next_station_arrival_sequence = next_station_departure_sequence. For dead-end stations, they will be the reverse of each other. So for my dead-end picture above:

TUs/VPs before arriving at the station:

carriage_descriptor {
  label = 'A'
  next_station_arrival_sequence: 1
  next_station_departure_sequence: 3
},
carriage_descriptor {
  label = 'B'
  next_station_arrival_sequence: 2
  next_station_departure_sequence: 2
},
carriage_descriptor {
  label = 'C'
  next_station_arrival_sequence: 3
  next_station_departure_sequence = 1
}

Consumers can know from this that it's a dead-end station, and can decide on an appropriate UI/info to show to the user.

Thoughts?

Copy link

@qwasar qwasar Aug 4, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RachM Sorry for being late with reaction, I've been off-grid.

I'm still afraid your latest proposal wouldn't allow us to handle all the cases I'd like to see addressed.

Let me expand on the example of the Copenhagen-Karlskrona train. Before boring the Citytunneln in Malmö in 2010, the Malmö Central used to be a dead-end station as well. So that train had changed its direction twice during its journey (in Malmö and Kristianstad). I can't help myself, but I think to describe such situation we really have to add CarriageDescriptor[] as an optional field to StopTimeUpdate as well. Something like this:

TripUpdate
    TripDescriptor
        CarriageDescriptor[]=[(A,B,C)+(D,E,F)] // two three-carriages units due to high demand
    StopTimeUpdate
        stop_id=Malmö, 
        CarriageDescriptor[]=[(F,E,D)+(C,B,A)] // first reversal
    StopTimeUpdate
        stop_id=Kristianstad, 
        CarriageDescriptor[]=[(A,B,C)] // second reversal, only single unit continues to Karlskrona

I found it very analogous to how Trip.trip_headsign can be overridden by StopTime.stop_headsigns in GTFS.

And on top of that it would be really great to have such info in GTFS too as it is quite common that the very same trip (train number) is served by quite different carriages on weekdays and on weekend.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More examples:
railjets at Wien-Zürich HB route changes direction twice at Buchs and Sargans stations.

LeoExpress at Košice-Prague route changes direction twice at Prešov and Přerov stations.

Copy link
Contributor Author

@RachM RachM Aug 4, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right - I was thinking mainly in terms of VehiclePositions (and hence only considered the next station). However, TripUpdates can specify many stations, so we need info about the carriage directions for each of them.

I still think it's important to know what both the arriving and departing sequence is at a particular station.

Revising:

  • CarriageDescriptor still sits in VehicleDescriptor, but only contains info about the carriage facilities (no sequencing info). Some of this could actually be moved to GTFS, in a carriages.txt file.
  • TUs: StopTimeUpdates contain the carriage sequences
  • VPs: the carriage sequence is at the top level, and is for the stop specified in stop_id

More concretely:

message VehicleDescriptor {
  ....
  repeated CarriageDescriptor carriage_descriptor;
  message CarriageDescriptor {
    optional string id = 1;
    ... wifi, occupancy, bicycles etc
  }
}

message CarriageSequence {
  optional string carriage_descriptor_id = 1;
  optional int sequence = 2;
}

message TripUpdate {
  ...
  message StopTimeUpdate {
    ...
    optional string stop_id = 4;
    ...
    repeated CarriageSequence arrival_carriage_sequence = X;
    repeated CarriageSequence departure_carriage_sequence = X+1;
  }
}

message VehiclePosition {
  ...
  optional string stop_id = 7;
  ...
  repeated CarriageSequence arrival_carriage_sequence = X;
  repeated CarriageSequence departure_carriage_sequence = X+1;
}


## _message_ CarriageDescriptor

Information for a carriage that is part of a vehicle.

#### Fields

| _**Field Name**_ | _**Type**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|-------------------|-------------------|
| **id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | optional | Internal system identification of the carriage. Should be **unique** per vehicle, and is used for tracking the carriage as it proceeds through the system. This id should not be made visible to the end-user; for that purpose use the **label** field. |
| **label** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | optional | User visible label, i.e., something that can be shown to the passenger to help identify the correct carriage. |
| _**occupancy_status**_ | _[OccupancyStatus](#enum-occupancystatus)_ | _optional_ |The degree of passenger occupancy of the carriage.<br>**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future.|
| **wheelchair_accessible** | [WheelchairAccessible](#enum-wheelchairaccessible) | optional | Whether the carriage is wheelchair accessible. |
| **toilet_facilities** | [ToiletFacilities](#enum-toiletfacilities) | optional | Whether the carriage has toilet facilities onboard. |
| **wifi_availability** | [WifiAvailability](#enum-wifiavailability) | optional | Whether the carriage has WiFi onboard. |
| **air_conditioning** | [AirConditioning](#enum-airconditioning) | optional | Whether the carriage is air conditioned. |
| **bicycles_allowed** | [BicyclesAllowed](#enum-bicyclesallowed) | optional | Whether bicycles are allowed in the carriage. |

## _enum_ WheelchairAccessible
Copy link
Collaborator

@barbeau barbeau Jul 12, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wheelchair accessibility always seems to be a tricky one to tackle. I'd love to see this included, although I'd be curious to hear from producers whether or not carriage wheelchair accessibility can be appropriately modeled as a boolean (effectively, given the below enumerations). For example, does WHEELCHAIR_ACCESSIBLE mean that a wheelchair can board the carriage (i.e., travel through the doorway)? Or does it mean that there is accessible seating/tiedowns for a wheelchair? Are toilet facilities accessible to a wheelchair? All / some / none of the above?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi everyone, Sean asked me to comment on this thread. I lead a research center on accessible transportation which includes both IT and vehicle accessibility research. Being able to specify a vehicle is wheelchair accessible is important but there are some subtle nuances you all might want to consider.

As Sean mentioned, there's a difference between accessible boarding and there being accessibility features inside the vehicle. There are also cases where the accessible boarding is only at certain stations that have the right height platforms or portable lifts. Furthermore, wheelchair access is sometimes limited to specific cars on a train. Since boarding is often tied to stations or even train platforms, you may want to split boarding out from vehicle interior. Perhaps something like AccessibleBoarding (yes, no, accessible platforms only, unknown) and WheelchairParkingArea (integer from 0). These are just brainstorms since I don't know the rest of the vehicle spec discussions.

I recommend adding something to the toilet and dining car elements (if any) to indicate whether those facilities are accessible, rather than trying to fold it into a single accessibility element.

As an aside, you may also want to think about in-vehicle announcements as an element too. Visual message signs, audio announcements, etc. Those have universal value beyond just deaf and blind riders.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for the insightful comments! It's fantastic to have an accessibility expert weigh in; I'm keen to get this right.

In regards to having the accessible boarding tied to the vehicle; I've experienced both a stop/station needing to be accessible as well as the vehicle. We already capture stop accessibility (wheelchair_boarding in stops.txt), but I thought it would be useful to capture vehicle as well (for the scenario where only some vehicles servicing the stop are wheelchair-boarding accessible). The use case I have in mind is buses in Sydney; not all are wheelchair accessible, and I think it would be great to show this information to users so they can better plan their trips.

I think it's clear that my original accessibility field is too simplistic. Maybe we need a whole message to encapsulate all of the relevant accessibility information? Maybe it doesn't all belong in a message? I'll think more about this....

Summarizing the potentially important accessibility features:

  • Accessible boarding
  • Accessible boarding instructions?
  • Wheelchair parking area
  • Accessible seating
  • Accessible toilet facilities
  • Braille signage
  • Audio announcements
  • Visual announcements

Anything else that I'm missing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially hearing "T" loop for the audio announcements as well?

A common complaint from wheelchair users is that there's no way to determine if the designated wheelchair spaces on-board are already occupied. It's one thing to have a wheelchair parking space, but they're only useful if they're available. It's a similar scenario for accessible seating.

Perhaps availability of wheelchair parking can be expressed as:

  • There is a parking space, but they are all occupied
  • There is a parking space, and there is at least one available
  • There is a parking space, and its availability is unknown (if the operator cannot determine its availability in real-time)
  • There is no parking space

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great point! One concern; are producers able to capture this type of information?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that audio announcements can vary between computer announcements and operator announcements. The latter are notoriously unintelligible in most systems since operators frequently mumble or fail to speak loudly.

We've looked at wheelchair space occupancy in our crowdsourcing transit information app (Tiramisu) and intentionally opted for overall vehicle loading instead. In most cases there is a direct relationship between loading and wheelchair space availability. Our concern about about using wheelchair space in a crowdsource system was twofold. First, most non-experts might not properly classify an opening if people without disabilities are seated in those areas. Second, we were concerned about malicious reporting that spots were full so people with wheelchairs would opt for another bus, thereby discouraging long dwell times for ingress/egress.


Whether the carriage is wheelchair accessible. The default is UNKNOWN.

#### Values

| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| **UNKNOWN** | It is unknown if the carriage is wheelchair accessible. This is the default case. |
| **WHEELCHAIR_ACCESSIBLE** | The carriage is wheelchair accessible. |
| **NOT_WHEELCHAIR_ACCESSIBLE** | The carriage is not wheelchair accessible. |

## _enum_ ToiletFacilities

Whether the carriage has toilet facilities onboard. The default is UNKNOWN.

#### Values

| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| **UNKNOWN** | It is unknown if the carriage has toilet facilities. This is the default case. |
| **TOILET_ONBOARD** | The carriage has toilet facilities onboard. |
| **NO_TOILET_ONBOARD** | The carriage does not have toilet facilities onboard. |

## _enum_ WifiAvailability

Whether the carriage has WiFi onboard. The default is UNKNOWN.

#### Values

| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| **UNKNOWN** | It is unknown if the carriage has WiFi. This is the default case. |
| **FREE_WIFI** | The carriage has free WiFi available for passengers to use. |
| **PAID_WIFI** | The carriage has WiFi available for passengers to purchase. |
| **NO_WIFI** | The carriage has no WiFi available for passengers to use. |

## _enum_ AirConditioning

Whether the carriage is air conditioned. The default is UNKNOWN.

#### Values

| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| **UNKNOWN** | It is unknown if the carriage is air conditioned. This is the default case. |
| **AIR_CONDITIONED** | The carriage has air conditioning. |
| **NOT_AIR_CONDITIONED** | The carriage does not have air conditioning. |

## _enum_ BicyclesAllowed

Whether bicycles are allowed in the carriage. The default is UNKNOWN.

#### Values

| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| **UNKNOWN** | It is unknown if the carriage allows bicycles. This is the default case. |
| **ALLOWED_OUTSIDE_CARRIAGE** | Bicycles are allowed to be transported, but must be stored outside of the carriage. |
| **ALLOWED_INSIDE_CARRIAGE** | Bicycles are allowed to be transported, and can be stored inside the carriage. |
| **NOT_ALLOWED** | Bicycles are not allowed to be transported in this carriage. |

## _message_ EntitySelector

Expand Down
1 change: 1 addition & 0 deletions gtfs-realtime/spec/en/vehicle-positions.md
View file
Open in desktop
Expand Up @@ -57,3 +57,4 @@ Vehicle descriptor describes a precise physical vehicle and can contain any of t
* **ID** - internal system of identification for the vehicle. Should be unique to the vehicle
* **Label** - a user visible label - for example the name of a train
* **License plate** - the actual license plate of the vehicle
* **Carriage descriptor** - an ordered list where each item specifies information about a carriage