Add support for feed_info.txt feed_contact_email

[barbeau]

In our last OBA monthly call, we discussed talking with all agencies to see who is actively monitoring the feedback via stop/trip problem reporting APIs, so we can avoid directing feedback to these APIs if no one is listening.

The next question, though, is where do we direct these stop/trip problem reports that are related to GTFS/rt data?

We have the GTFS agency.txt agency_email field, but that's more for customer service issues (e.g., bus driver complaints/compliments, lost and found). Most of the time customer service isn't really equipped to address data issues.

There is a proposal for feed_info.txt feed_contact_email, and it seems like this might be a good fit for this particular use case. Here's the GTFS change proposal on Github: https://github.com/google/transit/pull/31

@sheldonabrown Any thoughts on this? One question is how we would handle this field for multiple agencies/feeds in regional OBA - do we just transform this into an attribute of each agency in agencies-with-coverage API? Or should this field actually be an attribute of agency.txt for each agency?

cc @aaronbrethorst

[sheldonabrown]

I was all set to agree with the agency recommendation, but the Puget Sound regional OBA proves it is not that simple. Services are shared across many operators and tagged as belonging to an agency for branding purposes, but with out much logical arrangement. So with that, I would recommend exposing the feed info as its own API and its own top level object in the references element. I say this as agencies and feeds may have a many-to-many relationship as in the Puget Sound case.

Besides, from a dev-ops stand point, I can see feed_info growing with lots of relevant data and quickly exceed the size of agency meta-data, so cramming it into an agency seems wrong.

So something like this:

<references>
  <agencies>
    <agency>...</agency>
  </agencies>
  <feeds>
    <feed>...</feed>
  </feeds>
  <routes>
    <route>...</route>
  </routes>
  <stops>
    <stop>...</stop>
  </stops>
  <trips>
    <trip>...</trip>
  </trips>
  <situations>
    <situation>...</situation>
  </situations>
</references>

[barbeau]

I agree, having <feed> in references works better. And I guess we would generate a feedId, and each stop would have a list of feedIds to which it belongs (because stops could be merged between feeds)? I think each trip would only have a single feedId (because they can't be merged), but let me know if I'm missing something there.

The challenge from a UI perspective is that we need to go from user facing info to the feed to get the feed.contact_email to report the problem to the right feed maintainer - obviously users have no concept of a feed.

Our general UI flow for issue reporting is:

1. Have user choose stop
2. Choose "stop" or "arrival time" problem
   1. If stop problem, choose from list of stop issues and submit
   2. If trip problem, tap on the arrival time with the problem, choose from list of arrival time issues and submit

So as long as we can link the stopId and tripId to the feed.contact_email via the <references> elements, we should be good.

[barbeau]

One question is if the feedId persists between feed updates. Off the top of my head I can't think of a use case that requires a persistent feedId, but I think generally speaking moving towards persistent IDs when possible is a better practice. So I would recommend that we keep the feedId the same across data updates, unless there is a significant change in the structure of the feed.

[sheldonabrown]

Sorry -- I lost site of the end goal when I was describing how the data relates.

I was actually picturing the opposite with respect of feed id. It would be convenient for keeping track of the latest feed if the feed id was unique to the feed, either a UUID or an MD5sum of the GTFS data itself. But I could be convinced otherwise, especially since nothing else in GTFS behaves like this. Perhaps an example of what the feed id could be would help? As I understand it, the agency id started off as the FTA's NTD id without the region code. Is there some synthetic way to represent the feed id? Like all the agency ids sorted and prepended in some fashion?

Linking trips to feeds is something I hadn't anticipated. It would seem ugly at first but from OBA's perspective we could simply add another bundle index to solve the issue.

On Tue, Nov 29, 2016 at 10:21 AM, Sean Barbeau [email protected] wrote:

One question is if the feedId persists between feed updates. Off the top of my head I can't think of a use case that requires a persistent feedId, but I think generally speaking moving towards persistent IDs when possible is a better practice. So I would recommend that we keep the feedId the same across data updates, unless there is a significant change in the structure of the feed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OneBusAway/onebusaway-application-modules/issues/192#issuecomment-263599320, or mute the thread https://github.com/notifications/unsubscribe-auth/AA9JHXvQ6xK3twxLpJ7J4AF7hXiizVJ1ks5rDEMSgaJpZM4K-E5a .

[barbeau]

I think a versioned feed ID is better off in feed_info.txt feed_version: https://developers.google.com/transit/gtfs/reference/feed_info-file

I guess this would need to be a UUID (or something else) and not MD5 hash, as you couldn't hash the zip file without knowing the hash to put in the zip file (chicken-and-egg).

Yes, the best practice for agency_id is still being openly debated - I've suggested FTA NTD ID for US agencies in the past, and there's also TransitLand's Onestop ID scheme, which would work for non-US agencies as well: https://transit.land/documentation/onestop-id-scheme/

It looks like Onestop ID scheme includes a scheme for feed IDs too - see above docs, and here's the data: https://transit.land/api/v1/feeds

I suppose that's as good as any other scheme, assuming the agency has given Transitland the thumbs up to import their data. For agencies that haven't, we could still compute the feed ID using the same method.

[sberkley]

Now in 2023 this has finally been completed. https://github.com/OneBusAway/onebusaway-gtfs-modules/commit/113c88d60bb4cb89ddee80e562659be1b2eccc7f

Released in v1.4.9 of OneBusAway/onebusaway-gtfs-modules.