Support Standards Building Type and Standards Space Type in Space Type data

[DavidGoldwasser]

Currently other than space type name, color is only data that can be stored. It would be great to include Standards Building Type and Standards Space Type. This would make it easier to use measure to import JSON into an empty seed model and then run measures that populates space types using the standards gem.

[DavidGoldwasser]

I just wanted to document my work arounds for this.

1. Create an OSM that already has the space types you are going to use (with their standards assignments). Then export that as an FloorSpaceJS. When you go to FloorSpace JS, start from this json file instead of an empty one. You can merge that JSON with geometry back into the a copy of the template OSM. The space types should be linked together.

2. An alternative would be to make a measure with strict name matching of space type names, that could recognize and assign the standards building type and space type on the fly. This would be error prone for users, but you could make a template JSON file with pre-named space types to help. Would be similar to option one but is uses a measures instead of a custom OSM with pre-made space types.

[sarocu]

A cleaner workflow would be great here. Currently I am creating library files with (my) SuperStudio CLI and uploading them into the editor in order to plug in space type and construction sets, and then using the CLI to find and apply OS-Standards space types (as @DavidGoldwasser suggests).

# export a library file:
superstudio export --template 90.1-2004 --building_type LargeHotel --output ./hotel.json

# upload the output file to FloorSpaceJS and create a model...
# download the JSON...

# create a new model from JSON:
superstudio --create --building_type 'LargeHotel' --climate_zone 'ASHRAE 169-2006-5A' --standard '90.1-2004' --geometry --json ./floorplan.json

It would be nice to skip the library generation/importing step. If anyone would like to make a traditional measure to do the above, the relevant code in my CLI is here

[bgschiller]

@DavidGoldwasser, can you check my understanding on this item? We want a new field, "building_type" on each space. The UI should offer a dropdown, and the choices are:

[
  "Single-Family", "Multifamily (2 to 4 units)", "Multifamily (5 or more units)",
  "Mobile Home", "Vacant", "Office", "Laboratory", "Nonrefrigerated warehouse",
  "Food sales", "Public order and safety", "Outpatient health care",
  "Refrigerated warehouse", "Religious worship", "Public assembly",
  "Education", "Food service", "Inpatient health care", "Nursing", "Lodging",
  "Strip shopping mall", "Enclosed mall", "Retail other than mall", "Service",
  "Mixed use", "Parking",
]

right?

Should space_type also be available, and drawn from the same list of options?

It seems like the best thing would be to have a "building" level of organization, to assign properties that apply to all spaces within that building. Unfortunately, that's a pretty drastic change from how floorspace is currently organized.

[DavidGoldwasser]

I'm proposing three new fields. 'template', building_type and space_type. This would match how OpenStudio works, so that instead of just a space being a corridor it can be ASHRAE 90.1 2004, Primary School, Corridor.

This should only be applied to a space type, not individually to spaces. I'm fine not supporting a building level default space type, but it isn't necessary if it is problematic.

I'm also fine just having a free string for the user to enter. The OpenStudio Application has a cascading behavior where once you pick a template it shows you buildings, and once you pick a building it shows you spaces. I don't know that we want to maintain that in FloorSpaceJS, and I don't know if it can dynamically read from the open studio standards gem (I'm not sure if the OS does that or not). If we did hard code anything, I would also want to allow the user to easily add custom names.

For reference, the most commonly used building types are the DOE ones https://github.com/NREL/openstudio-extension-gem/blob/develop/lib/openstudio/extension/core/os_lib_model_generation.rb#L64-L90

And here are the space types https://github.com/NREL/openstudio-extension-gem/blob/develop/lib/openstudio/extension/core/os_lib_model_generation.rb#L404-L696

I'm just showing those for reference If we did want to try to support these pre-populated values one approach could be to have a pre-made collection of these and have an option for a user to load in a building type, and they would get the space types that go with that building type. If they have a mixed use building they could load in a second set of building type/space type combos. In OpenStudio standards we even have colors that go with these space types that could be used.

The end goal of this is to support measures that rely on these standard tags to the space types.

[benfen]

@DavidGoldwasser What is the building_unit field used for on spaces downstream? I'm thinking about using that to organize spaces into buildings.

[DavidGoldwasser]

I'm going to reopen, this I think my fault for some mis-communication and then following up.

Template, Building Type, and Space Type measure tags are attributes of a space type object in OpenStudio, and not individual spaces, as shown below.

In FloorSpaceJS they are all in space object now

What is shown above is correct for Building Unit but Template then Building Type and then Space Type should be in the Space type attributes in FloorSpaceJS in the view below

Rough mockup below

Then when forward translation from FloorSpaceJS to OSM happens, it is direct field to field between the formats. Its hard to assign and to use data assigned directly to a space, and may create condition with mixed settings where multiple spaces assigned to a single space type have different standards measure tags that do not align.

[DavidGoldwasser]

Looking back at things Space Type Column no space should be an attribute of space, it is the Standards Space Type" as well as "Standards Template" and Standards Building Type that are space type attributes as shown in OS application.

So space columns should look like they do in this screenshot from OS App