I woke up at 5 this morning to the news that the two subway lines in my neighborhood were still not running, more than 36 hours after the "Boxing Day Blizzard" had begun in New York City. The question then was, well, what is running?
The awful MTA site wasn't much help, especially with regard to the buses. It offered cryptic and non-specific messages like:
Due to ongoing snow related conditions, all MTA bus express services are running with system wide delays. There is no limited stop bus service in all boroughs.
There was no indication of how any one specific bus route was faring.
My neighborhood's Yahoo group was abuzz with conversations about which trains and buses were and weren't running, but the information was unorganized and freeform, because it was happening over email.
And while the MTA probably had a good internal grasp of which lines were having issues, they were not doing a good job of disseminating that information. Ideally their website should have been providing real-time geo-located incident reports so that any commuter could look at a map and quickly determine what the best route was to wherever they had to go. Even more ideal would have been, as my friend Michael McWatters suggested, a trip planner that could re-route you away from the suspended lines and to the freely-moving ones. But, at the very least, even just a little bit more detail would've been nice.
So this morning I thought to myself, this is exactly what crowdsourcing is good at. And I remembered hearing about a mapping tool called Ushahidi, which was put to good use during the crisis that followed the Haitian earthquake back in January. Indeed crisis mapping is a very powerful idea, and Ushahidi is leading the charge with their open source application that's free to download and deploy, as well as with Crowdmap, their hosted version of Ushahidi that is also, surprisingly, free.
In the span of about an hour, I put up a site up using Crowdmap called mtadelays.crowdmap.com. I entered all the subway service changes from the MTA site, and told a few people about it. It got a little bit of Twitter buzz, but only one person submitted a report other than me. I think I was a little late to the game (I should've set it up on Sunday), but, it turns out, the tool also has a few shortcomings specific to this particular use case.
First, the tool was built for incidents whose geography is best described as a point (a latitude/longitude coordinate pair). But transit delays are best described as lines. When service is disrupted, there is a starting coordinate and ending coordinate for that event. Ushahidi had no good way of representing this, so I ended up just putting in two points for every incident. It was kind of a hack, and it also was misleading--the issue itself spanned an entire length of subway or bus line, not just the endpoints. I imagine that anyone who might've submitted a report would have run into the same issue, and I also suspect there are some incidents that are best described by a polygon instead of a point or a line.
Similar to the incidents being specified by a point in geographical space rather than a line, they are also represented by points in time rather than durations. Transit delays have a finite duration (even if the duration isn't known up front). I would love if you could set incidents to expire after a certain amount of time (24 hours maybe?) rather than requiring an admin to go back in to the system and either edit or delete the incident. The overhead can be prohibitive.
Another issue is that it's somewhat difficult to submit reports. You have to visit the website and submit a form. Actually that's not really true--Ushahidi supports reporting via Twitter hashtags, SMS, or mobile apps (though there isn't an iOS app yet). These are decent options, but you don't really get the good geo-location data this way. It's probably only a matter of time before the mobile options for Ushahidi reporting get really good, but for now it's a bit clunky.
Despite these issues, though, it's really interesting to see how far this kind of technology has come. It's also interesting to think about how many different mature platforms Ushahidi is built on: there's Linux, Apache, MySQL, PHP, the Google Maps API, the Twitter API, SMS, Email, RSS, probably many others. It's pretty staggering when you think about it, and all I really had to do to set it up was press a "submit" button on a web page.
Even though the Haiti earthquake was a big moment in the spotlight for Ushahidi, I think we have yet to hear the last of them. They are building an amazing tool and I'm excited to see how it can evolve and continue to help communities deal with local crises and civic emergencies.