Vermont Election Results at the Precinct Level…Can We Map Them? (Yes, We Can…Now!)
What to do when you want to map voting results at the most granular level…and the boundary map data needed to show those results doesn’t exist? Vermont civic hacker Bill Morris contacted the Vermont Center for Geographic Information because he knew we might be able to help. Bill emailed one day during the spring of 2017 to say “Oh hey, so looking closer at this [HOUSE2012 boundary data] I think I need something slightly different to represent “voting precincts”…” As a result, VCGI staff created a new map layer to which Bill could join the voting results and soon it will be possible to analyze and visualize voting results at the reporting level.
The new “Voting Tabulation Areas” layer represents the smallest voting tabulation areas in Vermont, as reported by the Elections Division of the Secretary of State’s Office. In some cases, the geographic extent is a municipality, in other cases it is a section of a municipality. Many of the polygons in this layer represent PART of a state House District (the House District is the unit to which votes are tabulated to determine the winner of an election, and many of them are multi-town, while some are sub-town). This new layer was created using aspects of two existing layers: town boundaries from the “Boundary_BNDHASH_poly_towns” layer and any boundaries that split towns were derived from the “BoundaryOther_HOUS2012” layer. The new layer can be joined to tabular voting data reported by the VT Secretary of State Elections Division (http://vtelectionarchive.sec.state.vt.us/).
Navigating to a New Map Layer
Bill was looking for “precincts” because of an interesting aspect of how the Elections Division of the Secretary of State’s office reported elections results. They post data by the smallest reporting unit, rather than simply by either house district or town. As a result, their data did not match up with any existing geography that we included in our various boundary layers. Here is an easy example:
The Chittenden 6–7 district includes the entirety of the City of Winooski plus a small slice of Burlington, as we see in the second image at the top of the article. This district is one polygon in the House Districts data layer, and the section in Burlington was not a separate polygon in any layer. But the Elections Division reports voting data for that slice of Burlington separately from the Winooski votes:
Since the Elections Division reports the data at the smallest possible unit (in some cases at the town level, even if the town is part of a house district that include multiple towns, in some cases at the sub-town level), VCGI staff decided we should have a spatial layer that represented those units, so that the data could be mapped and analyzed.
Luckily, we did have the two digital map layers necessary to create the new layer: Town Boundaries and House District Boundaries. We needed to use the boundaries in the House layer that split Towns because those are the only representations of those boundaries and they were actually created during the last re-districting process by staff performing “heads-up digitizing” — essentially tracing the lines on aerial photos to match roads and waterways as dictated by the final legislation describing those boundaries.
The process of splitting town polygons was a bit laborious and manual, but not horribly onerous. In the end, 20 additional polygons were created (beyond the 255 found in the town boundaries layer). Initially, we used QGIS to perform the geoprocessing necessary to create the new polygons, but after doing so, we found that QGIS (v. 2.14)had introduced topology errors that were impossible to fix. Overlaps and gaps that were too small to see had occurred everywhere a polygon had been split. After checking with a colleague, we determined that my methodology was sound, but that QGIS seemed to have a bug.
Moving on to ArcGIS, I repeated the steps I had practiced in QGIS and successfully split all of the necessary polygons. The steps are outlined below:
- Using Boundary_BNDHASH_poly_towns as the starting layer, BoundaryOther_HOUS2012 was used to identify and define any districts that made subdivisions of towns.
- HOUSE2012 was converted to a line layer
- Lines that defined features internal to a town were identified.
- Lines that could be used to split a (town boundary) polygon were selected and used to split the polygon using the Cut Polygons tool
- A topology check did not identify any gaps or overlaps!
In order to identify which district a voting tabulation polygon belonged to (and include those attributes in the final polygon layer), the following steps were followed:
- BoundaryOther_VOTETAB2012 was converted to polygon centroids
- A spatial join was performed with the centroids as the target and the HOUSE2012 polygons as the join layer — this copied the House districts codes and names into the centroid layer
- After saving a new point shapefile containing the attribute information for District Code and Full District Name…
- A spatial join was performed with BoundaryOther_VOTETAB2012 as target and the new points with district attributes as join layer — this copied the district code and name into BoundaryOther_VOTETAB2012
- BoundaryOther_VOTETAB2012 has a valid district code and full name for all voting tabulation areas
- Final steps involved adding the following attributes: TOWN_GEOID and VOTETAB_ID. Why do these ID’s matter? See explanation below.
Why the Structure and Attributes of the Data Matter
The final data layer represents the best spatial boundaries we have available, as well as key attributes that make it possible to use the spatial data in concert with tabular data such as voting results.
TOWN_GEOID — this is a town code that allows users to dissolve the districts by town or join this data to other town-based tabular data.
VOTETAB_ID — this is a brand-new ID that allows the user to join the spatial data to election results…when the Elections Division of the Secretary of State’s office chooses to include the ID in their election results. Since this is key to the usefulness of this new spatial data, VCGI staff has stayed in close communication with Elections Division staff during and after the creation of this new layer. They agreed that it makes sense to add the new ID to the elections results data.
An interesting aspect of creating a brand-new ID was the emotional decision regarding format: should the ID be meaningful (and if so, how?) or should it simply be sequential numbers or even random alphanumeric combinations? I got back in touch with Bill Morris when I faced this decision to see what his opinion was, since he is a “big data” user. His advice was, as always, extremely useful:
I lean both ways at times, but I think the year-specific numeric id will work best for both machine integration and sustainability, provided the SoS office is on board. The last bit is the kicker, and bears thinking about the SoS staffer hired in 12 years who doesn’t recognize any of the numbers and unilaterally strips the column in the interest of “simplification”.
Another thing to consider is that the ID should always be interpreted — by every possible platform — as text instead of integers. This is to avoid:
- Excel stripping the leading zeros
- R ADDING leading zeroes
- Some random XML parsing library thinking the field is actually an ISO 8601 dateSo, probably something like this would fool most interpreters into conforming: “vt_2012_037”, “vt_2012_174”, etc.
-B
This made so much sense to my colleagues and I here at VCGI that we did exactly that!
The Results
With the VOTETAB_ID included in both the VOTETAB2012 boundary data and the elections results, we can join them together and make maps like this one:
You can find the VOTETAB2012 data layer (and lots more) at the VT Open Geodata Portal: http://geodata.vermont.gov/datasets/vt-data-voting-tabulation-areas-per-decennial-redistricting-2012
