Author: Tony

This paper goes into detail about the most common arrival prediction algorithm– using the published schedule. This algorithm is not perfect, but it is a substantial improvement on the schedule alone:

This scheme was found to systematically underestimate the remaining waiting time by 6.2{8472c33f139a04d7902a1525cca677786370fef6b48c8e38f5cec86fa878d628} on average. The provision of real-time information yields a waiting time estimate that is more than twice closer to the actual waiting times than the timetable is. This difference in waiting time expectations is equivalent to 30{8472c33f139a04d7902a1525cca677786370fef6b48c8e38f5cec86fa878d628} of the average waiting time.

Oded Cats* & Gerasimos Loutos. Real-Time Bus Arrival Information System: An Empirical Evaluation. Journal of Intelligent Transportation Systems, 2015

This is the second in a series of posts on what I’m calling the Global ITS Architecture. The first gave background on the National ITS Architecture.

Below the fold, edited notes from a talk I gave last year on “Have Open Standards Delivered ITS Architectures that Matter?” Hint: I argue Yes.

Note that I engage in some of the lies of storytelling, duly noted.

I’m going to take a strong stand on this question and make three arguments on my way to an answer:

1. The evolution of ITS has seen the scale of information distribution grow over time.
2. The private sector has really driven the state of the art for passenger information.
3. In this space, the work put into National ITS standards have not had good ROIs.

First, a bit of history. Electronic passenger information is not something of the 21st century. The first subway in America, Boston, had electronic passenger information signs in the 1890s.

But both the provision and reach of information was severely limited. Driving this was someone behind a switchboard.

Fast forward to the end of the 20th century. We have systems that make passenger information available at a city-wide scale. Here is one such sign.

While the data were available systemwide, in the beginning it was only available to the agency and through this manufacturer’s product(( Lie of omission: HSL in Helsinki is an awesome data provider)). The only reason we know what the interface for these signs looks like is because of a Finnish hacker. She was playing around with a spectrum analyzer, found something interesting and decided to take a look.

Growing Pains

At the dawn of the 21st century, after deploying a host of single vendor solutions, the industry began to understand the downsides of end-to-end functionality from one vendor. from a panel of experts on passenger information and, after a standard standards-development process, TCIP was born, good, bad, and ugly.

• Good: Standards Process
• Bad:
  • No major implementations
  • Backward looking: Year 2000 technology (Not thought through for web / mobile clients)
• Ugly: Documentation “cumbersome at best, impossible at worst”

Because of these issues, and no one has used the Passenger Information messages at large scale. No one took this standard as an example and said, “hey I want to build a system with that.”

Contrast this with the NTCIP standards, where the documentation is succinct and accessible.

Meanwhile…

The tech sector has taken a separate track.

In 2006 Google finalized the first version of GTFS. This was part of moving from a search company, to a data company.
Rather than trying to understand national ITS diagram,  they addressed this as a tech company would, in an agile fashion with a minimum viable product first. They worked with one agency, TriMet in Portland, to iterate a working product before putting it out.
Put simply, GTFS proved that without a flagship project, a standard is worthless.

Google saw world of opportunities for data, and they have driven the market ever since. But will they continue to in the future?

I’ll address that in in part 2.

This is background material for a subsequent post.

The [US] National ITS Architecture provides a common framework for planning, defining, and integrating intelligent transportation systems. It is a mature product that reflects the contributions of a broad cross-section of the ITS community (transportation practitioners, systems engineers, system developers, technology specialists, consultants, etc.).

The architecture defines:

• The functions (e.g., gather traffic information or request a route) that are required for ITS
• The physical entities or subsystems where these functions reside (e.g., the field or the vehicle).
• The information flows and data flows that connect these functions and physical subsystems together into an integrated system.

(Iteris)

Basically, the National ITS architecture brings taxonomy to Intelligent Transportation Systems, all through the confusing lens of the typical American engineer (c.f. the usage of the ackronym ISP). It looks like this:

The ne-plus ultra of the National ITS Architecture is the connected vehicle. Below the fold, a shiny video.

Personally, I remain cynical of the next big thing.

For more on the National ITS Architecture (and a reminder that slides make bad documents), see here. If you need bedtime material, there is a ~300 page theory of operation from USDOT.

Below the fold, an excellent talk on applying lessons from studying systems failures. A good introduction for those who don’t know that there is a study of systems!

Following my previous post, online journalism outfit Quartz recently posted a Guide on Bad Data, organized into the following parts:

• Issues that your source should solve
• Issues that you should solve
• Issues a third-party expert should help you solve
• Issues a programmer should help you solve

It is well worth a read. Also, if you have any comments or additions, it is open for your updates!

A while ago, I came across Daniel Burnham’s Plan for San Francisco, drawn up in 1905. It’s a beautiful piece of beaux-arts draftsmanship and City Beautiful idealism. If realized, San Francisco would be a remarkedly different place, emphasizing City Beautiful’s “urban design practices for American cities: straight streets, symmetrical buildings, and harmonious building facades framing public sculpture or monuments. City Beautiful was in part a reaction against the evils of the 19th century city, emphasizing beauty and a luxurious public realm as opposed to a city that merely served the needs of industry.”

Unfortunately, 1906 was an inauspicious year for the city that would redirect energy away from its implimentation.

Read more from Urbanist Gabe Metcalf (from whom I lifted the earlier quote), or the curious aesthetes at Curbed

Below the fold, a link to order my retouched version of the map.
Continue reading “Burnham’s Plan for SF, 1905”

The TED Radio Hour put out a great show a couple months ago on Open Source. I had let it sit for a while, given that a lot of discussions of tech aimed at a wide audience rely on simplistic explanations that easily fall apart with a little bit of background. This one does not.

Below the fold, two segments from Tim Berners-Lee (the progenitor of http://www…) and Clay Shirky (of Cognitive Surplus) that are worth sharing.

Continue reading “Open Source, for your Grandmother (or your Boss)”