The docs don’t seem to mention this explicitly, unless I missed it. Here are some guesses:
Thoughts?
I’d second that but just to confirm, the site boundary in this case includes temporary works but would you also want to include adjacent roads, offloading points etc.? I don’t have an answer but I do see this as more than just where the boundary fence is run.
Just my thought…
@ColinH ah yes, to be more specific I was referring to the legal boundary (i.e. the lot boundary) where the design is constrained by. This may or may not correlate with a physical boundary (e.g. some overhangs may be legally allowed, or street furniture may spill over, or boundaries may vary temporarily during construction tasks, etc).
@Moult Maybe we should talk with someone from the IFC for Site, Landscape, and Urban Planning – call for participation - buildingSMART International. Any idea of the status of this call @jwouellette ?
Some of these concepts could also get covered by the future implementation of IfcSpatialZone, as established in the proposed clusters from the Spatial Zone Project:
* Definition / Declaration
* Regulation / Validation
As many of them are out of the hierarchical structure of the corresponding domains (IFC Road, IFC Building, IFC Airport, …), there is a need to cover them crosswise.
I hope we can discuss these topics in Rome, too.
There has been no further action because there was no Sponsorship support for it. Once we’ve had commitments to funding the project, we could move it forward to a Detailed Project Plan, review, approval, and launch.
BTW, my feeling is that IfcSpatialZone only confuses things more than what was present with IfcZone. We could have simplified things by removing the Body Representation aspect of IfcZone and made it more like IfcRoof, where it could have a BR or not, depending on the use (singular “object” or aggregation of spaces). But that’s just my opinion. Now users have to decide which is which and there needs to be some kind of differentiation in every piece of software… which may be too subtle.
@jwouellette Thanks for the feedback. We’d be glad to discuss it during our presentation of the final technical report in Rome. We need this kind of valuable feedback more often and in more exposed public events, not just in some forum corners like this one.
I have a completely different opinion regarding the effects of the IfcSpatialZone once it is implemented. In fact, I think there is a lack of crosswise work between the different vertical subdomain development regarding spatial structures that are not essentially hierarchical but identified as that.
And coming back to the IFC for Site, L and UP, it is a pity you couldn’t find enough support. Let me know if there is a way we can help from that perspective. We know different actors in Spain (public ones) that are very interested in that matter (even building digital stuff, thus investing), and we could try to get them involved. I am unsure if there are other technical reasons beyond the financial one that could jeopardize the progress of this important call (bSI project priority levels considering the other evolving infra domains, etc…).
I’ll be happy to help.
Cheers, Jeffrey!
David
FWIW we now use IfcVirtualElement for this in the BlenderBIM Add-on. It has the added benefit of being automatically considered as a boundary for area calculations.
@Moult But the use of IfcVirualElement seems to be addressed for boundaries related to IfcSpace objects, and since spaces are areas or volumes that provide for certain functions within a building, it does not cover non-hierarchical spatial structures, such as the Site or subsite ones.
Even though the docs only explicitly mention IfcSpaces, I think it’s quite intuitive to imagine virtual elements separating IfcExternalSpatialElement which can indeed be hierarchical and on the IfcSite.
This is all uncharted territory of course 