Embedded Files
Create and Maintain a Permanent Fetch Link
Create and Maintain a Permanent Fetch Link
What is a static fetch link?
What is a static fetch link?
A static fetch link is a permanent URL where your static GTFS file is stored. Typically, it is hosted either on your agency’s website or by your vendor, if you contract with one for GTFS.
This is the way that trip planning apps like Google Maps access your GTFS. Your static GTFS files should be downloadable directly from this URL without requiring a login.
Concerns about licensing restrictions? Learn about restricting access to your GTFS.
URL Names
URL Names
Consistent fetch link and GTFS file names are crucial to ensuring access to your GTFS. If your agency does not use consistent URLs and file names for its data, it means that trip planning apps, feed aggregators, and other users will not get the most accurate and up-to-date GTFS, which will cause problems in the long run.
Once you have set a URL for your permanent fetch link, DO NOT CHANGE IT. This means that the URL should stay consistent, even when the GTFS is updated. Keep your URL as simple and generic as possible. Avoid using a URL that has an application name, dates or version numbers in it.
File Names
File Names
Likewise, keep the name of the ZIP file containing the GTFS consistent, even when making updates. For example, when you update a GTFS, do not add date or version number to the ZIP file name. If you would like to include data on the feed version or feed start and end dates in the feed, you can include it in the feed_info.txt file.
BEST: “YourAgency_gtfs.zip”, “gtfs.zip”
GOOD: “google_transit.zip”
AVOID: “YourAgency_gtfs_092921.zip”, “YourAgency_Fall2021.zip”
Sharing your GTFS fetch link
Sharing your GTFS fetch link
Should you share your link when asked by app developers or other interested parties?
Yes!
GTFS is an open data specification, and the best practice is to ensure that when you organize your transit information into GTFS format, that it is made available for anyone wishing to use it.
This means that it is also possible your agency’s data could be included in a different GTFS than the one you are maintaining.
Dealing with conflicting GTFS sources
Dealing with conflicting GTFS sources
The best way to ensure that your GTFS is the one that gets used by an application is to make that data publicly available at a static fetch link. This ensures that if a conflict arises about the source of a GTFS, you can definitively point to your GTFS as the best one to use.
There are cases where an application, such as Google Maps, must select data from one GTFS over another. One common example is a stop’s name and code - many agencies may share a single stop, each with their own name and code. Because only one name and code is shown on this application, the best way to ensure it matches what you wish riders to see is to coordinate your GTFS with other overlapping agencies. If all affected agencies agree upon the name and code, then the likelihood of conflicts between multiple GTFS datasets is minimized.
Which GTFS to use?
Which GTFS to use?
In the event you have multiple GTFS datasets available to you - usually the result on one being produced for public applications like Transit App, and another being produced for internal operational CAD/AVL systems, you may need to decide which one will be the GTFS you choose to promote and share.
It is recommended you choose to promote the GTFS that contains the most rider-facing information. GTFS that contain internal/jargon-y names for routes or stops, lacks fare information, or contains stop locations placed to intersect with the path of travel of the bus (common for CAD/AVL systems) should not be considered for public use. Whenever possible, seek to have your GTFS datasets match (e.g., same IDs for stops) so that internal ones do not conflict with public ones, and integrating other feeds like GTFS-rt feeds is possible.
Page updated
Report abuse