set up database and load eGRID database data

[sichen1234]

Set up a local database (couchdb) with a table for UTILITY_EMISSION_FACTORS with the following fields:

• Year
• Country (USA for now, can add others)
• Division_type (can be BALANCING_AUTHORITY, STATE_PROVINCE, SUBREGION, COUNTRY)
  _ Division_id
• Division_name
• Net_Generation
• Net_Generation_UOM (unit of measure, can be MWH)
• CO2_Equivalent_Emissions
• CO2_Equivalent_Emissions_UOM (unit of measure, can be tons)
• Source

Load data from the EPA eGRID database

Specifically, we can start from the attached spreadsheet from https://www.epa.gov/sites/production/files/2020-01/egrid2018_all_files.zip

It has the following tabs which are useful:

• ST18: emissions by state (Division_type = STATE_PROVINCE)
• SRL18: emissions by subregion (Division_type = SUBREGION)
• NRL18: emissions by NERC region (Divsion_type = NERC_REGION)
• BA18: emissions by balancing authority (Division_type = BALANCING_AUTHORITY)
• US18: emissions by country (Division_type = COUNTRY)

We can start with NRL18 for now:

• Year = 2018
• Country = USA
• Division_type = NERC_REGION
• Division_id = column C value
• Division_name = column B value
• Net_Generation = column I value
• Net_Generation_UOM = MWH
• CO2_Equivalent_Emissions = column Q value
• CO2_Equivalent_Emissions_UOM = tons
• Source = https://www.epa.gov/sites/production/files/2020-01/egrid2018_all_files.zip

[sichen1234]

egrid2018_data_v2.xlsx

[sichen1234]

@lamnd09 Can you change your import to use the data format described in this task? See the original description and the spreadsheet that I've attached.

[sichen1234]

@lamnd09 After some more thinking I still believe it is better to separate the logic of looking up emissions factors from storing this seed data on the chain. So can you just load one of these records based on what's here and then calculate the emissions by making the conversion? Then we can work on loading and getting data from a DB, either Orbit or Dynamo DB or something else.

[lamnd09]

@opentaps , it sounds reasonable! I will update the data format as #2 #3 with NRL18 to compute emissions. So I will create 2 structure, one for Utility to get NERC_REGION, then with NERC_REGION, a strucuture for emissions we compute the emission as #4. In second part, first step, I just take away some colums contain values of CO2 emission? How do you think?

[sichen1234]

Yes, so currently you have one Value struct, we'll need 3: Emissions which mirrors the emissions.js from node, and then a UtilityData for the fields from #3 and EmissionsFactors for the fields from #2. Just initialize with one record of UtilityData and one of EmissionsFactor for now. We can later work on code for getting them. Then the calculation should have some conversion in case there are other units of measure, for example other than KWH or TONS. Again, you can leave that for later. ----- Si Chen Open Source Strategies, Inc. Join our Hyperledger Open Source Carbon Accounting & Certification Working Group <https://wiki.hyperledger.org/display/CASIG/Carbon+Accounting+and+Certification+Working+Group> - Video <https://www.youtube.com/watch?v=Jbq2TYXPmj0>

…

On Fri, Aug 28, 2020 at 4:56 AM Lam D. Nguyen ***@***.***> wrote: @opentaps <https://github.com/opentaps> , it sounds reasonable! I will update the data format as #2 <opentaps#2> #3 <opentaps#3> with NRL18 to compute emissions. So I will create 2 structure, one for Utility to get NERC_REGION, then with NERC_REGION, a strucuture for emissions we compute the emission as #4 <opentaps#4>. In second part, first step, I just take away some colums contain values of CO2 emission? How do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <opentaps#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANAS4K6H7BCONQROJ27JFDSC6LQDANCNFSM4QCMPLZA> .