[QUESTION] Long-term Support for Mobility-Database-Catalogs Repo vs. New Mobility Database API

[mil]

The new Mobility Database API can provide much of the functionality of this repo (mobility-database-catalogs) & might potentially replace the existing CSV generation workflow. However, I'd note that from a business & end-developer perspective, consuming a CSV is often simpler to use & more pragmatic than integrating with a custom HTTP API for simple usecases.

As an end-user of Mobility Database's CSV (with an app that depends on it) currently, I want to confirm which is the case from Mobility Data's side long-term:

1. Long-term: there will be support for both this repo (mobility-database-catalogs) AND in parallel now there is just newly added support for the Mobility Database API (mobility-feed-api)
2. Long-term: only the Mobility Database API (mobility-feed-api) will be supported and over time this repo (mobility-database-catalogs) & CSV generation workflow is planned to be deprecated in favor of the API.

Is (1) or (2) the case from Mobility Data's side?

If I could vote - I'd voice my support for (1) but I'd like to find out either way which is the case.

Is the long-term roadmap wrt. mobility-database-catalogs & mobility-feed-api documented somewhere?

[mil]

I found this ticket which seems related:
MobilityData/mobility-feed-api#779

IIUC there is no long-term plan to deprecate CSV usage for end-consumers; but 'dynamic data' & CSV generation will move to mobility-feed-api? And then mobility-database-catalogs repo will only contain 'static' data (e.g. which feeds should be included in the Mobility DB dataset)?

[davidgamez]

Hi @mil, Thanks for your continued support. The mobility-feed-api was introduced to support API consumers and also create a more robust internal maintenance process. We understand the importance of CSV as a source of information. As a long-term strategy, we are:

• Deprecating the addition/update of feeds in the mobility-database-catalogs repository.
• Generate a CSV from the mobility-feed-api. We will continue supporting CSV users; only the source of truth will be from the API, not the catalog repository. This work is already in progress more info. We will try to keep backward compatibility with the current CSV; in any case, we will have documented a migration path if there are any breaking changes.
• New additions and updates will be ported over the API/ new UI. While we are developing the backend process to accomplish this without depending on GitHub actions, it's currently valid to add/update feeds within the catalog repository.
• All this will be announced when we are ready. As a limited-resource organization maintaining a couple of open-source projects, we need to shift gears to make sure projects are getting enough attention from us. We are also mindful of the community and will give users time to migrate to the new CSV and provide support.
• The main driver for this change is to be able to cover more complex scenarios and also import a bulk number of feeds from NAS(National Access Points). This will only be possible with the introduction of more automated processes.

I was collecting my thoughts when I read your second comment. I'm glad that you found the related issue

[davidgamez]

I found this ticket which seems related: MobilityData/mobility-feed-api#779

IIUC there is no long-term plan to deprecate CSV usage for end-consumers; but 'dynamic data' & CSV generation will move to mobility-feed-api? And then mobility-database-catalogs repo will only contain 'static' data (e.g. which feeds should be included in the Mobility DB dataset)?

All the feeds will be in the new CSV(GTFS and GTFS-RT). Feeds that are "bulk" imported won't appear in the mobility-database-catalogs repository. Once 779 is completed and tested, we will advise users to move the "new" CSV as it will contain more feeds.

[mil]

Great - thank you @davidgamez

This does really clarify things. I'm really looking forward to the first version of the new CSV based on 779.

And I'm also looking forward to the new feeds automatically imported sourced from NAS.