proposed addition to spec: TripDescriptor.direction_id

[Ethan Arutunian]

Based on the discussion around Metro North's real-time feed, I would like to formally propose the addition of the "direction_id" field to the TripDescriptor definition:

Field Name: direction_id
Type: uint32? bool? (open to suggestions here)
Cardinality: optional
Description: The direction_id from the GTFS that this selector refers to.
The direction_id field contains a binary value that indicates the direction of travel for a trip. Use this field to distinguish between bi-directional trips with the same route_id. This field is not used in routing; it provides a way to separate trips by direction when publishing time tables.

• 0 - travel in one direction (e.g. outbound travel)
• 1 - travel in the opposite direction (e.g. inbound travel)

The proposed initial GTFS-realtime producer is Metro North Railroad (to be added to their real-time feed).
The proposed initial consumer is Roadify (to test the change).

This is an official request for comments on the proposed change.

Thanks for your consideration!

-ethan

[tomc...@gmail.com]

I agree. On the NYCT feed we added a number of extensions including direction, track ID, ATS A Train ID plus others.

Sent on the Sprint® Now Network from my BlackBerry®

---

From: Ethan Arutunian <et...@roadify.com>

Sender: gtfs-r...@googlegroups.com

Date: Mon, 18 Nov 2013 17:17:40 -0800

To: <gtfs-r...@googlegroups.com>

ReplyTo: gtfs-r...@googlegroups.com

Subject: [GTFS-realtime] proposed addition to spec: TripDescriptor.direction_id

--
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/528ABC34.7090702%40roadify.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Ferris]

I'd vote for uint32 (vs bool) just because it more closely matches the int-like semantics that I've seen in most GTFS libraries that parse direction_id in trips.txt.

I'd actually also like to propose a slightly different strategy for handling extensions to GTFS-realtime like this one.  Read on for the details, but tl;dr - let's go ahead and reserve field #6 in TripDescriptor for this new field (aka "optional uint32 direction_id = 6;").

I'll post a separate message to the group about extension proposals.

Brian

[Dave Barker, MBTA]

Agreed! When known this is a highly valuable piece of data. 

Regarding bool vs. uint32, I would tend towards bool, since direction_id is described as a "binary value" in the GTFS spec.

-Dave Barker, MBTA

[Michael Smith]

It is certainly desirable for there to be just two directions. But I have seen so many complicated configurations that I'm sure some, though a very small number, could need more.  Still, for consistency, I think it should indeed be limited to a Boolean. 

Mike

--
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/bf6055e7-f394-4732-9f96-8446cb333e6c%40googlegroups.com.

[Brian Ferris]

I think if there is any chance we'd want GTFS trips.txt direction_id to allow more than two values at some point in the future (conceivable), then that's a good reason to make GTFS-realtime direction_id a uint32, not a bool.  If we pick bool now, it becomes extremely difficult to change the type in the future.  Plus, direction_id just doesn't feel like a bool to me, as it's almost always communicated as 0 or 1 in GTFS, not as "true" or "false".

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/8D650D64-0970-40B6-923A-58969F15E285%40gmail.com.

[Barker, David]

Valid reasoning. I certainly wouldn't object to it being an integer. 

-Dave (via mobile device)

Dave Barker, Manager of Operations Technology

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CAG9YwWAGc2x2fSW1UP_xtYt68wDvheDiQyAO0LN0ZkSuVasVGA%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

______________________________________________________________________
This email has been scanned by MessageLabs and contains no viruses or malware.

_______________________________________________________________________
This email/electronic message, including any attached files, is being sent by the MBTA. It is solely intended for the recipient(s) and may contain information that is proprietary, confidential, legally privileged, and/or exempt from disclosure pursuant to state and federal law. If you have received this message in error or are not the intended recipient(s), please notify the sender immediately by reply, and delete all copies of this email/electronic message and any attached files from your computer. If you are the intended recipient(s), you may use the information contained in this email/electronic message and any attached files only as authorized by the MBTA. Any unauthorized use, dissemination, or disclosure of this email/electronic message and/or its attached files is strictly prohibited.

[Michael Smith]

Given that I think consistency is a good thing, would it be possible to also revisit the GTFS spec to see if both GTFS-realtime and GTFS can both be integers without breaking existing applications?

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/73B5F217-C11E-4646-8025-78EBFB73EBEC%40MBTA.com.

[Brian Ferris]

At the end of the day, trips.txt direction_id is just text in a GTFS feed.  It's more of a question of how GTFS parsers choose to implement the field.  In the OneBusAway GTFS library and in Google's own GTFS parser, it's parsed as an int.  In the Python-based transitfeed library, it's parsed as a string value.  I'm not sure how other libraries handle it.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CA%2BvEGE3-L6_j7XXdxsL6se4Tj%2B9zk6r%2BES5R--xY5scG1J41MA%40mail.gmail.com.

[Brian Ferris]

I wanted to bump this thread again.  It seems like the field type is still the main issue at this point.  Any chance we can come to some consensus?  I'll admit that I still prefer "uint32".  Is there anyone who feels strongly enough that this is the wrong choice that'd they'd oppose adoption?

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CA%2BvEGE3-L6_j7XXdxsL6se4Tj%2B9zk6r%2BES5R--xY5scG1J41MA%40mail.gmail.com.

[Stefan de Konink]

Considering the at least five options in NeTEx for this value, I'm totally
pro uint32.

Stefan

[Brian Ferris]

I wanted to revive this proposal.  Since no one objected strongly when I made the suggestion two months ago, I'd like to formalize this proposal:

Let's reserve field #6 in TripDescriptor for this new field:

// The direction_id from the GTFS feed trips.txt file, indicating the direction of travel for this trip.

optional uint32 direction_id = 6;

Assuming I hear no objections, I will probably go ahead and reserve the field, as well as adding support in the OBA GTFS-realtime library.

Thoughts?

[Brian Ferris]

Ok, as there are no objections raised, I'm going to reserve field 6 of the GTFS-realtime TripDescriptor message for the direction_id field as proposed.  Note that this does NOT mean that the proposal has officially been adopted to the spec. Rather it means that GTFS-realtime producers and consumers will be using the specified field for evaluating this proposal for official adoption in the spec.

Thanks,

Brian