Greetings friends. This is the March 2014 update for the Georgia Open Data Project.
For those of you who are unaware, last summer I started the ball rolling on this project, called GAODP for short, which is engineered to open up data about the state and local governments in the State of Georgia. Underfunded technology departments and a need to focus on more pressing matters of government often mean that data about the state and its municipalities is very difficult to get your hands on in a form fit for data analysis. So we took matters into our own hands. Earlier this year we launched an API for the Georgia General Assembly. News flash: we’re not stopping there.
This month’s updates includes a few interesting tidbits. In summary, this update includes:
- Announcement of our first user-facing website: Scorecard.
- Announcement of our new logo!
- General news about GAODP.
- A short anecdote about why what we’re doing matters.
Feel free to skip ahead if any section starts to bore you. You won’t hurt my feelings. Let’s get started.
Announcing Scorecard
First up! It is with pride that today I announce the first application built with our General Assembly API. The GGA Scorecard.
The GGA Scorecard is a simple, in-browser application that allows you to view the voting history of each member of the General Assembly organized by how they voted. Want to know what a particular member has been for or against during their tenure in the General Assembly? Here’s your resource for finding that information. Additionally, for each vote we provide a link to the details of the vote on the General Assembly’s website so you can get more information.
Oh, by the way, it also works pretty well on phones, too.
You’ll notice that, despite its name, Scorecard doesn’t actually score or rank members of the General Assembly. The true score of any member of a legislative body is always determined by looking at how they voted on what. How you interpret that information determines their score. So, in a way I’ve opted to solve the general problem here, and provided you with a scorecard of sorts that works for everyone: the trick is you get to determine whether a particular vote adds or subtracts from their score.
This is a very basic, but powerful, example of what is possible as a result of the effort put into the GGA-API. Information that was not easily retrievable from the General Assembly directly is now easy to find through us. This application took me four hours on a Saturday afternoon to build. Using the data sources provided by the General Assembly directly it could have easily taken weeks.
I hope for two things with the release of Scorecard: First, that people would find it useful. Second, that it would inspire people to build other great things with the data sources we’re cultivating at GAODP.
We Have a Logo!
After months of being without a brand of any kind, the gracious Andi Mints was kind enough to lend some visual finesse to our humble effort. Ladies and gents, I present the official mark of the Georgia Open Data Project.
If anyone is looking for someone to do some branding work for them, I highly recommend Andi. I’m thrilled with the work she’s done for us, and she’s a joy to work with.
General News
Next I wanted to take a minute to give a few brief updates on what’s new at the Georgia Open Data project. I’ll keep these short and sweet.
- Known Issues in the GGA-API: There will always be defects, issues, and shortcomings in any data source. Here are a few key pain points we’re seeing as of March 2014. Please chip in if you think you could tackle either of them! - House Votes aren’t auto-importing. This is likely related to the fix for Senate votes that I mentioned below. I’ve already spent some time working on this without any workable solution. It’s next on my bug hit list.
- We need some sort of automated heuristics to detect import faults. Right now, the only way we find out that imports are broken is someone tells us. We need to implement some sort of automation that sends off emails when things on the GGA-API server look suspicious (e.g. no data for a particular category for a few days).
- We now have a Twitter account! You can follow us on Twitter. We’re @gadop. The account will be tweeting as changes are made to our code and as we have announcements relevant to the project.
- GGA-API supports JSONP. This is a bit technical, but if you’re looking to integrate GGA-API with an app on your server, you can now do so using the JSONP method. Just add a callback query parameter to any request. This change was introduced in d38a95d83f.
- Member votes are now partially denormalized. You get some basic details about each of the votes the member participated in. We did this primarily for Scorecard’s benefit, but we thought others would find it useful as well. You can get the old behavior back by adding normalize=1 onto the end of your query. This change was introduced in e040062839.
Why We’re Doing GAODP
It occurred to me not long ago that there are a handful of people who are following along with GAODP who don’t quite understand it. So, I wanted to take a minute to share with you an explanation of why I started GAODP and why you haven’t, and likely won’t, see many flashy whiz-bang new things geared towards end-users from me personally.
This month it came to my attention that State Senate votes were not being imported from the Georgia General Assembly’s servers. This is a huge chunk of data to just go missing. After doing some digging I found that the endpoint (the source of data) on the General Assembly’s servers required me to ask for a specific branch’s votes. If I didn’t mention a specific branch, it would just give me votes from the House of Representatives without indicating that something was wrong.
So no big deal, I think. I’ll just add something that asks for each branch and then I’m done. So I did. Then it still didn’t work. Regardless of what branch I asked for, I always got House votes. After about five hours I found out what was wrong. In the request that I sent to the General Assembly’s computers, I was specifying the ID of the legislative session followed by the branch that I wanted data for. Their systems require me specify the branch before the legislative session ID or it just sends me House votes.
This is the sort of nonsense that will send developers into a rage quicker than a red sheet will a bull. In the list of things that shouldn’t matter in 2014 THE ORDER IN WHICH I SEND THINGS IN A REQUEST RANKS PRETTY HIGH. To make matters worse, it now looks like House votes are no longer being imported correctly. So, in pushing a quick fix for the Senate bug, I broke House imports.
This is exactly the sort of nastiness that we hope to alleviate for people who are interested in writing applications that use data from the Georgia General Assembly. I hope that by giving people an easier option and lowering the barrier to entry that more people will choose to spend a few hours building something interesting with it. I hope that using data about the activities of the Georgia General Assembly will be easy for people who build software. Because my time is limited, I will continue to focus my efforts on making that dream – that level of data accessibility – a reality.
As of today if you understand some JavaScript and have a few hours you can build something that produces useful, actionable information for voters. Such a low barrier to entry for building applications that use this data is a big deal, and I can’t wait to see what you do with it.