search

BuildingSync / schema

BuildingSync® Schema
https://buildingsync.net
Other
23 stars 22 forks source link

Primary, Secondary and Tertiary eGRID Subregion Codes #358

Closed markborkum closed 2 years ago

markborkum commented 3 years ago

Is your feature request related to a problem? Please describe.

Given an eGRID-assigned zip code, the power profiler zip code tool returns between 1 and 3 eGRID subregion codes, referred to as "eGRID Subregion 1", "eGRID Subregion 2" and "eGRID Subregion 3", respectively.

For example, the zip code 30525 is assigned to:

  1. SRTV,
  2. SRSO; and
  3. SRVC.

Currently, in BuildingSync XML schema, an <auc:Site> or <auc:Building> element may have either 0 or 1 <auc:eGRIDRegionCode> child elements.

This introduces 2 issues:

  1. Only 1 eGRID subregion code can be asserted for a given <auc:Site> and <auc:Building> element; and
  2. It is not clear to BuildingSync XML document consumers which eGRID subregion code is being asserted (i.e., 1, 2 or 3?).

Describe the solution you'd like

  1. Rename the <auc:eGRIDRegionCode> element to <auc:eGRIDSubregionCode> to match the terminology in the eGRID standard.
  2. Add <auc:eGRIDSubregion1>, <auc:eGRIDSubregion2> and <auc:eGRIDSubregion3> child elements to the <auc:Site> and <auc:Building> elements.

Describe alternatives you've considered

An alternative approach is to change the maximum number of occurrences of the preexisting <auc:eGRIDRegionCode> element from 1 to 3. However, if this were implemented, then it would not be clear to BuildingSync XML document consumers which eGRID subregion number is being asserted (i.e., is the 1st <auc:eGRIDRegionCode> element for 1, the 2nd for 2, etc.?).

Additional context

For comprehensive calculation of emissions metrics, it is important to know all eGRID subregion codes for a given zip code and their ordering.

macintoshpie commented 2 years ago

@nllong might we want to include this for v3? We could also include in v2.4 as a choice to use either auc:eGRIDRegionCode or the subregion ones as a non-breaking change

One question I have though, does the numbering of the subregions mean anything? Could they change? Just wondering if we should have a more generic list of `s? (@markborkum )

nllong commented 2 years ago

I think this would be great to include in 3 and in 2.4 with the choice.

The question regarding the Subregion1, Subregion2, etc, is appropriate.

markborkum commented 2 years ago

@macintoshpie Both the number and order of the eGRID subregions are meaningful. Currently, in the EPA Power Profiler tool, ZIP codes are assigned to either 1, 2 or 3 eGRID subregions. The 1st eGRID subregion is "primary". For calculations, end-users use either the emission factors for the "primary" subregion or the mean of the emission factors for all assigned subregions.

In principal, the assigned eGRID subregions for a ZIP code only change when the eGRID subregions are changed. New eGRID subregions have been added to the EPA Power Profiler tool (e.g., #381). I am not aware of existing eGRID subregions being removed.

macintoshpie commented 2 years ago

Great, as I understand it documents should follow these rules:

v2.4

valid

1.

<auc:Building>
    <auc:eGRIDRegionCode>...</auc:eGRIDRegionCode>

2.

<auc:Building>
    ...
    <auc:eGRIDSubregion1>...</auc:eGRIDSubregion1>

3.

<auc:Building>
    ...
    <auc:eGRIDSubregion1>...</auc:eGRIDSubregion1>
    <auc:eGRIDSubregion2>...</auc:eGRIDSubregion2>

4.

<auc:Building>
    ...
    <auc:eGRIDSubregion1>...</auc:eGRIDSubregion1>
    <auc:eGRIDSubregion2>...</auc:eGRIDSubregion2>
    <auc:eGRIDSubregion3>...</auc:eGRIDSubregion3>

5.

<auc:Building>
    ...
    <auc:eGRIDSubregion1>...</auc:eGRIDSubregion1>
    <-- each one is optional, no subregion 2 here -->
    <auc:eGRIDSubregion3>...</auc:eGRIDSubregion3>

invalid

1.

<auc:Building>
    ...
    <!-- can't use both old and new method -->
    <auc:eGRIDRegionCode>...</auc:eGRIDRegionCode>
    <auc:eGRIDSubregion1>...</auc:eGRIDSubregion1>

3.0

Same as 2.4, but 1. is invalid (it's deprecated)

For 2.4 we should add a deprecation warning to eGRIDRegionCode

nllong commented 2 years ago

Looking into this more and chatting with the Cambium lead, it looks like there really should only be a single eGRIDSubregion per location. If there are more, it is an artifact of having multiple power providers. Using EPA's online tool, you can enter 80005 and the results return immediately, however when you enter 30525 you have to select the power provider/utility.

From the spreadsheet, there are ~8% with a second subregion and ~0.3% with a third subregion.

I'm concerned that we are designing to the exception here and perhaps the eGRIDSubregion associated with the building/facility/site should be the one from which the power is being delivered. This would push the onus to the creator of the BuildingSync to ensure they have selected the correct eGRIDSubregion for their building based on the utility.

I do agree that we should rename eGRIDRegionCode to eGRIDSubregionCode.

JieXiong9119 commented 2 years ago

I'll do the rename. Should we restrict this element with maxOccurs="1" ?

macintoshpie commented 2 years ago

@JieXiong9119 I think we're going to hold off on this, it sounded like Nick and Mark were going to chat with someone else

macintoshpie commented 2 years ago

After further discussion, we decided not to move forward with this change because our understanding is that a building is associated with a single subregion.

We decided we should still update the naming of the element to Subregion and provide a maxOccurs of 1, see here: https://github.com/BuildingSync/schema/issues/383

macintoshpie commented 2 years ago

Continued discussion has led us to decide BuildingSync should handle multiple eGRID Subregion Codes. The main motivation for allowing multiple codes is that users should use the average of coefficients for multiple region codes.

We concluded the following:

We are currently reaching out to determine if/how we should add these codes to auc:Utility.