O’Reilly Radar with a post about Google Transit, pgRouting, OSM and other developments in the world of mass transit data. Unfortunately, Jim didn’t get the complete picture, so Umibot provided an extended comment in the post, appearing below with links for enhanced reading pleasure.

I’m glad you made this post, but a bit disappointed it has such a narrow perspective. I like Andrew Turner lots, but to take him as the definitive source for all things transit-related is a *bit* of a reach.

Urban Mapping has been doing a whole heck of a lot of work in this area, with some pieces announced. We have detailed data and schedule-related info for around 70 public transportation systems (note: link not current!). This is mostly US-focused, but we’re rapidly expanding coverage in Europe.

First response is to data. GTFS has been invaluable in raising awareness, but make no mistake, Google does little of the work in data. With the exception of NYC’s MTA, agencies provide data to Google in the prescribed format. Google collects this data, tests it, then dumps it into their routing engine/index and millions of people can enjoy. There are 70 or so agencies that participate in Google Transit, yet only 10 or so make the data available to anybody else. In fact, an agency cannot make selective disclosure and *must* make it available to all (but compelling one to do this may involve unnecessary time and expense).

Because data is not made available to Google (or anybody else) does not mean data is not available. I spoke about this at the Where2.0 conference several years ago in my talk “How Open Is Open?” It means that companies have to actually do work to get it. Urban Mapping has a developed a massive inventory of spatial, attribute and schedule data, the vast majority of which we source the old fashioned way–on the ground research. Collecting, normalizing and maintaining this base of data is no easy task, especially when data at the detail of a subway entrance is required.

But data is (relatively) useless on its own, so we’ve made a significant investment in the Graphserver project. Now *this* is compelling–an open source, super-fast engine with a small memory footprint that can ingest GTFS or whatever schedules you like. We’ve been testing this engine with customers and have performed multimodal (walking, driving, inter-agency) lickety-split. If you want to build applications, graphserver is *the* place to be (but don’t worry, UMI will also offer hosted solutions).

Finally, a schedule is relatively useless unless a train (or bus, etc…) sticks to depart/arrive times. But they don’t…so updates/alerts/notifications become of paramount importance. Urban Mapping has also developed a method to poll and ingest the 1000s of incidents and associate them with the relevant IDs. This info is pushed out via a feed, so UMI data subscribers can rest assured their data is the freshest it can be.

And there’s much much more going on. The advent of ITS has raised awareness (and federal $$) to upgrade, experiment and partner with industry in novel ways. UMI will be announcing some unique initiatives in the coming months, and others will also continue to push this along.