"reporting units" to ward-level results

[epaulson]

Wisconsin doesn't actually publish official ward(precinct)-level results - they're rolled up into "Reporting Units" which might have multiple wards included. (Bigger cities are required to publish report ward-by-ward)

The LTSB disaggregates the GAB/Wisconsin Elections Commission official results and publishes them as CSVs and as Shapefiles. The LTSB version is just estimates - they proportionally allocate per-ward results from the "reporting units" because there is no better data. (They don't take into account different turnout levels of different wards, which would be nice)

Anyway, I've asked for the code for how they do that but they said they weren't able to share - some of it I guess is built into their district-management utility and some of it I get the sense that they just manually edit.

I put together some Jupyter notebooks that I think replicates how the LTSB processes the GAB results. They'd be pretty easy to turn into some scripts, but there'd be a bunch of code to handle special cases for each election. This is what someone would have to do if they wanted to map any of the current election results in this repo.

Long-term OpenElections might want to think about publishing the Wisconsin results like the LTSB does, so they're at least sort-of "ward" level. Alternatively, including a set of files that has "reporting_unit" -> (list of FIPS codes that make up that reporting unit) keeps both the original results as-reported but makes it a bit easier to map.

[nbdavies]

Hi Erik,
That's some cool possibilities for mapping/visualizing the data! Even if LTSB proportionally extrapolates the results reported by the Elections Commission (where wards are often combined) down to the individual ward level, are you thinking we need to report vote counts per individual wards in the openelections repo?

My thought is that LTSB's extrapolations are useful for certain things, but in terms of providing data to the openelections database, we should probably stick to the official/empirical numbers.

[epaulson]

Yeah, I certainly think we'd want to be careful in how to identify any included "precinct" level results in OpenElections data repos, since again I don't think they actually exist (like, I think in many cases elections officials put the ballots in the same bucket and just count the bucket)- the stuff the LTSB Publishes in the zip files in the 'Data Library' at https://legis.wisconsin.gov/ltsb/gis/data/ is slice-and-diced - however, it's a pretty useful slice and dice and what a lot of folks would most want to have, so thinking about ways to include it in the repo already created and with a good reproducible trail is helpful.

Sometime we should ping Derek on how they'd want to handle this or if it's just a weird Wisconsin-ism.

[nbdavies]

FYI, there's another group doing similar stuff with this data over yonder: nvkelso/election-geodata#2 (comment)