Defining tags for space inside a building isn't actually defined and I would like to propose something simple so we could have something to start with.

The concept of Zones brings a lot of discussion / interpretations... that's why I thought using the simple term: room. A room is a physical space inside a building surrounded by walls/windows/doors. A hallway is a room, an office is a room... Special cases can be defined as there's nothing that would prevent one to use "room" tag to split one big physical room into a bunch of rooms... or maybe a kind of "sub-room" tag could be used... but for now, let's keep it simple.

Zone would be the result of a query like that : all rooms served by equipRef:@vavX As it is an abstract concept, it seems logical to me that it would be defined by a query...

I think that departmentRef, floorRef would be useful ref tags...

So here is my proposal

departmentRef id: @department_name dis: "Department Name" siteRef: @site

floorRef id: @floor_id dis: "Floor Id" siteRef: @site

roomRef id: @room_id dis: Str roomNumber: Str levelRef: @ departmentRef: @ area: Number sqft width:Number height:Number length:Number volume:Number diffusersType: "ex.ceiling" diffusersQty:Number flowMinClg:Number cfm flowMaxClg:Number cfm flowMinHtg:Number cfm flowMaxHtg: Number cfm numberOccupants:Number

Example

Engineering Department id: @engineering_department dis: "Engineering Department" siteRef: @site

2 floors and 1 basement id:@basement dis: "basement" siteRef: @site

id:@floor1 dis: "Floor #1" siteRef:@site

id:@floor2 dis: "Floor #2" siteRef:@site

a few rooms id: @room_101A dis: "Mr Jone's office" roomNumber: "101A" floorRef:: @floor1 departmentRef: area: 200 sqft width: height: length: volume: diffusersType: ceiling diffusersQty:2 flowMinClg: flowMaxClg: flowMinHtg: flowMaxHtg: numberOccupants:1

id: @room_102 dis: "other office" roomNumber: "102" floorRef: @floor1 departmentRef: area: 1000 sqft width: height: length: volume: diffusersType: ceiling diffusersQty:4 flowMinClg: flowMaxClg: flowMinHtg: flowMaxHtg: numberOccupants:

id: @room_101 dis: "Mr Engineer's office" roomNumber: "101" floorRef: @floor1 departmentRef: @engineering_department area: 400 sqft width: height: length: volume: diffusersType: ceiling diffusersQty:1 flowMinClg: flowMaxClg: flowMinHtg: flowMaxHtg: numberOccupants:1

id:@vav1 roomRef: @room_101 roomRef: @room_102

Here is a challenge of defining relation between equipRef: Vav and rooms... if not possible to use "arrays" of Ref tags...we could use equipRef tags in each rooms...

I am not sure department is really a good abstraction to standardize. Floor and rooms are pretty much standardize terms I think everyone could agree upon. But I think we'd still have to do some really hard work to standardize the fundamental abstractions for space and zone. COBIE I believe has some good definitions and I think we should align with what they have done. If someone is an expert in how they did it, then maybe we can craft a complete proposal.

I do think that the concept of a List of Refs is something we should seriously consider. The 2D-ness of haystack data can be constricting at times.

Its true that the benefits of tabular data are very high for export to CSV, Excel, SQL, etc. So I don't think we should do anything to move away from 2D data structures in general.

But frequently there are cases that occur where one ends up encoding zinc inside of zinc, e.g. point actions, priority arrays, and the like. Even the enum tag is an example of an encoded list.

Complex models like the one that Christian is exploring are another example of a case where a data structure inside of a row value could be very useful -- in this case supporting a many-to-many relationship via a sequence of Refs.

The problem of course is that if we allow complex data structures at the syntactic level, then we will quickly move away from CSV going straight into Excel or Rdbms, which is probably not acceptable.

Perhaps we could introduce the concept of allowing embedded data structures (List, Dict, Grid) to be unquoted via a flag on the request, but have the default be that they are quoted as an escaped string as we do now.

@Brian Aligning with COBIE from what I understand means aligning with BIM modeling wich seems to be really complex (and complete yes). http://www.buildingsmart-tech.org/ifc/IFC4/final/html/index.htm

Do you think Haystack should act as a kind of interface between BIM and another server ?

Or are you proposing to align only with terms and implement our own representation ?

To be honest, I'm afraid by the level of complexity of BIM and it wouldn't be my first choice (even not my second...). It's really made for construction...

If we are only concerned by using good terms and definition, I agree that we can stick to what have been defined by BIM modeling :

http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcproductextension/lexical/ifcspace.htm

http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcproductextension/lexical/ifczone.htm

In fact, we could state that if there's some internal fight concerning semantic/definitions and word choices, we will use definintion given by BIM modeling.

I'll end saying that I'm pretty confident that we should keep things simple. haystack should be used to analyse data not to build a new building. We don't need every layers of complexity of BIM.

Or are you proposing to align only with terms and implement our own representation ?

I don't really think we need the complexity of BIM, but at the same time I don't think we should define things that don't cleanly align. Today these worlds are very separate, but they will converge over time.

Regarding spaces versus zones, you can see in BIM that space is more of a human view of the building (rooms, floors, etc). Zone is more of a system's view of the building (VAV zones, lighting zones, security zones).

We would have to decide if we need both concepts, how they are modeled, and how they compose together. I don't think we can fully tackle any piece without putting together the whole design for zones, spaces, floors, rooms, etc.

One similar concept that is defined in Haystack is "lightsGroup".

I am curious if anyone uses this tag; and if so how do you use it? It sounds similar to how a lighting zone might be defined.

@Brian Both concept can cohabit very well I think and I'm pretty sure that we would have a stronger model with both concepts. A physical one, let say space and a logical one zones.

For little systems or non-complex ones, zone and space can be the exact same thing but we cover more situations with both.

@Denis I may be wrong but the notion of lightsGroup refer to the way they are programmed. Lights in a same zone could be on different lightGroups (if group #1 is dimmable or near windows, group #2 could refer to the middle of the zone, etc...)

One similar concept that is defined in Haystack is "lightsGroup".

Yes that is heavily used, but is not really related. That was just to fit lights which are typically boolean points into the equip/point model. It serves as the equip level for lights to contain one more "light switches" which use the lights tag.