Category: Uncategorized

18F, the US Government’s digital renegades, posted a blog post strongly arguing that government agencies don’t need to develop apps. Hint: the web is much better at getting something out the door.

511.org in the (California) Bay Area provides GTFS and GTFS-Realtime for many of the agencies in the region, including VTA, Caltrain, SF Muni, AC Transit, and a whole lot more.

The docs are available here, but I find the PDF a little dense (and there are some peculiarities), so this is a cheat sheet.

First you need a token sent to your email address.

Continue reading “A cheat sheet for Bay Area 511 GTFS-rt feeds.”

Aaron Antrim has a long and detailed piece about the history of GTFS (and some on other standards that do not see public use). It is well worth a read.

Sean Barbeau has a great post on the shortcomings of GTFS-rt 1.0 and how they have been improved in the recently ratified version 2.0. It is here and well worth the read.

Mapzen has recently released Transitflow, a set of tools for visualizing transit vehicles via their scheduled locations. See below the fold to watch the magic dots.

Continue reading “Transitflow — Couldn’t have done it better”

You know that annoying problem when three buses arrive at once? It’s really hard to solve.

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.

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”

Below the fold, an excellent video from the London Transport museum on how their rollsigns are still produced, mostly by hand, using a process that, with the exception of Photoshop and a plotter, has not changed in decades.
Continue reading “More London Analog Data”

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 (https://yourlogicalfallacyis.com/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.

http://web.archive.org/web/20051206033411/http://www.trenitalia.com/it/orari_biglietti/ticketless/index.html

“… 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 (https://blog.codinghorror.com/the-magpie-developer/) 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.