Hi @jwouellette ,
I think some of those proposals would be very advantageous, certainly in regards to boundaries. If I understand you correctly, this means boundaries would not be limited in their capability or scope as they currently are, as they would have all the benefits of an explicit object type such as geometric representation and property sets?
Having property sets would allow much richer information to be associated with boundaries allowing the ability to be used with multiple calculation engines (and even different disciplines? If it may be useful?). This would certainly allow movement up and down stream for BEM’s which current seems a bit difficult as energy analysis needs to be done in it’s own ecosystem due to the lack of detail IFC can persist for it. One of the main problems (at least my understanding so far) is data needs to be repopulated for the various BEM’s at different stages/tools in the workflow, and is then subsequently lost/discarded when finished with which seems wasteful and time consuming. So this would really push IFC forward as an exchange format for energy analysis I think.
More level types, and types defined as attributes is definitely a good move to. Currently, there is a real loss of precision with the data as everything is packed into a limited/restricted data type, and detailed information (such as thermal bridges etc) is lost being lumped into a single scalar ThermalTransmittance property value (I think I’m right in saying this is L3 are thermal bridges? but please correct me here if I am wrong?).
I’m more data driven (lacking knowledge and expertise in the disciplines… I leave that for the engineers to tell me) so advocate more of a federated model approach (including holding multiple boundary types), however I can certainly see the benefit if users wish to concentrate just on subsets of the data. Decoupling something such as a BEM for usage without all the overhead of the building element geometry etc would definately be a good (I guess this would be similar to gbXML but within an IFC environment?).
Certinaly feels a step in the right direction for IFC5!
I guess this is a bit more difficult to faciliate in IFC4.x though?
I will suggest this to (engineer) collagues to see what they think. Currently they are at the mercy of the data I can provide them for the calc, and I am at the mercy of the data that I can either get from upstream or generate from IFC (the latter being the only way to really add value at the moment). It would make my life easier thats for sure