Shutting Down a Civic Project

It’s never easy to shut down a civic project or app, but sometimes its the right thing to do.

And so it is with a project I started at the original Apps for SEPTA event in Philadelphia during the Fall of 2011. Effective last Friday, SEPTAlking stopped accepting phone calls and text messages for the next available SEPTA regional rail trains.

I’m proud of this little application that I first threw together during an insanely crazy weekend while helping to manage a civic hacking event I organized with my good friends at Devnuts. This application went on to be featured in a groundbreaking SEPTA marketing campaign that saw the agency promote apps developed by outside hackers to regional rail riders. Awesome stuff.

The application was used almost 20,000 times since late December 2012 by transit riders looking for the next available train at regional rails stations in and around the City of Philadelphia. This level of usage was made possible by SEPTA’s promotion of the app and also by the generous suport of my friends and former colleagues at Voxeo Labs.

The code for the app is open source, and I hope it inspires others as they work on transit apps and civic projects. Philadelphia is a city where many citizens face challenges to traditional Internet access and I think it’s important that this influences how we build civic apps. The apps we build must be able to serve the widest community of citizens possible.

Most of all, I’m immensely proud to be a part of the civic hacking community in the City of Philadelphia – a community that has grown by leaps and bounds because of events like Apps for SEPTA.

Not the first civic app I’ve shut down, and it certainly won’t be the last. Nevertheless, more hacking to come.

An SMS-Enabled Polling Locator

This is a great weekend for civic hacking.

Daylight Savings Time has given us an extra hour, advances in telephony application development have made it dead simple to build text messaging applications and Google has given us the Civic Information API.

With an election on Tuesday, I wanted to build a quick application that demonstrated the ease with which SMS apps can be built and the power of Google’s API.

The address of a polling place is both valuable and succinct – it’s the ideal kind of information to deliver through multiple communication channels. Text messaging (SMS) is a fairly ubiquitous communication channel, and in some cities – like Philadelphia – it’s an important way to engage with citizens that may face barriers to digital access.

The screencast above demonstrates how to use the script I developed using the Google Civic Information API and the Tropo telephony platform.

There are many ways to do this, and there are a large number of text messaging platforms and services to choose from, so if you want to use your extra hour this weekend to help people find their polling location pick the one you like best and get cracking.

It’s never been easier to build useful communication and messaging apps – in fact it’s getting easier every day. And with the richness of information available through APIs like Google’s Civic Information API, it’s never been easier to build an app that will help people get to their polling location.

Election day is just around the corner. Use your extra hour this weekend wisely…

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!