search

nprapps / elections18-general

2018 midterm election back-end: Associated Press data ETL, database, admin panel, and JSON output; iteration upon 2016 GE work
MIT License
3 stars 1 forks source link

Update which geographic level is captured for each race type #5

Closed mileswwatkins closed 6 years ago

mileswwatkins commented 6 years ago

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 an FAST_ELEX_FLAGS and SLOW_ELEX_FLAGS, with the extra overhead (but additional flexibility) that that entails?

cc @alykat @lindamood

alykat commented 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.

mileswwatkins commented 6 years ago

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_.

mileswwatkins commented 6 years ago

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'
]