GTFS-RT Proposed changes to specitication

[gregory....@transport.nsw.gov.au]

All,

 Attached is a sample protobuf file containing proposed extensions to the GTFS-RT specification.

There are two principle extensions included :-

(1) A new message - UpdateBundle - that provides a way to add a new trip or cancel a scheduled trip. The details of the added trip are exactly the fields defined in trips.txt and stop_times.txt. The cancel function is pretty much a repeat of the existing TripUpdate function but is included for consistency. The intent of this change is to permit operators to alter their schedule and include the same level of information present in the static feed. TripUpdate would then be used for running services only. 

(2) A new field in the existing VehiclePosition message. This is specifically for rail. It is a repeated field that contains information about each carriage in the consist. The purpose is to allow rail operators to present a structured consist with carriage specific information (eg. occupancy by carriage, presence of facilities etc). This is extremely useful information for passengers and is frequently not available until a specific consist has been allocated to a service. 

The protobuf file is a sample for comment and it's my first one, meaning it likely contains errors some of which may be spectacular. Please be gentle when correcting. The file is there to communicate intent. 

The outcome we seek is to understand whether there is community support for these types of changes or whether we should go the extension route. 

Thanks for reading,

Gregory Nicholls. 

NSW Trains

[gregory....@transport.nsw.gov.au]

Opps,

 Wrong version of the attachment. 

This is the (hopefully) correct one. 

Sorry,

Greg.

[Ritesh Warade]

Hi.

We are definitely interested in (2) since it's important information for rail systems. 

Can you please give a plain text example of how you expect this to be used to represent one or many carriages in a consist and their order?

Thanks

Ritesh

---
Ritesh Warade
Associate Director, IBI Group | 617.699.9544

--
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/47781fc3-13e8-4fa0-94cd-af4befced3c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gregory....@transport.nsw.gov.au]

Hi Ritesh,

   As it stands, passengers can find out the estimated arrival time at their stop and get some indication of the loading, but that's it. What we envisage is using this new structure to identify the number, sequence, passenger loading and onboard facilities on a per carriage basis. We imagine an app would be able to highlight which carriage has seats available (and therefore where to stand on the platform) as well as assisting disabled passengers or those with luggage in the same way. Effectively reducing dwell times by allowing passengers to self-arrange themselves on the platform according to what (if any) specific facilities they may need. 

 The carriages are represented in order oriented from a central point on the network. Depending on which way the train is running (UP - towards the node) or DOWN (away from the node), consumer applications need to present the consist ordering as is in the feed, or reversed. 

Does that help ? 

[Ritesh Warade]

Hi Greg,

Sorry for not being clearer:

Could you provide a data example in plain text representation of the protocol buffer file?

So an example of a vehicle position entity is: 

entity {
id: "1466513238_y2260"
vehicle {
trip {
trip_id: "30118489"
start_date: "20160621"
route_id: "1"
direction_id: 1
}
position {
latitude: 42.3684425
longitude: -71.10887
bearing: 36
}
current_stop_sequence: 8
current_status: STOPPED_AT
timestamp: 1466513164
stop_id: "69"
vehicle {
id: "2260"
label: "2260"
}
}
}

How would this change if the vehicle was a train with multiple carriages.?

Ritesh

---
Ritesh Warade
Associate Director, IBI Group | 617.699.9544

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/2dbf61f8-a70f-406d-964d-afd5b9cb7233%40googlegroups.com.

[Tony Laidig]

One example of a UI that presents train loading information to passengers is JR East's app showing relative crowding on the Yamanote line in Tokyo. This extension would enable a similar UI to be powered solely from a GTFSrt source.

https://3.bp.blogspot.com/-5Qu1q_bzUSQ/VSD__pwjeyI/AAAAAAAAGlw/jqzTU2rGe1Y/s1600/yamanote-location.png

[gregory....@transport.nsw.gov.au]

Hi Ritesh,

 Completely off the top of my head I imagine a feed would look something like this version of your sample: -

entity {

id: "1466513238_y2260"

vehicle {

trip {

trip_id: "30118489"

start_date: "20160621"

route_id: "1"

direction_id: 1

}

position {

latitude: 42.3684425

longitude: -71.10887

bearing: 36

track_direction:0;   // new field representing the orientation of the train with respect to a well defined central point

}

current_stop_sequence: 8

current_status: STOPPED_AT

timestamp: 1466513164

stop_id: "69"

vehicle {

id: "2260"

label: "2260"

// new fields representing a 4 carriage consist. carriages are in order relative to DOWN. combined with the track_direction enables a 

// consumer app to determine the orientation at a specific location 

carriage {

name: "C213"         // Carriage identifier

occupancy_status: 3  // front of train is crowded, rear has space

toilet: 1;           // ambulant toilet here  

}

carriage {

name: "D202"         // Carriage identifier

occupancy_status: 2  // this is a bit full, move down to the next carriage

toilet: 0            // no toilet

}

carriage {

name: "D345"         // Carriage identifier

occupancy_status: 1  // more seats available here

toilet: 0            // no toilet

}

carriage {

name: "C222"         // Carriage identifier

occupancy_status: 1  // more seats available here

toilet: 2:           // disabled toilet here

}

}

}

}

[Kenneth Tsang]

Hi Greg,

I might be missing something, but is there an advantage in describing the consist relative to the track direction rather than the direction of travel?

Also, would defining direction_id relative to a central point be an adequate substitute for track_direction?

Cheers,

Ken

[gregory....@transport.nsw.gov.au]

Hi Kenneth,

 Yes, you could define the consist based on the current track direction and define the spec to read the first carriage in the RT feed is the leading carriage on track. That's probably a better long term approach than mine. 

[Sean Barbeau]

Gregory,

Thanks for sharing!

FYI - #1 has come up before.  There actually used to be a TripDescriptor.ScheduleRelationship = REPLACEMENT value, but the behavior wasn't well specified and it ended up being removed in 2014:

https://groups.google.com/forum/#!topic/gtfs-realtime/77c3WZrGBnI

A 2015 proposal to add something similar back to the spec:

* https://groups.google.com/forum/#!topic/gtfs-realtime/npG8Z0Iqt4k

Sean