Closed epaulson closed 7 years ago
This does seem to be a problem with the processed csv data as checked into github - when I clone the repo and run parse.py - which uses the Excel files that are in the local_data_cache - I get different results from what are checked in to the yearly directory data:
(openelex27)epaulson:~/development/openelex/openelections-data-wi $ git status
# On branch 10-missing-election
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: 2010/20100914__wi__primary_ward.csv
# modified: 2010/20101102__wi__general_ward.csv
# modified: 2011/20110503__wi__special_general_ward.csv
# modified: 2012/20120403__wi__primary_ward.csv
# modified: 2012/20120605__wi__general-recall_ward.csv
# modified: 2014/20140812__wi__primary_ward.csv
# modified: 2014/20141104__wi__general_ward.csv
# modified: 2015/20150217__wi__special_primary_ward.csv
Not sure how you want to keep those up to date with what parser.py produces.
Thanks for this catch.
@davipo has some changes in his fork that fix this. (There were some spreadsheets where the last sheet wasn't being read.)
@epaulson Can we close this one?
Yeah, I think so - I just spot-checked the same CSV from a fresh checkout and it had 99 races instead of 98, so I think it's better now.
It looks like Assembly district 99 got dropped in the data as checked in:
Grabbing the API metadata from http://openelections.net/api/v1/election/?format=json&limit=0&state__postal=WI and checking the .xlsx the GAB supplies I do see AD 99:
Not sure what other elections might be missing data in case this is an off-by-one error in the parser somewhere...