GTFS-Realtime, maybe a little easier

GTFS-Realtime is a an efficient means for interchange of large amounts of data on the state of a public transport network. The combination of its efficiency and implementation result in a product that is difficult to understand for newcomers. This is made even worse by the fact that the documentation is intermixed with code.

This repository presents the same information (along with several extensions) as hypertext, which may be easier to understand. See that documentation here.

What you measure and what you seek to control

An excellent parable on the goals to set when looking to the future. In the coming years, this story should be on the minds of anyone working in the autonomous vehicle space.

Britain was set to dominate the jet age. In 1952, the de Havillands Comet began commercial service, triumphantly connecting London with the farthest reaches of the Empire. The jet plane was years ahead of any competitor, gorgeous to look at, and set new standards for comfort and quiet in the air. Then things went horribly wrong.

In 1953 a Comet fell out of the sky, and the crash was attributed to bad weather and pilot error. …In 1954, a second Comet fell out of clear skies near Rome. The fleet was grounded for two months while repairs were made. Flights then resumed with the declaration, ‘Although no definite reason for the accident has been established, modifications are being embodied to cover every possibility that imagination has suggested as a likely cause of the disaster. When these modifications are completed and have been satisfactorily flight tested, the Board sees no reason why passenger services should not be resumed.’ Four days after these words were written, a third Comet fell into the sea out of clear skies near Naples, and the fleet was grounded again indefinitely.
Continue reading “What you measure and what you seek to control”

Rant: Why the Age of a Technology Doesn’t Matter.

There have been a number of mentions on the Internets recently that the history of a technology has some impact on how that technology serves a need. But does it? I argue that linking the age or history of a technology with its usefullness is a fallacy. I’ll reference the awesome Your Logical Fallacy Is when calling out the problems in this argument.

I was first rankled by an article in Dissent on Bus Rapid Transit, which uses the Genetic logical fallacy to suggest that BRT benefits the petroleum/asphault industries, has been promoted by them, and is therefore bad. Jarrett Walker has a good response piece, which concludes:

The mixed motives that underlie BRT advocacy don’t tell us anything about where BRT makes sense, any more than the mixed motives behind rail advocacy do.

Soon after, TransitCenter made a blog post that mentioned the following:

New York’s MTA, the largest transit agency in the country, relies on fare payment technology invented in the 1960s.

There are a fair number of problems with the Metrocard system, and I’ll reference those at the tail of this post. But the fare payment technology invented in the 1960s is not the whole technology. The referenced technology (the magnetic stripe) is only a part of the system. This is a logical fallacy known as Composition/Division ( Truth be told, there are other technologies used in the Metrocard system that have been developed in every decade since– even the current one!

My greatest frustration with this particular claim is that the “new” technology that would replace the magnetic stripe, “Ticketless,” is itself more than a decade old. I first saw it in Italy in 2005.

“… You can receive a free SMS on your phone with the receipt of the transaction. Once aboard the train, it is enough to give the received code to the crew…”

You might say, “SMS? But now we have apps!” Well, in 2008, Trenitalia released an App for mobile tickets

So, the next generation of technology to be deployed is a decade old… oh noes!

Not to be outdone, this quote from New York’s new Streetcar Czar raised the same ire.

“The subway was a 20th-century technology. Streetcars are a 21st-century technology, which is why all the fastest-growing cities in Asia and the Middle East are all looking at them.”

The glaring problem with that is that electrically powered streetcars running on the street actually predate the Subway by a decade. Oh, and both Streetcars and Subways both use steel wheels over steel rails, a combination developed in the 1860s.

The real questions to ask regarding technology’s continued usefulness:
1. Is it easily maintained?
2. Does it actually serve the needs placed upon it?

Or, as Jeff Atwood ( put it:

Don’t feel inadequate if you aren’t lining your nest with the shiniest, newest things possible. Who cares what technology you use, as long as it works, and both you and your users are happy with it?

For the Metrocard, the former is definitely the case– crucial components of the system are tied to not-easily-replaceable equipment. A strong case can be made for the latter, as it does place a limit on capacity on buses and at crowded subway stations.

Digital Audio on Analog Visual Information

London Reconnections, a London-based magazine and site, has a Podcast, the second episode of which is on Transit Maps. I know that audio on a the impact of a strictly visual medium sounds odd, but it’s worth a listen. To hear it, check this link or go below the fold.

There is no ISO standard for transit maps.

Continue reading “Digital Audio on Analog Visual Information”

Why TCIP sucks (and what can be done to fix it)

In the past few weeks, I’ve gotten a number of questions from a variety of sources about TCIP. Transit Communication Interface Profiles (TCIP) is ‘the FTA and APTA’s decades-old project that includes specifications for all manner of technology systems in the transit industry.’

If you want to stop reading now, just take my word that it’s not that great and rarely used. If you’re interested in learning why, and what I think should be done about it, read on.

Continue reading “Why TCIP sucks (and what can be done to fix it)”