Seven years ago Azavea began working with the Public Mapping Project to create DistrictBuilder, an open source, web software tool that would enable people to draw their own legislative district plans. We worked with leading redistricting experts: Michael McDonald (Associate Professor at the University of Florida and head of the Elections Project) and Micah Altman (Director of Research and Head Scientist for the Program on Information Science for the MIT Libraries). The usual redistricting process in many states is done with commercial software (most commonly Maptitude), behind closed doors, and with no public input. DistrictBuilder was designed as an alternative to the usual process. It aimed to provide an affordable, easy-to-use redistricting tool that would enable governments, legislatures, advocacy groups, and members of the public to create plans in an open and collaborative way. Further, because the source code was open, there was an element of transparency that is frequently lacking in the legislative redistricting process.

The software was used successfully in a number of jurisdictions. Not only could it be used to draw plans, it included features for communities to run competitions, publish plans for review, and calculate scores for plans based on a broad range of criteria. The software was used to run a competition for college students in Virginia and a public competition in Philadelphia, called FixPhillyDistricts. The Joyce Foundation supported implementations in several Midwestern states, and in Minneapolis, district plans by two local communities – representing Latino and Somali groups, respectively – ended up being incorporated into the revised City Council plans.

Following the last decennial census, we continued to do some additional work on DistrictBuilder, adding support for non-English languages and other features that would make the software more useful both in the United States and internationally.

But for the past four years, we haven’t touched the software. The original version and many subsequent improvements had combined funding from the Alfred P. Sloan Foundation and others with pro bono work by Azavea. But we had no funding to support ongoing development. We continued to host the web site and the FixPhillyDistricts application, but we didn’t do any new work. During this time many things have changed, and we believe we can build a better DistrictBuilder today than we could in 2010. Here’s what we are thinking about:

Re-architect the Software

Two of the main barriers to wider use of DistrictBuilder have been cost and complexity, and we think there are some technology-related ways to overcome this. First, the software has aged (yes, software ages, and it can quickly go from youth to decrepitude in three or four years); all of the underlying components – PostGIS, OpenLayers, GeoServer, Django – have released several versions since then, and the ones we used are no longer supported. This accumulation of out-of-date software components is sometimes known as “technical debt“, and we need to pay down this technical debt. Second, the underlying software components are complex and this means that implementing the system requires some fairly advanced systems administration skills (and complexity = cost, in this context). I don’t think we can make the software architecture simpler, but I think we could re-engineer it to make it easier to configure and install for any given jurisdiction and thereby reduce cost and reduce time to configure the system. Since our original implementation, Amazon Web Services, Google Compute, and Azure have also added a range of services that would enable DistrictBuilder to be constructed in such a way that hundreds or even thousands of separate jurisdictions could operate on a partially shared infrastructure. Each prospective organization would be able to configure and operate an instance online (without an engineer), rather than operating their own infrastructure and having the configure the system by hand. We think this step would be difficult but would significantly reduce the cost and complexity.

Automated Data Provisioning

Once DistrictBuilder was configured and running, data acquisition, formatting, uploading, and troubleshooting were a another area of substantial complexity, and I think we could make progress on this front as well. Since the original DistrictBuilder was developed, the Census Bureau has made much of its most useful data available through a machine-readable APIs that enable specific data sets to be accessed on-the-fly. These APIs should enable us to build automated data provisioning tools that would ask the user a series of questions related to the level of government, demographic variables they want to consider, and then reach out to the Census APIs to extract that data and load it without any technical skills. This would not solve all of the data provisioning challenges (municipal/county jurisdictions would need to be able to upload their local council boundaries, and there would still need to be a way to load non-demographic data), but it would enable someone to get a basic instance of DistrictBuilder up and running without a lot of data wrangling.

Re-work the UX Design

We did a good, iterative, user-centric design process in 2010, but it’s been seven years, and we think the whole user experience (UX) needs to be overhauled.

Support Other Kinds of Districts

We designed DistrictBuilder to support legislative redistricting, but there are obvious applications outside that domain. In particular, we’ve seen interest in redistricting for school district, police districts, election precincts, and other types of local service districts. In addition, we’ve had some interest from private companies interested in organizing sales territories. I think it would be possible to make the setup and configuration process somewhat more generic to support these other applications. I don’t think it would be a big money-maker, but it would enable the potential for a revenue stream that would support ongoing development and support so that we aren’t forced into a hiatus again after the census-driven legislative redistricting is complete.

Features Wishlist

There are always new features that people want to see. Here are a few suggested by our partners at the Public Mapping Project as well as others we’ve heard over the past few years:

• Add support for “floterial districts” – Floaterial districts are districts include multiple communities that already have district representation, a sort of “super-district”. A 2006 constitutional amendment in New Hampshire allows for floterial districts, and they are also used in Idaho, Tennessee, and Texas for state office as well as some cities.
• Embeddable maps – DistrictBuilder already supports sharing maps; this enhancement would extend this feature to support embedding a shared map in other web pages and blogs.
• User testing and redesign of the COI feature – DistrictBuilder supports developing and scoring maps based on “communities of interest”. However, this feature did not receive a lot of usage in 2011 redistricting round, and we think it could be improved with better testing.
• Support account creation and login via OpenID and Oauth
• Extend the permissions model and workflow to support group editing of a single plan
• Enable comparison of multiple maps
  • Side-by-side display of two maps
  • Show polygonal “differences” between two proposed maps
  • Display scoring metrics for each of several maps
• Provide a REST API with access to completed maps and other public data
• Metes and Bounds report – generate a “metes and bounds” report that describes a district using the language often required for the formal legislative bill defining the district.

This is a preliminary wish list, and I’m confident that lots of other ideas will arise once we get started.

What do you think? We’ve had a lot of fresh interest in DistrictBuilder over the past six months. We didn’t get started on the original version until 2010 and having something ready in time for the first states was a huge rush. We’d like to get started much earlier this time around, but it’s going to take funding, so we are now working with our partners to talk to potential funders. Do you want to help support the next version of DistrictBuilder? Drop me a line.