How to address operational specific needs in a GTFS

[EmmaMagnifici]

Introduce yourself

Hello,
I work for RATP DEV in France, I help affiliates with their AVLS and Passenger Services matters and sometimes ticketing when data expertise is required (about GTFS, GTFS-RT, Siri etc)

Ask a question

For many years now, we deal with providers that will only accept GTFS as input data (ticketing systems and AVLS). GTFS is for passenger services and they are a lot of "non commercial" data needed to make the Systems work properly.

Eventually, we end up to bending the data and create many specific GTFS so the Systems can work.

I give you 3 examples:

1. For one of our affiliates, I have a GTFS with standard trips.trip_headsign (for the website, app etc), and we had to create a new one for Systems with external destination sign code.

2. 2 GTFS too for another affiliate: one with standard trips.block_id (sequential trips made using the same vehicle), another one specific required by System with sequential trips made using the same driver.

3. Ticketing System doesn't accept our GTFS because there is no stop_sequence = 1. Indeed, the first stop of the trip is non commercial (a parking lot). So in the GTFS, stop_sequence starts with stop_seq = 2. This is not a bug, this is real life.

How can we address operating systems needs with a GTFS that is build for passenger information?

Thanks you for your help and sorry if you already answered this question.
Regards
Emmanuelle

[stevenmwhite]

GTFS is very extendable, and you can add additional fields or additional files that aren't in the specification itself. Consumers will ignore fields and files that they don't understand.

For your example number 2, we have the same need, and we import GTFS files from multiple scheduling systems with an additional field called run_id for exactly this purpose (we also have some fields like run_label for human-facing names). In our case, these fields don't appear in the GTFS that get published for public-facing consumption by rider-oriented apps (but they technically could), but do get used in GTFS files exchanged between the commercial systems.

[felixguendling]

I think some of what you describe might be in TODS but maybe someone who has experience with TODS can say more about your concrete examples. Another option could be NeTEx which was designed for dual-use (operations + customer information) from the beginning and is used like this in Norway as far as I understand.

[EmmaMagnifici]

This is great, thanks to both of you for your help. TODS is pretty interesting as well.

[laurentg]

For point 3, one hack is to configure your first stop time with pickup/dropoff flag set to 1 ("none"). That way the stop is provided in the GTFS but not usable for riders. Be careful when using this if you use block IDs and if you have a previous trip within the same block. But for deadhead trips that's usually not the case.

[EmmaMagnifici]

We tried to trick Hastus with pickup and drop_off_type = 1 but it's too smart and he didn't export the stop.

[skinkie]

We tried to trick Hastus with pickup and drop_off_type = 1 but it's too smart and he didn't export the stop.

Export NeTEx directly from Hastus. Do the NeTEx to GTFS conversion as a step afterwards.

[EmmaMagnifici]

We tried to trick Hastus with pickup and drop_off_type = 1 but it's too smart and he didn't export the stop.

Export NeTEx directly from Hastus. Do the NeTEx to GTFS conversion as a step afterwards.

The French Authorities asked a fews years ago but Giro refused. We already have a standard export for Hastus, it's called "AVL export" and it's perfectly fits to our needs. The thing is, this a bit more difficult that GTFS to understand

[skinkie]

The French Authorities asked a fews years ago but Giro refused.

We were informed that Giro illegally sold our solution :-)