I won't comment on the legalities of copyright (IANAL) or the tactics MTA is using (they may have shot themselves in the foot), but there are very good reasons for MTA to want to keep control of their schedule information and limit third-party distribution.

Yes, third parties can often get information out to the public in a faster and more accessible manner than transportation companies, but there's a right way and a wrong way to do it. I should know--I was responsible for the project that first put Amtrak schedules online, back in the Gopher era and then in the early years of the WWW. We also did online schedules for several commuter rail systems, including MTA's, in those early years.

Most important _is_ ensuring that the data is maintained and kept up to date. Having outdated schedules up for download is worse than having no schedules at all. This is not a matter of 'boo hoo, you missed the train by one minute because you were relying on your iPhone--be early next time' as one commenter put it: sometimes the changes can be pretty substantial, especially as a result of construction projects. And yes, the company gets blamed even when the fault is someone else's.

Second, it is _not_ helpful to undercut the system's own communications department. They may not be as fast as you in putting out an app, but they may have something much more useful in process, such as an app that can link to a dispatching database and provide real-time departure information (see NJ Transit's new Departure Vision beta, for example). With all due respect to your programming skill and interface design ideas, users are usually better off with information direct from the source.

Finally, put yourself in the shoes of the system. When we were distributing a downloadable version of Amtrak's timetable, we had a pretty difficult time trying to convince well-meaning individuals not to repost them on their own boards, and getting the ones who had done so to take down outdated editions. They may be dealing with other people who want to do the same thing as you, and all of this at the same time as they're trying to add new features to the official sites.

If you want to do something like this, either as a public service or for profit, the right thing to do is to communicate with the system and get their permission first. Ranting on Slashdot about copyright, government bureaucracies or about the lousy on-time performance of the system's operating side (actually, Metro-North's on-time performance is exemplary--best in the nation) is not constructive. Find out what is in the pipeline, and if you still think there's a need for the kind of information you can provide or the mechanism for delivering it, make the case to the system's customer service people, and you'll probably get a green light and a good deal of cooperation.

Matt Mitchell
Delaware Valley Association of Rail Passengers
www.dvarp.org

Rather than beating on the 'information good, copyright bad' dead equine again, let's look at the reasons a transit agency might want to control timetable information, and how a well-meaning information provider might actually make the situation worse.

I should know--I developed and distributed the first online timetables for Amtrak, back in the days when Gopher was state of the art.

The principle you've got to understand is that in this context, wrong information is _worse_ than no information. If timetables change, and the website or app distributing the unofficial timetables isn't updated promptly, some of the customers using those timetables are gonna miss the train. Rightly or wrongly, they blame the railroad.

So any online timetable project has to be a close collaboration between the railroad and the developer, and the developer has to be extremely reliable about pushing out updates whenever timetables change: not only the periodic changes, but unexpected ones as well.

So how do you make a project like this successful? Well the first step is asking permission and working out an update plan--not publishing the app.

In our case, we spoke to management people at Amtrak (and a number of commuter railroads) before launching our projects. We explained what we were doing, how the information would be distributed, who would benefit, who would be responsible for updates, and stressed that the project would only go forward with the permission of the system. Sometimes we got a quick OK, other times it had to go through channels and took months. A few systems told us "no" (in some cases they had their own projects in the works) and we respected their decisions. But because we were a well-established organization that understood the industry and the challenges of the project, most of the responses were positive.

We lined up a string of volunteers to transcribe information, created a standard format, and soon had our first package ready. Many people wanted to help redistribute the files, but we strongly discouraged that because we would have little control over updates and people would have no idea whose schedule site was correct. Eventually we took on three other partners, all of whom were considerably involved in publishing transportation information and knew the importance of removing outdated information immediately.

A few years later, Amtrak launched its own web site. Schedules were available, but the interface was awful and you could only get point to point schedules rather than the entire timetable for a particular train. We discussed the situation with our liaison at Amtrak, who initially wanted us to close our project; and after we pointed out the way the official site was failing to meet some customers' needs, they agreed we should continue. We did so, with the official and unofficial sites working in parallel for a coupla years, and then Amtrak upgraded their site and put in the functionality it was missing. At that point, we posted one more edition of our unofficial timetables, gave notice to the users that they should migrate to the official site, and shut it down six months later.

The same principles still apply today. Transit information is perishable, information must be kept current in order to be beneficial, and it's easy for well-meaning supporters to actually make things worse. The only difference is the amount of interconnectivity and availability of real-time information.

Railroads now have real-time dispatching information available--if and when we can get that to the user, it's a whole lot more useful than static timetables like the Transit Sydney people are working on

And in fact, most of those railroads _are_ developing apps to get that information to the customer, though they aren't always as fast to get on to new technology such as iPhone apps--they have limited resources and must target them to the largest user bases, which in this case means telephone (see Amtrak's "Julie" for example) and web (see www.vre.org for a good example). Customized messaging (see NJ Transit's "My Transit") is also growing.

The ideal situation (which is something we are actually making progress towards) is to provide standardized 'hooks' in the real time information (like the geographic information that can be used by Google Maps). Then people can develop apps that reach in and get information from the operator's platform-independent database in real time. Because the apps don't themselves contain the information, there's no problem with their being outdated and, incidentally, no copyright issues.

But an iPhone app containing CityRail schedules is not only a potential problem for CityRail--it's behind the times.

Matt Mitchell
Delaware Valley Association of Rail Passengers
www.dvarp.org

Reminds me of the reskinned arcade video game "Tapper." They took out the Budweiser logos, renamed it "Root Beer Tapper," and made it into a fun game I wouldn't have any problem letting my elementary school-age children play. In fact, I might dig up my copy of MAME and let 'em play it!

The chief obstacle to a nationwide network of high-speed trains isn't technical, it's the capacity of our national rail infrastructure. Most main line intercity rail routes (owned by the six major US freight railroads) are at or near capacity. While you could buy 90 or even 120 mph diesel passenger trains more or less off-the-shelf, you wouldn't have any place to run them. If you try to intermix 90 mph passenger trains with 40-60 mph freight trains, you need a lot more track capacity than you have now. Why is that the case when railroad tracks don't look as busy as interstate highways? Because switches, sidings, and other places where the passenger train can pass freight trains are pretty far apart. One train passing another, even on a two-track main with centralized traffic control, ties up a lot of railroad, forcing traffic coming the other way to stop and wait. One can think of the railroads as a series of one-lane highways linked together. Furthermore, a lot of main lines are single track and not double track: single track has much less than half the capacity of double track. Now the economics are such that the railroads only build and maintain the capacity necessary to handle their primary freight operations. If the railroads had capacity to spare, they'd have to pay taxes and maintenance expenses on it, as well as pay the cost of capital needed to build it (bond interest and/or stock dividends). Stockholders rightly won't stand for their company spending money on assets that aren't earning a competitive return. As long as railroads are built with private capital, taxed on their land value and improvements, and regulated strictly; while highways are built with public capital, tax-exempt, and regulated loosely, the full potential and efficiency of rail transportation will not be realized. Matthew Mitchell Delaware Valley Association of Rail Passengers Philadelphia www.dvarp.org