Representations
Introduction
An IfcProduct can have a representation. The IfcRepresentationItem conveys the representation data and can take a variety of forms that each calls for specific technical handling. Indeed we have IfcBoundingBox, IfcExtrudedAreaSolid, IfcGeometricCurveSet, IfcFaceBasedSurfaceModel, IfcMappedItem, ... to name a few. Also Tessellation is available as of IFC4. This introduces a simple Mesh geometry where every shape is approximated by a set of non overlaping triangles. It will be convenient - or necessary - to reduce the variety of representations used in the IFC for the submission process. Alternatively, applying IfcOpenshell tessellation might help. It is worth noting that in IFC5, Mesh geometry will be at the core (base/default geometry)
An overview of the IFC geometry is provided in Building Information Modeling.
flowchart TB
IfcObject --o IfcProduct
IfcProduct --o IfcElement
IfcProduct --o IfcSpatialElement
subgraph spatialelement
IfcSpatialElement --o IfcSpatialZone
IfcSpatialElement --o IfcSpatialStructureElement
IfcSpatialStructureElement --o spElem["IfcSite,<br/>IfcBuilding,<br/>IfcBuildingStorey,<br/>IfcSpace"]
end
subgraph element
IfcElement --o IfcBuildingElement
IfcElement --o IfcDistributionElement
IfcBuildingElement --o elem["IfcWall,<br/>IfcSlab,<br/>IfcColumn,<br/>IfcBeam,<br/>IfcDoor,<br/>IfcWindow,<br/>..."]
end
IfcProduct --o IfcProductRepresentation
subgraph representation
IfcProductRepresentation --o IfcProductDefinitionShape
IfcProductDefinitionShape --o IfcShapeRepresentation
IfcShapeRepresentation --o IfcRepresentationItem
IfcRepresentationItem --o IfcGeometricRepresentationItem
IfcGeometricRepresentationItem --o item["IfcBoundingBox,<br/>IfcExtrudedAreaSolid,<br/>IfcGeometricCurveSet,<br/>IfcFaceBasedSurfaceModel,<br/>IfcMappedItem,<br/>...<br/>,<br/>Tessellation<br/>"]
end
In our workflow, the geometry is created in the AEC Tool and preserved along the tranformation so that it can be rendered in a standard Ifc Viewer. Up to a point, this appears as a non issue.
Ingress flow:
flowchart LR
AECTool --> IFC
AecGeo["Create Geometry"] --> AECTool
IFC --> Python
Python --> IfcJSON
IfcJSON --> Python
Python --> DB
style AecGeo fill:#148F77
Egress flow:
flowchart LR
DB --> Python
Python --> IfcJSON
IfcJSON --> Python
Python --> IFC
IFC --> IfcViewer
ViewGeo["Visualize Geometry"]
IfcViewer --> ViewGeo
style ViewGeo fill:#148F77
That's fine, until we need to handle specific geometric aspects. Which is a requirement with most administrative processes. When we create an IfcSpatialZone, we will eventually need a represenation derived from IfcRelReferencedInSpatialStructure elements.
There we have several possibilities to explore:
- Use IfcOpenShell Geometry in Python (Python wrapper above CGAL and OpenCascade); possibly also use the Voxelization capabilities
- le the geometry during the import & transform
- Use PostGIS Geometry in the DB; PostGIS uses GEOS which can also be accessed via Shapely
- Use an external Tool when an Agent must perform adjustments
Transformation flow:
Execute a tessellation during the ingress flow
flowchart LR
AECTool --> IFC
AecGeo["Create Geometry"] --> AECTool
IFC --> Python
Python --> Tessellation
Tessellation --> Python
Python --> IfcJSON
IfcJSON --> Python
Python --> DB
style AecGeo fill:#148F77
style Tessellation fill:#a14b45
Execute tessellation or other transformation on an as-needed basis
flowchart TB
DbGeom["PostGIS Geometry"]
DbGeom --> DB
DB -- Read IfcJSON --> Python
Python -- Store IfcJSON --> DB
IfcGeom["IfcOpenShell Geometry<br/>incl. tessellate"]
IfcGeom --> Python
Python -- Export --> IFC
IFC -- Import in sub-bundle --> Python
IFC <-- Update --> ExternalApp["External Application<br/>e.g. Blender with Bonsai"]
IFC --> IfcViewer
ViewGeo["Visualize Geometry"]
IfcViewer --> ViewGeo
style ViewGeo fill:#148F77
style IfcGeom fill:#a14b45
style DbGeom fill:#a14b45
style ExternalApp fill:#a14b45
Impact on the data model
With PostGIS, we only need to add a column of type Geometry.
In the paper An IFC-based database schema for mapping BIM data into a 3D spatially enabled land administration database the authors have elected a model which maps key IFC entities and add a Geometry column to most of them.
In our Physical Data Model, we have elected to keep the number of tables quite small. We have one representation table to which we have added the Geometry column.
Further to that, the intent is to use the Geometry Column only for a limited number of object types, starting with IfcSpace and IfcSpatialZone.
In the IfcModels used as examples, we have observed a large variety of options used for representing an IfcSpace geometry. This variety will impact the mapping of the representation in the IfcJSON to the format used by PostGIS Geometry.
What we have in the data model is
erDiagram
object {
int bundleId "part of PK"
uuid objectId "part of PK"
string type
string name
array representationIds "array of str(uuid)"
json elementJson "contains the object placement data"
}
object ||--o{ representation : has
representation {
int bundleId "part of PK"
uuid representationId "part of PK"
string type
json elementJson "contains the shape representation data"
geometry geom "geometry column for PostGIS"
}
Technical References
- IfcOpenShell Geometry processing
- IfcOpenShell Geometry creation
- Voxelization Toolkit
- PostGIS Documentation
- GeoAlchemy2
- Shapely
- GEOS