Frequently Asked Questions
How often can I request data?
As often as desired, however all data is cached for 10 seconds so a request made more often than that will receive cached data.
Can I use UTA logos?
According to the terms of use, you cannot use UTA logos.
Can I write a program to scrape data from UTA public websites?
Yes, data found on UTA websites is for public use. One caveat is that there is no guarantee that the data and site structure will not change.
Scraping data also exludes the app from being listed on our App Center page.
How can I communicate with UTA developers? What are the future plans for the APIs?
Join our Google group to post questions and discuss the API with
the UTA developer community. Along with other 3rd party developers, internal UTA developers are also members of the community, and they may be able to answer questions and provide news.
Will UTA host my program on its websites?
To maintain neutrality, UTA does not host 3rd party software on the developer site. However, we can provide a link to your website on the App Center page.
You'll need to fill out the application form to have it posted.
Where can I find a dataset with routes and stops?
UTA provides that data via a GTFS feed to google. You can learn more about GTFS here.
One place you can get UTA's feed is here.
What is the difference between the two APIs that are offered?
The first API, or GTFS files, contains information about our routes, schedules, stops, etc. The second API, or
SIRI, provides realtime location information about our vehicles as well as predicted departure times. SIRI is a restful service accessed via
HTTP just like a normal web page, whereas the GTFS files are downloaded so they can be stored and queried within your software.
Is there a demo for SIRI that I can use to get started?
At our initial release, we provided a basic open source demo on how SIRI might be used as well as a
slide deck. The demo requires you to have registered for a token and that you have Google
Earth installed. Google Earth is used simply as a demonstration case, but any map system you can interface with can be used within your software as needed.
How do I handle merged GTFS data?
In order to avoid time between schedule changes when no schedule data is available, the GTFS specification calls for merging the current schedule against one or more future schedules. In order to
query the correct records, a date – usually the current date – now becomes a necessary parameter in order to avoid querying seemingly duplicate matching records across the various schedules. This
way your software can pull the correct records on the last day of a schedule and then again the next day for the new schedule all without needing an update of the GTFS data before the new schedule
can be queried. This is important, because new GTFS data is often not released on a schedule change day, and this merged schedule data allows your app to deliver critical new schedule information
the moment your users need it.
UTA may release a merged GTFS file at any time – especially within the month preceding a schedule change. Your software will need to be able to handle this data correctly in order to avoid problems
for your users (i.e. the appearance of duplicate routes, etc.).
This means that when using a merged file, you must make sure to check the date range in Calendar.txt. There will be more than one service_id for a given route_id and one service_id for each date
range. In a non-merged file, there may only be one date range, but if you always check for the right date range, it won’t matter if you are working with a merged GTFS file or a non-merged GTFS file.
Be sure to read the Google GTFS Specifications to understand how to do this. Google suggests that there is no secret
to reading merged GTFS data; if your software is reading the GTFS records the way the specification describes, then your software will work equally well with merged and non-merged GTFS data.
Example: You want to know what kind of service route 17 has on July 24 2013.
- Find the route_ids for route 17 in the route.txt. The route_ids are 40784 and 41069.
- Find the service_ids for route_ids (40784 and 41069) in trips.txt . The service_ids are 4_merged_1520956 and 4_merged_1520927.
- Find which days (Sun-Sat) the service is available in calendar.txt for service_ids (4_merged_1520956 and 4_merged_1520927) for July 24, 2013. The line
"4_merged_1520927,20130414,20130817,1,1,1,1,1,0,0" shows this service is running Mon-Fri from Apr 14, 2013 to Aug 17, 2013. The Line "4_merged_1520956,20130217,20130413,1,1,1,1,1,0,0"
shows the service running Mon-Fri from Feb 17, 2013 to Apr 13, 2013, so ignore this line – its date range does not apply to July 24.
- Now check for exceptions for this date in calendar_dates.txt. From the line "4_merged_1520927,20130724,2" we see that service has been removed for that day.
How can I know when a new GTFS file set is available?
UTA may begin releasing new GTFS updates as frequently as every week or more, since small changes are often made throughout a schedule period. In order to avoid hardcoding GTFS data into your
software and releasing a new version with each change, it’s recommend that your software be designed to automatically download and install GTFS data into your repository as it becomes available.
To determine when a new GTFS file is available, an RSS feed is available at our
GTFS publication location. There are a number of ways to use the RSS feed to determine if an update is available,
including the following two:
- Your software could check the link in the "id" node in the first "entry" XML node and compare with the same id you store in your software the last time the GTFS data is downloaded. If they
don’t match, then a new GTFS data set is available to download from the link
http://www.gtfs-data-exchange.com/agency/utah-transit-authority/latest.zip.
- Otherwise, you could check the file name in the "content" node to get the file’s release date. For example, a file name of "utah-transit-authority_20130413_0322.zip" would mean that it was
released on April 13, 2013 at 3:22 a.m.
