Redistricting with OpenLayers Part III
And…wait for it….done.
Well, almost done. The tutorial video is still a place holder and will be until Friday. But everything else is done. Complete. Concluded. Fin. Don’t let the door hit you on the way out. It goes “live” sometime in early May (I think). I’ll probably dump all or some of the plans created during testing in short order.
There were lots of changes over the last couple of months. Lots and lots of changes. To give you a taste, now it does Board of County Commissioner and Board of Education districts, and they have different rules. Never has the 80/20 rule been more true: 80% of the app took 20% of the time, and the other 20% of the app drained all the beer out of my fridge.
But today I finished the last two steps that have hung on the bottom of my TODO list since the project started: the redistricting data is available on Google Fusion Tables, and the code is available on Google Code.
The code is open source (MIT), but I wouldn’t call it an open source project. It’s just open code, and that’s a different thing. The code is tailored specifically to Mecklenburg’s data and redistricting rules. It isn’t like the GeoPortal project - you’ll have to get elbow-deep in the code to make it meet a different set of needs. There’s a readme in there that describes at a high level what you’ll have to touch and what the database looks like.
I wanted to open the code for the usual reasons - facilitate collaboration, improve our code, help others in the community. But the big reason for opening the code in this case is trust. The public should be able to trust any system involved in the political process. The only way to do that in any meaningful way is by opening the code.*
*I’m looking at you black-box voting machines.