The motivation for doing the work was to provide the ability to query via SMS capable phones and pagers. I wanted to find a way for recent immigrants / non-native English speakers to get good routes quickly without having to call MTC and stumble through an English conversation.

It looks like you’ve already done a lot of good work getting the data between gis and a more usable format. This could really prove to be something awesome. I know there’s a few places out there that turn lat/lon into Gpoints data for integration so I doubt it would be much of an issue to shuttle data from GIS->gmaps with a little tweaking.

Oh, and I know this post is terribly disorganised, but I also heard in my correspondence that they’re planning to implement a ‘real bus arrival time’ option for the trip planner and possibly phone schedule service, which means they certainly do track the gps units on the buses. I doubt they’ll make the backend data available, though ):

But seriously, great work! I might have to dust off the old ArcGIS and download those layers when I get home from work.

bus stops and bus service

Shows up correctly in preview…

Anyway, I wrote an application that does what I think you guys are looking for maybe a year or so ago now as an experiment in ruby. The route information you’re after from the MTC is already made publically available as GIS data, updated quarterly and is available via ftp here (might be down because they are probably updating the new March route changes, it was hit or miss when it was up when I was developing, I have the files from December 2005):

The app is a bus route planner that takes as input 2 spatial GIS coordinates, one temporal coordinate, and returns you a string containing the shortest bus route plan consisting of bus identfiers, spatial location of the initial bus stop, and stop times that will best serve your needs. Might be fun to verify the application algorithm and the datasets accuracy.

I can dust off the prototype and put it online somewhere if you want. The app is queryable via SMS (mobile phone) or http (web).

The bulk of the transit data you’re looking for comes in four (loosely standard) GIS shapefiles: Bus Service, Bus Routes, Bus Route Segments, and Bus Stops.

Here’s a map of the current transit service in the seven county metro using the data..

here’s all the bus stops in the data for the downtown area plotted along with functional class roads.

It would be trivial to add the ability to use United States Geological Survey Places and Names so that you could use strings such as Mall of America, HHH terminal, etc to plan your route instead of geeky GIS coordinates.

I kind of grew bored with it, could get interested in it again if the MTC would make available the GPS data from their buses. I assume they have GPS aboard their buses by now or maybe even cooler!?! a sensor network through which the buses move. Would be a problem of interest to me to provide a real-time plan based on the actual traffic conditions. I’ve been wanting to wrestle with the reference implementation of DOMINO for awhile and never had a real data set to work with. I think someone at google was playing with a similar concpet for awhile by plotting manhattan passenger van companies locations.

I could write an adapter I guess to transform the data into the info Google needs to put it into Google’s system if you like their interface without too much problem if the MTC doesn’t want to do anything. Have to see what restrictions they have put on their data. I probably still have contacts in Google labs.. let me know how your meeting goes s4xton. There is seriously NO good reason wtf portland of all places is supported by google and not minneapolis.

To give you a flavor of the information available here is what attributes the Uber Twin Cities Bus Planner(tm) application slices and dices from the bus route segment shapes:

LINE ATTRIBUTES:

SEGID: A unique identifying number for each segment.

LINE_ID: A number identifying the route number associated with the bus and its schedules. Prefaced with an M for Metro Transit operated, and P for Private Provider operated.

DIRECTION: 0, or 1. 0 is for northbound or eastbound, 1 for southbound or westbound.

FROM_NODE: Timepoint, aka Node, where segment begins.

TO_NODE: Timepoint, aka Node, where segment ends.

MILES: Length of the segment in miles.

WKDY_TRIPS: The total number of trips made by this segment during a weekday.

WKDY_FTRIP: The time of the first trip that segment makes on a weekday, in decimal form. This time is the average between the stop times of the two timepoints on either end of the segment.

WKDY_LTRIP: The time of the last trip that segment makes on a weekday, in decimal form. This time is the average between the stop times of the two timepoints on either end of the segment.

WKDY_RNTME: The average daily scheduled running time by route segment during a weekday.

WKDY_MPH: The average daily miles per hour by route segment during a weekday.

AM_Trips: The total number of trips made by this segment from 7:15 AM to 8:15 AM.

Mid_Trips: The total number of trips made by this segment from 9:00 AM to 2:59 PM.

PM_Trips: The total number of trips made by this segment from 4:15 PM to 5:15 PM.

Ev_Trips: The total number of trips made by this segment from 6:30 PM to 9:59 PM.

SAT_TRIPS: The total number of trips made by this segment during a Saturday.

SAT_FTRIP: The time of the first trip that segment makes on a Saturday, in decimal form.

SAT_LTRIP: The time of the last trip that segment makes on a Saturday, in decimal form.

SAT_RNTME: The average daily scheduled running time by route segment during a Saturday.

SAT_MPH: The average daily miles per hour by route segment during a Saturday.

SUN_TRIPS: The total number of trips made by this segment during a Sunday.

SUN_FTRIP: The time of the first trip that segment makes on a Sunday, in decimal form.

SUN_LTRIP: The time of the last trip that segment makes on a Sunday, in decimal form.

SUN_RNTME: The average daily scheduled running time by route segment during a Sunday.

SUN_MPH: The average daily miles per hour by route segment during a Sunday.

LINE_ID_N: A numeric field identifying the route number associated with the route and its schedules.

Italics is bugging me.

Well, that didn’t work.