DetailedItineraries does not contain any agency info

[wklumpen]

When using multiple datasets, it is not clear what agency a "route" might be associated with. I think if possible we need another column to show some sort of unique-ish Agency information (or in my case ideally the actual GTFS source).

Do we know off-hand what's returnable here? Otherwise I can dig into the code.

[wklumpen]

From poking around it looks like we use a distinct TransitLayer for each GTFS feed? At least that's how I read this load function. At the very least it seems the feed ID is kept unique; is there a way to map that back?

[christophfink]

You could check out what’s in route in TripPlanner#L354. It is a com.conveyal.r5.transit.RouteInfo, there should be an agency saved in there

[christophfink]

there’s a bit of inheritance logic on how TripLegs (e.g., TransitLegs) are assembled to Trips and then summarised in DetailedItinerariesComputer, but I guess it’s an easy and accessible version of a Matrushka doll ;)

[christophfink]

I mean we could simply add another column there, but it needs to be added in the right places.

[christophfink]

Since you’re the GTFS expert, @wklumpen , could you choose which of the following would be most relevant to include in the output data (I would suggest to refrain from including all of them to keep our output at a reasonable size)

[wklumpen]

Based on OTP itineraries it seems to me that the minimum set of useful data would include (from the GTFS)

agency.agency_id

route.route_id

trip.trip_id

stop.stop_id

Which could then be easily joined with various GTFS tables to get more metadata.

Looking at that line of code I can't quite see what's all available but I'll look again. Happy to attempt a PR but I'm not quite clear on how it's all nested here.

[wklumpen]

Route Info contains agency/route level data so that's a good start. Given this is designed as a trip planner and that we have times in the output we must have some trip, stop, and stop_times level data floating around.

[wklumpen]

Oh and to avoid ambiguous agency ID issues I would actually go with agency.name

[christophfink]

You’d have to start from r5py.r5.TripLeg: change its COLUMNS and adapt the __init__() to accept the additional parameters, also adapt the docstring of as_table_row(). In r5py.r5.Trip, adapt the docstring for as_table(), also replace routes() with the respective alternatives (see the code there, not complicated). Then, add (and possibly typecast) the route info data in r5py.r5.TripPlanner (the line mentioned above). Finally, make sure the docstrings throughout (e.g., in DetailedItinerariesComputer) are up to date

Probably forgot something here, but those are the steps I think will sufficient/necessary

[wklumpen]

Okay here's what I'm going to add (as I need it for my purposes and it allows a complete reconstruction of steps). Let me know if there's a red flag anywhere there, I'm happy to write up a guide afterwards about what to do with it.

• feed (the GTFS feed identifier, which seems to match the filename)
• agency_id the agency ID inside the feed, usually there's just one but this lets us identify between multiple
• route_id (replacing route which was the route name - the GTFS route_id identifier)
• start_stop_id (the GTFS stop_id identifier for boarding)
• end_stop_id (the GTFS stop_id identifier for alighting)

This allows us to capture a sufficient level of detail to track what stop is being used where. We could I suppose also add the trip_id, at the moment I don't really need it, and stop patterns in R5 are done a bit differently.

Note however that this no longer produces "human readable" information in terms of what you might expect from a trip planner, but when the data is joined to a GTFS feed it can provide the required data.