Electoral Maps

Early on in 2017 I had two conversations that set me on the path of learning about maps. One was with Mike Gaughan, who suggested that it might be possible to identify neighborhoods in Kansas with larger-than-normal numbers of unregistered voters. The other was with Paul Davis, who suggested that it might be possible to identify Kansas state legislature districts that could be flipped with targeted outreach to just a few neighborhoods.

I knew that one of the big issues affecting election outcomes was how the maps get drawn for political districts: state legislative districts, congressional districts, etc. But how did those political district boundaries correspond to the votes that are cast? No one seemed to have a map that could show me, for any given district, how the votes in that district for a given election correspond to streets and addresses. Or how did a particular neighborhood vote from one election to the next. State elections can often be decided by dozens of votes, so knowing how a particular neighborhood votes (or fails to vote), from year to year, could be a significant datum to understand.

I realized that it was hard to take a research and data-driven approach to a geographic problem without good geographic data. And none of the Democrats I spoke with seemed to have that data. So I decided I was going to create a map-oriented research tool for elections over time.

The Map Is Not The Territory

One fact in particular made the map data hard to acquire and use. Election results are reported to the Kansas Secretary of State at the county level. Each county clerk tallies up the votes (a process called certifying an election) and sends those numbers to the SoS office. Kansas has 105 counties. If you look at a map of Kansas counties, one thing you will quickly realize is that they are all mostly the same size and shape. That’s because the county boundaries were drawn very early in the state’s history without regard to where people lived and without knowing where they would settle a century later. County boundaries ignore population and they do not change over time.

Political district boundaries, however, are entirely about population and they change over time based on relative movements in the population. The idea around equal representation is that each district has roughly the same number of people, not the same number of acres. This is what gives political map drawing its power, because the political district boundaries could be drawn in carefully constructed ways to maximize a particular kind of voter in a given district.

So elections are reported by counties. Counties are about land size and don’t change. Districts are about population and change frequently. To borrow a math metaphor, what is the least common denominator?

The Precinct

The precinct is a geographic boundary that aligns with a political boundary. Every county is made up of one (often dozens) or more precincts. Every ten years the county clerk’s office divides the county into territorial entities in order for the federal government to count all the people in the census. Those territorial entities are called census tracts. Everyone gets counted in exactly one (we hope). Each census tract is also a voting district, or precinct. (It gets more complicated in the ten years between census takings. Read on for more.)

Most significantly, political district boundaries align with precinct boundaries. In your precinct, you belong in exactly one state house district, one state senate district, one congressional district. A political district is, in other words, the sum of its precincts. (Precincts are also vital to how political parties work, which will be the subject of another post.)

So if I wanted a map that would show, over time, how Kansans in specific neighborhoods vote, or if there were neighborhoods with a predictably low voter registration or turnout record, I would need reliable precinct-level election data, voter registration data, and I would need precinct-level map coordinates in the form of shapefiles.

Seemed straightforward enough at the time, I thought. I just need to look around on the internet and between the SoS website and the census.gov website, I’m sure I’ll find everything I need.

Oh foolish, silly, naive man. I look back on you now and chuckle at your enthusiasm. Of course, if I had known how hard it was to acquire those data and make sense of them over time, I might not have started in the first place. Deceptively simple problems get a lot of yaks shaved.

Fortunately, I quickly stumbled upon other people who were thinking the same things about maps and precincts, and other people who had been working hard at the precinct election data problem for a long time. I was able to follow in their footsteps.

In my next post I’ll dive into the nitty gritty of the challenges I encountered building the map.

Talking to Democrats

I am not particularly attached to the Democratic Party. Until 2017 I wasn’t registered as a Democrat. (And I only registered as one because the KDP, reasonably, wouldn’t let me help with their data otherwise.) My personal politics are more green/socialist. I just saw the Democratic party as the group best positioned to swing state races in 2018 and defeat 45 in 2020.

So in 2017 I reached out to my state and county parties and started cold-calling people. Would they meet me for coffee and talk about politics and technology? Yes they would!

I asked everyone three questions:

  • could technology have changed the outcome of the 2016 election?
  • if yes, what could someone like me do to help for 2018 and 2020?
  • who else should I talk to?

I’m very grateful for everyone who explained how precincts work, how county and state parties work, how the voter file works, how campaigns work, how campaign technology works (and doesn’t work). I spent several months meeting all sorts of Democrats, in Kansas and elsewhere (thanks to the wonders of the internet) and listening to their answers to my three questions. It turns out I knew very little about how elections work. Everything else I have been doing since then stems from something I discovered while talking to the Democrats that year who were so generous with their time and knowledge.

Follow a Bill

After the election, reading was how I spent my free time in November and December of 2016. That, and talking to my brilliant partner about all I was learning about political machinery. As it happens, she is a professor who teaches social policy and takes her students on field trips to the state capital in Topeka. She suggested that if the state legislature was so important, I should learn how it actually works: find a bill and follow it through the legislative process.

So I went to the Kansas legislature website and tried to figure out how to follow a bill. I found I could search bill text and find bills if I knew their number, but I could not find a feature that would send me email whenever the status of the bill changed: when it was going to be discussed in committee, or voted on, etc. I knew from using the federal congress.gov site that it was possible to get alerts on federal legislation emailed to me if I created an account. The same kind of follow-the-bill alerts feature did not seem to exist for the Kansas legislature.

I figured that someone must have solved this problem already. The closest I found was openstates.org which did not have the alerts feature but did have an API that I could use. After touching base with the OpenStates developers to see if the alerts feature was planned (it was but without a timeline), I decided to see how quickly I could prototype the legislative alerts feature myself. A classic yak shaving exercise. I had three design goals:

  • The minimally viable product should take no more than a single weekend;
  • Send alert emails for a single bill or a saved search (like a Google alert);
  • Store the minimum amount of user account information possible.

Since I had been doing a lot of Ruby on Rails development for my day job, I decided to use that tool to meet goal number one. Goal number three was made possible thanks to the wonders of OAuth: I could let users log in using an existing account (Google, Twitter, GitHub, but not Facebook since I did not (yet) have a Facebook account). Goal number two proved to be the trickiest but that was where all the fun was. I found an existing Ruby client for the OpenStates API and after some experimentation, hit on a data model that did most of what I wanted. The end result seemed good enough to me that I decided to go ahead and register a domain name and set up a GitHub organization and a Twitter account. I figured I would use it, at least, and since it could search all US states, maybe others would find it useful.

What I did not know yet was what bill I should follow. This is what yak shaving can lead to: lots of energy spent working on the thing you think you need in order to do the thing you want to do, and then sort of forgetting about the thing that got you shaving that yak to begin with. (I did eventually find a bill to follow: my own.)

Each year since then I have updated the site to reflect changes to the OpenStates API and to make small improvements. But basically the site is as it was three years ago. It does one thing and it tries to do it well. I’m told that the OpenStates.org site itself will soon offer the same kind of functionality. When it does I’ll be glad to shut down legalerts.us and treat it as a learning exercise that helped me experience how a bill becomes a law.