I’ve recently been trying to create a tool that determines the most likely route of a vehicle from an unsorted cloud of latitude/longitude pairs. The purpose was to mash together existing shapefiles associated with each route that the MTA has to form the complete route. You can read more about this in my preceding blog posts. What this post is about is how to use the MTA itself to pull a shapefile for a given bus route. This post is also intended to be a resource for those seeking to pull bus shapefiles for any route from the MTA.
The reason for pulling from the MTA online rather than using those associated with the shapefiles is written about in detail in prior posts. The general issue is that the shapes provided with the GTFS data are fragmented and, if one just wants a sort of “de facto” route for a given bus line, it is definitely easier to just default to the one that is provided from the MTA when you visit a given route.
The MTA actually has some handy API functionality (though I have yet to find some decent documentation for it). The URL http://bustime.mta.info/api/search?q=*****
allows you to enter in a given bus route (marked in the example by ****
) and receive a JSON such as in the below.
The part that matters from that example is the key polylines
. This key’s value is an encoded string that, when run through One Bus Away’s OBA decode utility, produces a latitude/longitude array that can be used as a lineString GeoJSON. The portion of the OBA utility that performs this action is called decodePolyline
. I went ahead and extracted and cleaned it up - it’s included in the below code snippet.
This tool is pretty useful. I wrote a simple Node app that takes the name of the bus route. You don’t even need the exact name - MTA guesses which it is and gives you suggestions. It’s decent; if you put in any variation of, say “M60” (such as “m60” or “M60-sbs”) and it will return the M60 bus line information. In the below server.js
code I just made a simple Node app that takes the bus route name that you want and it reconfigures the JSON supplied by MTA with the actual latitude/longitudes instead of the polyline encoded string value. The code for this tool is included in the below snippet. Just make sure to include the defintion for the decodePolyline
function, as well, and it should be good to go.