IfcRelContainedInSpatialStructure

[mtveerman]

See:

GitIFCPrototype/111111 Test IfcGit/045leWpMj4oQIEZ829grmf Project/045leWpMj4oQIEZ829grmh Site/045leWpMj4oQIEZ829grme Building/045leWpMj4oQIEZ81sLAAA BuildingStorey/0GDokRCPb3nPU27Rv5we1H Beam/IfcBeam.ifcjson

Line 2 in 6181030

"type": "IfcRelContainedInSpatialStructure",

Somehow I would not expect to find an IfcRelContainedInSpatialStructure definition in the definition of the IfcBeam. An IfcRelContainedInSpatialStructure could hold more than one entity, so why not treat it as a separate entity?

[jmirtsch]

I agree, it's not intuitive. But it was one way of explicitly expressing the folder relationships in a human intuitive way without penalizing the path lengths. This is the first implementation and can be greatly improved. If you explicitly add relationships folder structure looks like this:

And embedding the relationships looks like this.

[radumg]

Ah, the age-old database normalisation issue.

To see if i get this right @jmirtsch , is this beam defined/duplicated anywhere else ?

[jmirtsch]

This is the better of both, although it quickly hits windows path length which is a real drawback.

It also means that any elements with multiple aggregations or element container relationships would be merged (which is rare and not really an issue if the relationships doesn't provide further attributes or relationships).

I guess for spatial elements we could simply use (and enforce) the short name instead of guid to alleviate the file length.

[radumg]

I like that one, question is whether those IsDecomposedBy and ContainsElements folders are required ? If not implicit in the data types, could those relationships be recorded in a top-level table, for example relationships.json ? Could help with the container relationships issue you mention above?

Second question is whether those GUIDs could be shortened ? I'm thinking a short hash algorithm for folder name and full GUID in json file ? Yes, potential for collisions would theoretically increase, but the folder structure should by and large alleviate that ?
Also wondering if using the names by themselves could introduce issues ? I'm thinking of instances where elements were not specifically named in the BIM authoring tool, so their names might not be unique enough ?

PS : hope you don't mind me asking these questions @jmirtsch , i'm learning lots about IFC by exploring these topics. hopefully they also help :)

[jmirtsch]

Discussion is great, I can only encourage other points of view and opinions.
I think the mere fact this serialization of IFC helps you learn and understand is a great characteristic and is a worthwhile benefit.

In IFC, there are multiple ways to aggregate elements.
Commonly http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/link/ifcrelaggregates.htm
but also other sub types of http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/link/ifcreldecomposes.htm (ie IfcRelNests implies ordered aggregation).
But the less folders the better for file path lengths etc. I'm going to alter the serialization so an aggregation is implicitly assumed, and any other relationship is explicitly aggregated.
The guids are already a character compression of a conventional Guid (as I understand it, helped to fit files on floppy discs). But alternatives could be considered. Readily helps identify elements when this is the schema format.
I haven't yet located a where rule or implementer agreement on aggregated element naming, but the guid format could be used if no name is defined (or if duplicate names are detected). The element is still explicitly defined in the json in either way. I'm proposing that this only be used for spatial breakdown (ie unlikely to stories have the same name).

[mtveerman]

(I love this while git/IFC discussion!!)

I think I still stick with my idea of having a folder per IFC entity, and a separate folder storing links between those. As described here:
https://bimagineering.blogspot.nl/2017/09/thoughts-about-git-for-ifc-3.html?m=1

This solves some of the problems:

• less prone to max_path issue
• no data duplication, period
• no issues in terms of aggregation (since whole structure reflects the IFC data graph)

Yes, drawback is the human readability...

[mtveerman]

How does ifcxml handle these aggregates by the way? Hierarchical?

[jmirtsch]

I think all software implementations of ifcxml I've seen generate flat xml file, not utilizing the ifc file hierarchy. I've added the revit export to the repo for the base file. My toolkit does generated the tree so you can collapse or expand branches (image here https://twitter.com/geometrygym/status/745376849547534336)

I've just pushed some commits with the implicit aggregation hierarchy. Certainly looks much better. I also improved the naming conventions for folders and some files.