Many of Virginia's clean energy goals and legislative mandates take the form quantitative targets that are to be achieved by specified actors on specified schedules. Example: "Dominion shall bring online 15 GW of new solar generation capacity by 2030."
@LEEPYUNG has organized these targets into a spreadsheet. This represents an important start. But we need a more refined system.
The task: Design, implement, and document a solid structure and process for organizing and storing these targets.
The structure should incorporate, at a minimum, fields representing the following values:
target date, e.g., 2020-01-01
quantity, e.g., 15000
units, e.g., MW
goal type, e.g., solar generation capacity
goal sub-type, e.g., utility-scale
text description of the goal in English
and perhaps other fields.
The structure we adopt should be sufficiently robust, flexible, and comprehensive to enable at least the following use cases:
The resulting data set should serve as our "gold copy" for data that represent Virginia's clean energy goals. This will be the source from which we pull values used to create visualizations.
The data model should ideally allow for representation of all the different goals, targets, and mandates that Virginia has adopted through its clean energy legislation, in diverse areas: solar, wind, energy efficiency, equity, etc.
In practice, though, we may find that some of the goals are so complex and case-specific that it does not make sense to develop a data structure sufficiently general to embrace them. Judgement call.
The structure should allow for future amendment of current targets.
The structure should be sufficiently general to allow for the addition of new goals, of new types, possibly by additional actors/responsible parties.
Some possible options for implementation:
One simple, cheap option may be simply to refine the current spreadsheet into a format that enables the above use cases. The spreadsheet could be stored on a cloud drive, or in an appropriate folder in the repo.
A more involved but likely superior option would involve creating a set of database tables, one for each goal, each structured as a time series:
Year
Target
[year value]
[target quantity]
[year value]
[target quantity]
[...]
[...]
All the time-invariant parameters of the goals, such as units of measure (e.g., "MW") and the responsible party ("Dominion"), could be stored in records in the existing metadata table. A new logical field is_a_goal could be added to the metadata table, to distinguish tables containing goals from those containing historical observations or forecasts. The fields data_source_brief_name and data_source_full_name could be used to store references to the legal source of the goal -- e.g., "Virginia Clean Economy Act of 2020".
Use your understanding of the problem and your skills to craft a good solution.
Many of Virginia's clean energy goals and legislative mandates take the form quantitative targets that are to be achieved by specified actors on specified schedules. Example: "Dominion shall bring online 15 GW of new solar generation capacity by 2030."
@LEEPYUNG has organized these targets into a spreadsheet. This represents an important start. But we need a more refined system.
The task: Design, implement, and document a solid structure and process for organizing and storing these targets.
The structure should incorporate, at a minimum, fields representing the following values:
The structure we adopt should be sufficiently robust, flexible, and comprehensive to enable at least the following use cases:
Some possible options for implementation:
One simple, cheap option may be simply to refine the current spreadsheet into a format that enables the above use cases. The spreadsheet could be stored on a cloud drive, or in an appropriate folder in the repo.
A more involved but likely superior option would involve creating a set of database tables, one for each goal, each structured as a time series:
All the time-invariant parameters of the goals, such as units of measure (e.g., "MW") and the responsible party ("Dominion"), could be stored in records in the existing metadata table. A new logical field
is_a_goalcould be added to the metadata table, to distinguish tables containing goals from those containing historical observations or forecasts. The fieldsdata_source_brief_nameanddata_source_full_namecould be used to store references to the legal source of the goal -- e.g., "Virginia Clean Economy Act of 2020".Use your understanding of the problem and your skills to craft a good solution.