Building Multichannel Transit Apps with Tropo

This post is the third in a series about building an open source transit data application using GTFS data from the Delaware Transit Corporation.

In the first post, I described how to download the State of Delaware’s transit data and populate a MySQL database with it.

In the previous post, I walked through a process of setting up stored procedures for querying the transit data and setting up a LAMP application environment.

Now we’re ready to write code for our transit app!

Choosing a Platform

One of the most under appreciated developments that has accompanied the increasing amount of government data that has become available in open formats is the vast array of new tools now available for developers to use. I’ve talked about this a lot in the past but it bears repeating – it has never been easier to build sophisticated, multi-channel communication applications than it is now.
The number of options open to developers is truly exciting, but there are some platforms that rise above the rest in terms of ease of use and in what they enable developers to do. For this project, I will use the Tropo WebAPI platform.

The Tropo WebAPI has a number of advantage that will come in handy for our transit app project (and any other projects you’ve got in the works). You can write a Tropo app in one of several popular scripting and web development languages – Ruby, Python, PHP, C# and JavaScript (Node.js). There are libraries available for each language that make it easy to build Tropo apps and to integrate with the Tropo API. (Disclaimer – I’ve worked on several of these libraries.)

In addition, the real magic that Tropo brings to the table is the ability to serve users on multiple communication channels (phone, IM, SMS, Twitter) from a single code base. This is especially important for an application meant to service transit riders. These users may not have the luxury of sitting in front of a desktop computer in order to look up information on a bus route or schedule. They are much more likely to be traveling and using some sort of phone or mobile device. The Tropo WebAPI is perfect for our needs.

Vivek Kundra, the former CIO of the District of Columbia and current CIO of the United States, has described the effort by governments to release data in open formats as “the democratization of data” – these efforts make previously hard to get, or hard to use data available for everyone.

I like to describe platforms like Tropo and the various libraries that are available to use with it as “the democratization of application development” – these tools make building powerful communication apps simple for anyone who understands web development.

Building our Transit App

Before we can build our application, we need to decide what it will do.

For our purposes, this has already been determined by the stored procedures we built in the last post. Our transitdata database has 2 stored procedures – one to return the nearest bus stops to a specific address or location, and one to return the next bus departure times from a specific bus stop.

However, this series of posts is meant to inspire readers to build their own applications – now that you have transit data in a powerful relational database like MySQL you can query it any way you like. In addition, the SQL scripts and steps developed for this series of posts can certainly be used with the data from any other transit agency that uses the GTFS format. There are lots. Use your imagination – build whatever you find useful.

So now that we have some idea of what we want our application to do, we need to select a development language. It will probably come as no surprise that for this example I’m going to use the PHP scripting language and the PHP Library for the Tropo WebAPI. PHP is a good match for Linux, Apache and MySQL – all technologies we used in the previous entries in this series of blog posts.

If you want some more detailed information on building PHP applications that run on the Tropo WebAPI platform, you can review a separate series of blog posts on this issue here.

To get the PHP Library for the Tropo WebAPI, you can download it and unpack on your web server, or simply clone the Github repo.

Once you do that, you can grab the code for our demo application from GitHub as well.

In order to test this application, you’ll need to sign up for a free Tropo account – you can do that here. Once you are signed up, go to the Applications section in your Tropo account and set up a new WebAPI application that points to the location of our PHP script on your web server. You can see more detailed information on setting up a Tropo account here.


Note – You’ll also need an API key from Google Maps for geocoding addresses – get one here. Change the following line in the application to include your Google API key:

define("MAPS_API_KEY", "your-api-key-goes-here");

Once your Tropo account and application are set up, you can add as many different contact methods as you like – your Tropo application is automatically provisioned a Skype number, a SIP number and an iNUM.

To illustrate how our transit app will work, I’ve gone ahead and assigned a Jabber IM name to my app – Add this to your friends/user list in Google chat and you can use the app I’ve set up. Here’s what it looks like in my IM client:


As you can see, my first IM to sends the address of a building in Downtown Wilmington (actually, a building I used to work in). The app responds with the three closest bus stops and the distance (in miles) to each.

I then send the number of the bus stop I am interested in. The app responds with the next three buses to leave that stop, the route served by each and the number of minutes before each departs.

How cools is that!

I could very easily make this application more sophisticated, so that it it delivers content tailored to specific channels (i.e., IM vs. phone) but I want to keep things simple for now.

In the next blog post of this series, we will introduce some additional tools, including Google Maps and the new hotness in cloud telephony – Phono.

Stay tuned!

A ‘Glass Half Full’ View of Government App Contests

An increasing number of people are starting to suggest that the concept of the “app contest” (where governments challenge developers to build civic applications) is getting a bit long in the tooth.

There have been lots of musings lately about the payoff for governments that hold such contests and the long term viability of individual entries developed for these contests. Even Washington DC – the birthplace of the current government app contest craze – seems the be moving beyond the framework it has employed not once, but twice to engage local developers:

“I don’t think we’re going to be running any more Apps for Democracy competitions quite in that way,” says Bryan Sivak, who became the district’s chief technology officer in 2009. Sivak calls Apps for Democracy a “great idea” for getting citizen software developers involved with government, but he also hints that the applications spun up by these contests tend to be more “cool” than useful to the average city resident.

App Contests Abound

This view is starting to crystallize against the backdrop of an ever greater number of app contests being held. At the recent Gov 2.0 Expo in Washington DC, Peter Corbett of iStrategy Labs (who helped launch the first government app contest in DC) gave a presentation that listed several dozen governments around the globe that had recently completed an app contest or were scheduled to soon start one.

And the biggest app contest to date – being sponsored by the State of California – is slated to begin soon. (Two fringe technology companies that you’ve probably never heard of – Google and Microsoft – are set to partner with the Golden State for this 800 pound gorilla of government app contests.)

So if app contests are being used in more and more places, and the size and scope of these contests keeps growing, what’s with all the hand wringing of late?

Lessons Learned from App Contests

My take on app contests is not an unbiased one. I’ve been a competitor in three different app contests (the original Apps for Democracy, the original Apps for America, and the NYC Big Apps competition) and was recognized for my work in them. Outside of contests, I’ve build applications using open government data and APIs for the cities of Toronto and San Francisco, and for the New York State Senate.

Clearly I am a supporter of the concept of the government app contest.

Having said that, though, I do think that those taking a more skeptical view of app contests are asking some important questions. The government app contest has come a long way since Vivek Kundra was in the driver’s seat in the DC technology office. It’s time to start asking how app contests can be improved.

But before we move on to that discussion, it is worth noting the lessons that have been learned over the last two years or so from government app contests.

First, governments and citizens benefit when high value, high quality data sets are released by governments that are in machine readable formats, easily consumed by third party applications. Believe it or not, there is still debate in many places on this point. App contests prove the theory that publishing open government data provides tangible benefits.

Second, app contests prove that it is possible to engage and excite both developers and high level elected officials about open government data. The cause of open government can’t be anything but well served when these two groups are excited about it, and appealing to both successfully in equal measure is usually very challenging.

Third, and maybe most importantly, government app contests provide sort of a “petri dish” for government officials to see how government data might be used. They let governments solicit ideas from the private sector about the different ways that open data can be used in a manner that is low risk and low cost. Some of the proposed uses of government data that emerge from these contests – whether its tweeting a recorded message to your Congressman, or using an IM client to browse campaign finance data – might never be considered by governments but for them running an app contest.

These lessons aside, there are those who contend that the existence of app contest entries that have languished (or even been abandoned altogether) after a contest is over suggests that an app contest didn’t work well (or as well as it should have). I don’t think this is necessarily the case.

Look at it this way; once a government has decided to publish open data sets and enable the development of one single app by an outside developer, the marginal cost of the next app (from the perspective of government) is essentially zero.

Once a data set has been put into a machine readable format and staged for download so that it can be used by a developer or third party, what is the cost of the next download? Or the next 50, or 100? Essentially nothing.

The road to tech startup profitability and success is a long and hard one, and it’s littered with the hollowed out husks of ideas (some very bad, some very good) that for one reason or another just don’t make it.

Should we be overly concerned that the dynamic of government app contest entries is essentially the same as it is for any other sort of technology startup project? Personally, I don’t think so.

Making App Contests Better

I do however, think there are some things that government app contests organizers can do a better job on.

Most notably, government engagement with app developers over the long-term has proved to be somewhat challenging. Gunnar Hellekson of Red Hat has observed the same phenomenon:

“..I would think that one of the desired outcomes [of an app contest] was an ongoing community of developers that are producing and maintaining applications like this — whether it’s for love, money, or fame. It would be a shame to see hard work like this die on the vine because we’ve lost the carrot of a cash prize.”

I don’t think this is an issue with developers necessarily – I know there is still lots of excitement around the data sets that have served as the foundation for app contents that are now over. I think the issue is that governments do not always have a plan for post-contest developer engagement.

Once the prizes are given out, and the award ceremony is over, there are no plans or strategies in place to keep developers engaged over the long haul. I do not believe this is an issue of money – not every developer is looking for a cash prize, and there are some good examples of government agencies (MassDOT and BART among them) who do a pretty good job of keeping developers engaged without contests.

I also think that a greater emphasis could be placed in app contests on developing reusable components (as opposed to user-facing solutions) that can be released as open source software and used by anyone to consume data or interact with a government API. I’m talking specifically about things like open source libraries for interacting with the Open311 API – tools and libraries specifically designed to make it easier to use open government data.

The easier it is to use government data and APIs the more people will do it, and the more development of reusable components as a by product of app contest, the less angst there will be about projects that don’t remain viable long-term. If one of the requirements of entry is the use (or reuse) of common components, even contest entries that fizzle out down the road will have made a tangible contribution to the open data effort.

I think with a few simple changes, app contests can continue to be used as an effective tool by governments to encourage the development of cutting edge applications powered by “democratized” government data.

The Economic Promise of Open Government Data

It’s been a few weeks since I suggested that by embracing open government data, the State of Delaware (and other states and localities) could encourage the development of nimble software companies and spur entrepreneurship.

Since then, it’s been very gratifying to see lots of other people come to the same conclusion:

I particularly like this statement from Jake Brewer of the Sunlight Foundation:

Perhaps the greatest by-product of creating a more transparent, accountable government through freely available open government data, is that in so doing, we will simultaneously create one of the most vast opportunities for new enterprise in recent history.

I couldn’t have said it any better myself…

OpenGov APIs: Interfacing with Open Government

There has been lots of good talk (and a good deal of action) lately around open government APIs at events like Transparency Camp, Where 2.0 and on the Twitters.

So, as a prelude to a talk I’ll be giving at eComm next month, I wanted to write a post surveying the landscape of recent government API developments, and also to describe evolving efforts to construct standards for government APIs.

A Rundown of Recent State and Local API Developments

At Transparency Camp in DC last weekend, Socrata – a firm that hosts open data sets for governments – open sourced their API for accessing and querying public data. The Socrata Open Data API (or SODA) is a specification for running queries against public data sets. Currently, Socrata hosts data sets for the City of Seattle and others – code samples for working with the SODA spec can be found on Github.

The Open311 API recently implemented by the City of San Francisco (and being implemented by others) got some well deserved attention at the recent Where 2.0 conference. Other cities are starting to take note, and some (like Edmonton and Boston) look set to be next in line.

One of the early adopters of government APIs – the NY Senate – recently announced a new release for their OpenLeg API, which includes some important new changes. Today the NY Senate remains one of the few (if not the only) state legislative body to adopt an API to open up access to legislative information and proceedings, but other will hopeful soon follow. (Certainly the work done in Albany by NY Senate CIO Andrew Hoppin and his team has opened the door for work on other government APIs.)

That’s a lot of good stuff in just the last few weeks – I’ve probably missed some stuff, but I’m sure there is more to come in the weeks and months ahead.

Towards API Standards

The work being done on the Open311 API, the OpenMuni Project, and certainly the move by Socrata to open source the SODA spec will have significant implications for the open government data movement.

Standards for open data and APIs will make it easier for developers to build things – an app that works for one municipality can work for others if both adhere to a common standard that the app can run against. But they’ll also make it easier for governments to open up their data – standards will offer governments assurance that the time and effort they expend to maintain and publish data or stand up APIs will provide the most return on investment.

The move towards open data and government API standards is an important one that may influence the long-term success of the open government movement.

What’s Next?

As these standards develop, and as more and more municipalities start to embrace open data, we’ll move closer to the idea of government as a platform.

More and more open data will be published by governments in this country and others. These newly opened data sets may be hosted on infrastructure maintained by governments, or by third parties like Socrata. Enterprising governments in different regions or states may decide to team up and jointly host data that is of interest or value to constituents served by multiple governments or jurisdictions.

The applications that allow citizens to communicate with governments and consume public services will increasingly be built outside of government. (By outside, I mean outside the control of government and the government procurement framework.) Governments will increasingly become the collectors and maintainers of data and information and will focus less on building applications that use such data (or contracting for such applications to be built).

The applications built to consume public data and communicate with government will increasingly be designed as multitenant applications, able to service constituents in multiple jurisdictions that adhere to common data or API standards. They will also be built using more open source components and Web 2.0 technologies.

And (hopefully) the ranks of civic coders will continue to swell, as technologists looking to “scratch their own itch” are empowered to make a difference far beyond their own wants or needs.

All hail the transformative power of standards!