Closed mileswwatkins closed 6 years ago
I think county-level breakdowns for Senate and maybe Governor's races are on the list of requests. The rest would be top-level results, I believe. We'll need to prioritize.
So, seems like we'll need county info for Senate and governor, and race-wide info for House and ballot initiatives. I don't think FAST_
and SLOW_
are the correct identifiers anymore; maybe we should use DETAILED_
or COUNTY_
vs RACEWIDE_
.
These are the ideal production flags that we'd use, since then we would minimize data transfer totals. But it's totally possible that making a single, ru
-level call for all these race types (as we'll be doing now, since it's compatible with our testing server) is only trivially slower.
ELEX_FLAG_SETS = [
'--results-level state --officeids H,I',
'--results-level ru --officeids S,G'
]
ELEX_INIT_FLAG_SETS = [
'--results-level state --officeids H,I --set-zero-counts',
'--results-level ru --officeids S,G --set-zero-counts'
]
What level of results are going to be visualized? In 2016, the town/county-level was captured for presidential races, but only race-level results (ie, vote totals) were captured for House/Senate/governor/initiative races.
Once the front-end design process has determined which level of data is needed for each race type, this needs to be implemented in the code; specifically
ELEX_FLAGS*
settings. Will we be able to just make one type of call this year, or will it be like 2016 when we had anFAST_ELEX_FLAGS
andSLOW_ELEX_FLAGS
, with the extra overhead (but additional flexibility) that that entails?cc @alykat @lindamood