All,

Thanks for sending this information. Joshua filled me in on this conversation and I wanted to hop in here. Let me start by pointing out something that may not be clear based on your email above: the TransLoc OpenAPI is not a GTFS API, nor is it a static transit data API. Your observations about the API thus far (1. the response from your query is empty and 2/3. the stop_times.txt file doesn’t match our arrival predictions endpoint) are absolutely correct and expected. Our public maps (http://ncsu.transloc.com, for example) and our mobile apps (http://translocrider.com) are often rebuilt as student projects or to embed other datasets into the map experience. Our OpenAPI provides the following sets of data:
• A list of agencies and how to reference agencies in other datasets
• A list of current routes for an agency/region, including stops served and route segments
• A list of active route segments for an agency/region, including the shape data required to drawing route segments as polylines
• A list of current stops by agency/region, including location, routes and agencies that serve the stop
• A list of active vehicles by agency/region/route, including passenger load, location, and arrival times for upcoming stops
• A list of arrival predictions by stop and agency/route, including upcoming arrival times by vehicles by route
The takeaway here should be that the TransLoc API only provides information on live conditions of transit systems. We do not include any schedule data, at all. One agency_id in your example query (16) is for one of our university customers - the route_id list from the example doesn’t match any of the live data. If you query the routes endpoint for agency 16, then plug the returned route_ids into the arrival-estimates endpoint, you’ll see live data in the response. Our database has to maintain a unique identifier for every route, agency, stop, and vehicle element that we know about, so there is no 1:1 matching between our data and any GTFS feed (outside of cosmic coincidence). Likewise, published changes to our dataset increment these element’s IDs for reporting purposes, so the mapping between our data and GTFS feeds is short-lived and unreliable.

That said, I would be happy to help you navigate our API based on your particular use case. We’ve seen a lot of different projects get built on top of our API, so TransLoc can provide a little bit of guidance beyond our API docs. I don’t know the specifics of what you’re trying to do with our dataset, or how you want to blend that with GTFS, so if you want to share that there may be some advice I can provide. As Joshua mentioned, all support concerns should be directed through the Mashape portal so we don’t lose track of them.

Best,
Spenser Rubin, Product @ TransLoc

On Wed, Sep 20, 2017 at 10:19 AM Scott Kolber scott@roadify.com wrote:
Hi JT- I tried to set up an account at https://market.mashape.com/transloc/openapi-1-2/support but the account set-up process stalled so I sent a note to their support email asking for help. In the meantime, until we get that taken care of, below is the response from Dmitry, copied here, who’s working on this for us. Please feel free to copy him on any reply. Thanks very much. Best, Scott

1. Arrival estimates
   API call
   curl --get --include ‘https://transloc-api-1-2.p.mashape.com/arrival-estimates.json?agencies=12%2C16&callback=call&routes=4000421%2C4000592%2C4005122&stops=4002123%2C4023414%2C4021521’
   -H ‘X-Mashape-Key: vAQKs2Xm0tmshs7rHE9RJbAsn9Lbp1IivTEjsn46HAo54oFHge’
   -H ‘Accept: application/json’

Expected results:
{
“rate_limit”: 1,
“expires_in”: 5,
“api_latest_version”: “1.2”,
“generated_on”: “2014-01-03T21:46:33+00:00”,
“data”: [
{
“arrivals”: [
{
“route_id”: “4000100”,
“vehicle_id”: “4000844”,
“arrival_at”: “2014-01-03T17:06:33-05:00”,
“type”: “vehicle-based”
}
],
“agency_id”: “16”,
“stop_id”: “4099542”
},
{
“arrivals”: [
{
“route_id”: “4002998”,
“vehicle_id”: “4000196”,
“arrival_at”: “2014-01-03T17:02:31-05:00”,
“type”: “vehicle-based”
}
],
“agency_id”: “16”,
“stop_id”: “4099322”
},
{
“arrivals”: [
{
“route_id”: “4000098”,
“vehicle_id”: “4002320”,
“arrival_at”: “2014-01-03T16:59:07-05:00”,
“type”: “vehicle-based”
},
{
“route_id”: “4000098”,
“vehicle_id”: null,
“arrival_at”: “2014-01-03T17:26:47-05:00”,
“type”: “schedule-based”
}
],
“agency_id”: “16”,
“stop_id”: “4102278”
}
],
“api_version”: “1.2”
}

Actual results:
{“rate_limit”: 1, “expires_in”: 5, “api_latest_version”: “1.2”, “generated_on”: “2017-09-19T21:40:35+00:00”, “data”: [], “api_version”: “1.2”}

Vehicles
API call
curl --get --include ‘https://transloc-api-1-2.p.mashape.com/arrival-estimates.json?agencies=12%2C16&callback=call&routes=4000421%2C4000592%2C4005122&stops=4002123%2C4023414%2C4021521’
-H ‘X-Mashape-Key: vAQKs2Xm0tmshs7rHE9RJbAsn9Lbp1IivTEjsn46HAo54oFHge’
-H ‘Accept: application/json’

Expected results:
{
“rate_limit”: 1,
“expires_in”: 1,
“api_latest_version”: “1.2”,
“generated_on”: “2014-01-03T21:22:05+00:00”,
“data”: {
“16”: [
{
“description”: null,
“passenger_load”: null,
“standing_capacity”: null,
“seating_capacity”: null,
“last_updated_on”: “2014-01-03T21:12:47.570000+00:00”,
“call_name”: “4281”,
“speed”: 0,
“vehicle_id”: “4002320”,
“segment_id”: “4043935”,
“route_id”: “4000098”,
“arrival_estimates”: [],
“tracking_status”: “up”,
“location”: {
“lat”: 35.78867,
“lng”: -78.67292
},
“heading”: 101
},
{
“description”: null,
“passenger_load”: 17,
“standing_capacity”: 25,
“seating_capacity”: 20,
“last_updated_on”: “2014-01-03T21:12:47.553000+00:00”,
“call_name”: “4278”,
“speed”: 31.484,
“vehicle_id”: “4000196”,
“segment_id”: “4055095”,
“route_id”: “4002998”,
“arrival_estimates”: [
{
“route_id”: “4002998”,
“arrival_at”: “2014-01-03T16:22:54-05:00”,
“stop_id”: “4099366”
},
{
“route_id”: “4002998”,
“arrival_at”: “2014-01-03T16:36:29-05:00”,
“stop_id”: “4102038”
}
],
“tracking_status”: “up”,
“location”: {
“lat”: 35.78919,
“lng”: -78.69319
},
“heading”: 93
}
]
},
“api_version”: “1.2”
}

Actual results:
{“rate_limit”: 1, “expires_in”: 1, “api_latest_version”: “1.2”, “generated_on”: “2017-09-19T21:42:51+00:00”, “data”: {}, “api_version”: “1.2”}
2 and 3.
I think, they should match.
GTFS documetation says:
https://developers.google.com/transit/gtfs/reference/stops-file
stop_id Required Contains an ID that uniquely identifies a stop or station. Multiple routes may use the same stop. The stop_id is dataset unique.

https://developers.google.com/transit/gtfs/reference/routes-file
oute_id Required Contains an ID that uniquely identifies a route. The route_id is dataset unique.

Stop and route ids don’t have to start with 1 or any other number, the only requirement - uniqueness, so they absolutely can be the same as API returns.

We have static data loaded with GTFS, and real-time (it doesn’t yet return data, but due to documentation) data loaded from API. And we need to match real-time delay with specific trip from static GTFS feed (by stop_id, route_id and and time). But now - we cannot do it, since these ids from real-time don’t match any ids from GTFS static feed.

There is a stop_sequence field in stop_times.txt file of GTFS static feed, this field corresponds to order of stops for route. So, all stops are shown ordered by value of this field. Looks like there is discrepancy between departure/arrival times and stop sequence.
Scott Kolber
Roadify, CEO
http://www.roadify.com/
+1 646 734-8388

Hi Scott,

Thanks for reaching out. Going forward, any API-related questions can be posted here: https://market.mashape.com/transloc/openapi-1-2/support

1. Can you send over the language that was used in the call? Can you provide any ID’s used in the call and the expected outcome?
2. The stop and route ID’s in the GTFS feed differ from the stop and route ID’s in the API. The ID’s from both data sets should never match up.
3. Can you clarify? Is there there a question here about the route data?

Thanks,
JT

On Tue, Sep 19, 2017 at 1:55 PM, Scott Kolber scott@roadify.com wrote:
Hi JT- Joel sent us the updated Columbia U GTFS feed which we’ve uploaded, and we’re also working with the real time data to support Four Winds bringing it all live on digital screens at the university. We’re hoping you can provide us with some guidance on a few issues that we’re seeing with the data, per the notes below. Copying Dmitry and Kevin on our team who are working with the data feeds. Thanks very much!

Here is API documentation we’re using: https://market.mashape.com/transloc/openapi-1-2

1. The two real time API calls that seem most useful for us (Arrival Estimates and Vehicles) aren’t returning data:
   Both are returning empty data fields. We checked yesterday at 3 pm NY time to be sure it was during service hours.

2. Stop and route ids are different in the GTFS feed and API. API has some parts working - with stops and routes.
   Example from documentation for Arrival Estimates:
   {
   “arrivals”: [
   {
   “route_id”: “4000100”,
   “vehicle_id”: “4000844”,
   “arrival_at”: “2014-01-03T17:06:33-05:00”,
   “type”: “vehicle-based”
   }
   ],
   “agency_id”: “16”,
   “stop_id”: “4099542”
   }
   In the API stop_id is “4099542”, but in GTFS feed (stops.txt) there are 39 stops and their ids are numbers from 1 to 39.
   In the API route_id is “4000100”, but in GTFS feed (routes.txt) there are 4 routes and their ids are numbers from 1 to 4.

3. The GTFS feed appears to have some departure times out of sequence and others with departures only a couple of minutes apart and then several hours gap until the next one. This varies from route to route (Red, Green, Blue, Purple) and depending on when we check.

Thanks in advance for your guidance on these issues. Best, Scott
Scott Kolber
Roadify, CEO
http://www.roadify.com/
+1 646 734-8388