3. Bus API

Last and totally least (in my opinion) is the Bus data. You don’t currently need an API key to hit this endpoint. Like the train API, it too is a big list, but it only has one entry for every vehicle_id. If you’re hoping to see future estimates for a bus, you have to build it yourself using the 40MB GTFS ZIP file, and you have to keep that ZIP file updated. The basic idea I have is that you take an entry like this:

{

"ADHERENCE":"-32",

"BLOCKID":"487",

"BLOCK_ABBR":"809-2",

"DIRECTION":"Southbound",

"LATITUDE":"33.8106058",

"LONGITUDE":"-84.3707666",

"MSGTIME":"11\/17\/2019 2:18:05 PM",

"ROUTE":"809",

"STOPID":"103900",

"TIMEPOINT":"King Memorial Station",

"TRIPID":"6852151",

"VEHICLE":"1893"

}

and assuming MARTA keeps things updated, you can take that TRIPID value and look that up in the GTFS data, in the trips table. From there you can get all the future stops for the bus, and link it up to the future stop you care about. The other IDs ( BLOCKID , ROUTE , and STOPID ) also tie up to the schedule data.

This API endpoint is sorted by MSGTIME , which I believe is the timestamp that the bus last checked in. I’ve gathered a couple conspiracy theories over the years involving bus drivers having to manually check-in to produce these API entries. To this day I imagine stressed out MARTA bus drivers sitting in Atlanta traffic, just trying to survive. If we are relying on them to manually populate this API, then I can imagine there will be edge cases.

I also put the bus API last because I have yet to be able to build anything usable with it, even though people have requested it multiple times over the years. You have to import 40MB of CSVs, you have to keep them updated, and that is just way more maintenance than filtering the single train API endpoint.