Closed nealkruis closed 1 year ago
@nealkruis Space includes several "type" fields including:
I think the function data element may be the best to use for this, either we can simply add "residential" to that enumeration or else we can make it a ruleset specific enumeration. I hate to add yet another "type" field here if we can avoid it. The current Laboratory, Kitchen, and other are 90.1 specific I believe. What do you think?
I think this is partly a consequence of the ruleset section authors not coordinating for common ways to define space types. However I think the issue of occupancy type is more broadly important to codes (especially beyond energy codes). I think it is important to keep it separate because it is fairly explicit.
There are residential common spaces that could be a kitchen, and I suspect that there are other overlaps with other "functions" that aren't mutually exclusive.
@nealkruis so the lighting_space_type, ventilation_space_type, and service_water_heating_type all point to ruleset specific enumerations and these include for appendix G values that correspond to residential such as
GUEST_ROOM, DWELLING_UNIT DORMITORY_LIVING_QUARTERS FIRE_STATION_SLEEPING_QUARTERS HOTELS_MOTELS_RESORTS_DORMITORIES_BARRACKS_SLEEPING_AREAS, TRANSIENT_RESIDENTIAL_DWELLING_UNIT DORMITORY HOTEL MOTEL MULTIFAMILY
Why can't one of these existing data elements support the use case you are thinking of? Is it because it is an envelope based requirement? If that is the case, it seems like it would be derivable from one of these other data elements. I hate to have this many non-orthagonal elements and really would prefer not to add another. What if we renamed one of the existing ones to lighting_or_envelope_space_type or something?
I hate that the rulesets have this many non-orthogonal elements, but they do. It's why we decided we needed separate enumerations for the other ones and I don't see this as any different. I think we either include it as a separate enumeration or work to try to consolidate the others into a single space type enumeration.
@nealkruis I added to the schema:
envelope_space_type:
Description: "Envelope space type classification"
Data Type: "<EnvelopeSpaceOptions2019ASHRAE901>"
Notes: "The enumeration is based on the standard used. Often refered to as occupancy type."
and to the 90.1 enumeration file:
EnvelopeSpaceOptions2019ASHRAE901:
Object Type: "Enumeration"
Enumerators:
NONRESIDENTIAL_CONDITIONED:
Description: "Nonresidential conditioned"
RESIDENTIAL_CONDITIONED:
Description: "Residential conditioned"
SEMIHEATED:
Description: "Semiheated"
UNCONDITIONED:
Description: "Unconditioned"
Addressed with 0.0.29 update
I still don't like this approach. It might work for 90.1, but I'm not sure it works for other rulesets where you might need more combinations.
Alternative?
My original suggestion: Make a separate enumeration for occupancy type. While I agree the space type classifications are a bit out of hand, I think that is an artifact of how the rulesets have been written.
That is what I thought I did. What else were you looking for?
You compounded occupancy type with conditioning type. I think they should be separate enumerations.
To be clear, though: I think the rulesets should clean up their space type descriptions to make things more consistent, but that might take a while to get through.
You never said what enumerations you were looking for explicitly and that is probably the source of the confusion. Could you list the enumerants that you want?
Some rulesets change envelope requirements depending on whether a space has a "residential occupancy" or not.