tymshft

Google Transit will NEVER be enough? Maybe not.

I recently needed to research a particular mass transit problem. Because of the large size of southern California, I was required to consult three different transit agency websites: Metrolink (a local commuter train service), the Orange County Transportation Authority, and Omnitrans (the mass transit provider for western San Bernardino County).

Well, actually I started with Google Maps. Google Maps incorporates a service called Google Transit that attempts to calculate transit connections that use multiple agencies. However, at present Google Transit is not perfect, so I have to go to the underlying transit agency web sites to refine things.

One of the services that I mentioned, Omnitrans, recently tweeted a link to a post entitled “guest post: nate wessel on why google transit will never be enough for small to medium-sized systems.” Omnitrans tweeted this because it is a medium-sized system. Nate Wessel wrote it because he lives in a city (Cincinnati) served by a medium-sized system.

My first reaction, when looking at the post title, was that Wessel was a little strong. As Romeo Void reminds us, “Never say never.” Certainly, I thought, improved algorithms and additional information on Google’s end will allow it to improve the information that it provides.

So I started to read Wessel’s post to see how wrong he was. (Read to the end of the post for my conclusion.)

Wessel started with an explanation of the two things that a traditionally printed map provides to the reader:

[M]aps show us what’s possible in the physical world. They tell us that Spain is a place in Europe, that Queens is connected to Manhattan by subways and bridges, and that it’s not similarly connected to Britain. We can’t think of taking transit until we know what transit does and doesn’t.

The other critical thing maps (and some other media) do is provide us with answers to specific questions. These might be:
• “Which line can I take to Queens?”
• “Are there coffee shops within walking distance of my current location?”
• “Exactly how much will the bus cost?”

Wessel then asserted that Google Transit is very good at answering the second question (answer specifically), but is terrible at answering the first (inform broadly). He explains:

…Google Transit suggests we take the #19 northward, but says nothing of the invisible #17 that runs parallel to it at more than twice the frequency. You can easily imagine someone who’s once looked up their route on Google Transit regularly letting a #17 pass by while they wait for a #19 and complain about headways. Similar situations must happen a thousand times a day.

Exploring a transit system with Google Transit is like blind men trying to understand an elephant by touch. This part is thick, this part is bumpy, we don’t know how any of the parts attach to each other, and the whole thing is constantly, inexplicably moving.

Once I read this, I absolutely knew that Wessel was dead wrong. As I mentioned above, algorithms can take care of suggesting possible alternatives, and Google is perfectly capable of layering information about other routes so that I can compare the alternatives in Google Transit itself.

But once again, I figured that I’d hear Wessel out.

It turns out that one of Wessel’s talents is his ability to create a thoughtfully hand-rendered transit map. The word “thoughtfully” is important here. Rather than throwing a bunch of information into Google’s engine and displaying it, Wessel asserts that there is an additional requirement to “thoughtfully” abstract the information into something meaningful to the reader.

The example that Wessel provided was of Washington DC’s Metro system – a system that I used for several years. If you go to the Metro “maps” page, you can see two views of the Metro system. One of the views is called the “Google Map” view.

The other view is called the “Rail Map” view.

As it turns out, the map used by the majority of Metro riders is the latter view, the Rail Map view. This view is inaccurate, is not to scale, and is missing the information that you would find in a regular map. But the “rail map” serves as an easy-to-understand abstraction of the rail system, providing the exact information that a rider needs.

For example, let’s say that you want to get from Franconia-Springfield (in the lower left corner of the map) to Shady Grove (in the upper left). If you look at the “Google Map,” you can’t even find the stops. But if you look at the “Rail Map,” you can easily see that there are several different ways to get between the two points. I won’t go into the details, but anyone who has lived in the Washington area can recite the options to you – and tell you which option is the best around 5:45 pm on a Friday.

Well, now I knew that Wessel was wrong. Google could incorporate those abstracted maps into Google Transit.

But then Wessel said something that stopped me in my…um, tracks.

It seems like most big American cities put these questions, at least so far as transit is concerned, largely to rest decades ago with their famous metro maps but that many small and mid-sized cities, particularly those that primarily use buses, provide little if any coherent, holistic map of how their system operates. They often seem content with either no system maps at all or only topographically accurate maps that de-emphasise and confuse the areas that can benefit from transit the most: those that are dense and well served by multiple lines.

In essence, Google cannot incorporate information into its data-crunching machine if the data itself doesn’t exist. For a place such as western San Bernardino County, a nice neat abstraction of the Omnitrans system does not exist. (Whether such an abstraction could be created for a bus system, which is more complex than a rail system, is open to question.) And Google isn’t going to create such an abstraction. And Nate Wessel can’t run around everywhere and create them for every single transit system in the entire world.

So I was forced to agree with Nate Wessel. Google Transit will NEVER (or, as Taylor Swift would put it, never ever ever) be enough for small to medium sized systems.

Is he wrong? Am I wrong?