IFC5: Adequate complexity maximum reliability

Transcript

1. IFC5
   Adequate complexity - maximum reliability
   

   View Slide

2. About us
   High-end consultancy on open standards and open source
   solutions in the built environment.
   

   View Slide

3. Complexity and scope
   (Schiphol Oct 2019)
   schema
   complexity
   intended
   scope
   coordination reference
   *
   **
   ***
   An ever growing schema with a more
   precise (=good) scope statement
   (mismatch is not good)
   Clearly communicated cumulative
   implementation levels with narrow or
   ambitious scope
   

   View Slide

4. From compromises to consistency
   IfcMaterialLayerSet
   IfcWall
   IfcWall
   IfcBuildingElementParts
   aggregation IfcCompositeProfileDef
   

   View Slide

5. Decomposition
   on many levels
   ✓
   ✓
   :( :(
   semantic
   associations
   possible impossible
   Workarounds: IfcMaterialLayerSetUsage IfcMaterialLayerSet IfcMaterialLayer IfcMaterialList
   IfcMaterialConstituentSet IfcMaterialConstituent IfcMaterialProfileSet IfcMaterialProfile
   IfcShapeAspect IfcMaterialProperties (10 supertypes!) IfcProfileProperties (2 supertypes!)
   IfcStyledRepresentation IfcMaterialDefinitionRepresentation IfcComplexProperty
   Note: A reason why sub-product
   decomposition became so popular is probably
   because it’s simple to reinstantiate.
   

   View Slide

6. Semantics
   Wall of text. No semantic markup. Ambivalent traits.
   

   View Slide

7. Trait-based “latebound” hierarchy
   (latebinding from ifc5 taskforce paper)
   uml
   schema
   express
   data
   json/xml
   UML attribute =
   express attribute
   UML attribute =
   IFC property
   Unifies inheritance, psets and concepts into a comprehensive mechanism. Enforce schema semantics.
   potentially load-
   bearing Y/N
   space bounding Y/N
   Concept: IfcSpace - IfcRelSpaceBoundary - IfcElement - IfcRelSpaceBoundary - IfcSpace
   IfcWall
   IfcColumn
   nb: examples are
   illustrative
   could require multiple
   inheritance in late-
   bound part
   largely eliminates
   “usages”
   

   View Slide

8. The problem of many roots
   IFC4 has 59 root classes: ['IfcActorRole', 'IfcAddress', 'IfcApplication', 'IfcAppliedValue', 'IfcApproval',
   'IfcBoundaryCondition', 'IfcConnectionGeometry', 'IfcConstraint', 'IfcCoordinateOperation', 'IfcCoordinateReferenceSystem',
   'IfcDerivedUnit', 'IfcDerivedUnitElement', 'IfcDimensionalExponents', 'IfcExternalInformation', 'IfcExternalReference',
   'IfcGridAxis', 'IfcIrregularTimeSeriesValue', 'IfcLightDistributionData', 'IfcLightIntensityDistribution',
   'IfcMaterialClassificationRelationship', 'IfcMaterialDefinition', 'IfcMaterialList', 'IfcMaterialUsageDefinition',
   'IfcMeasureWithUnit', 'IfcMonetaryUnit', 'IfcNamedUnit', 'IfcObjectPlacement', 'IfcOrganization', 'IfcOwnerHistory',
   'IfcPerson', 'IfcPersonAndOrganization', 'IfcPhysicalQuantity', 'IfcPresentationItem', 'IfcPresentationLayerAssignment',
   'IfcPresentationStyle', 'IfcPresentationStyleAssignment', 'IfcProductRepresentation', 'IfcProfileDef', 'IfcPropertyAbstraction',
   'IfcRecurrencePattern', 'IfcReference', 'IfcRepresentation', 'IfcRepresentationContext', 'IfcRepresentationItem',
   'IfcRepresentationMap', 'IfcResourceLevelRelationship', 'IfcRoot', 'IfcSchedulingTime', 'IfcShapeAspect',
   'IfcStructuralConnectionCondition', 'IfcStructuralLoad', 'IfcTable', 'IfcTableColumn', 'IfcTableRow', 'IfcTimePeriod',
   'IfcTimeSeries', 'IfcTimeSeriesValue', 'IfcUnitAssignment', 'IfcVirtualGridIntersection’]
   Trim down to suitable “top-level” definitions:
   Objects, Types, Relationships, Properties, Representations,
   Resources
   For example for representation in SQLite or ArangoDB
   

   View Slide

9. Objectified relationships, one to one
   Joining federated models Creating model subsets One to one pairs
   Containment node needs
   to be merged/recreated
   Containment node needs
   to be updated
   All good.
   Pure subset.
   

   View Slide

10. Dependency hell
    Making changes in complex graph structures can have undesirable
    cascading effects.
    Create clearly compartmentalized structures:
    Tree: Type (geom + pset) -> Product (placement + pset)
    Graph: Element <-> Element (connections)
    Tree: Containment + Decomposition + Hosting
    Other than that: minimize dependencies, create self-contained
    definitions
    

    View Slide

11. Self-contained elements
    with (schema-defined) parametric behaviour
    IfcPolyline
    IfcPolyline
    IfcLine
    IfcRel-
    Connects
    

    View Slide

12. Semantic well-understood geometry
    Some procedural geometry definitions obfuscate semantics
    and are ambiguous and not universally understood.
    Case in point:
    - IfcCraneRailAShapeProfileDef (deleted in IFC4)
    - IfcTrapeziumProfileDef (deprecated in IFC4.3)
    - (more)
    

    View Slide

13. Case in point (2):
    IfcExtruded/RevolvedAreaSolidTapered
    1. The conventional name for this is a loft. An interpolation of cross
    sections (over an Axis).
    2. Complex due to possibility of rotation
    3. Revolution + scaling results in a non-primitive, non-ruled surface that’s
    hard to understand
    4. “Given that the start and end section is provided by a polygon…”
    - no: could be any profile including curved
    5. “The start profile is defined by an arbitrary bounded curve bounding a
    plane and …”
    - no: probably mistake in where rule:
    No blame here. Advocating the point
    that creating well-understood geometry
    definitions is very very hard.
    IF ('IFCPROFILERESOURCE.IfcDerivedProfileDef' IN
    TYPEOF(EndArea)) THEN
    Result := (StartArea :=:
    EndArea\IfcDerivedProfileDef.ParentProfile);
    ELSE
    Result := FALSE;
    END_IF;
    

    View Slide

14. IfcRevolvedAreaSolidTapered
    The interoperable, flexible, semantic way
    Hint: Observe the similarity with IfcWall (Body + Axis) and infra alignment sweeps?
    IfcFlowFitting
    |
    IfcRelNests
    |
    IfcAnnotation (2)
    (or IfcPort)
    |
    IfcRelDefByProps
    |
    IfcPropertySet
    - IfcRepresentation
    (IfcCircle)
    - IfcRepresentation
    [Body]
    (explicit brep)
    + IfcRepresentation
    [Axis]
    - Radius=x
    nb: this is basically the
    transition from entity to
    “concept”
    the explicit body can act
    as shape validation
    

    View Slide

15. migrate
    Our responsibility
    An intelligent, sustainable, circular built environment.
    Requires queryable, meaningful, well-understood, up-to-date
    content and long-term preservation.
    ifc
    migrate migrate
    export :)
    import :( time
    open native
    ?
    (community effort, project-specific)
    (individual responsibility)
    

    View Slide

16. Conclusions
    Decomposition on element level as the generic mechanism.
    Uniform material and appearance means association of semantics
    can stay at element. Requires more intelligent instancing of types.
    Meaningful trait-based BuiltElement subtree informed by
    concepts
    Lower-dimensional geometric primitives to supplement
    interoperable, semantic and intelligent exchanges (as we have
    been doing since 2x)
    

    View Slide

17. Conclusions
    IFC is a versatile and powerful basis
    Mainly shift in focus. Conceptualization of procedural definitions is
    meaningful, but don’t obscure in entity but brake down into universally
    understood primitives plus “concepts”.
    Necessary breaking changes are mostly:
    - latebound BuiltElement (paper)
    - intelligent types: geometry, decomposition, recursive (paper)
    - cleanup of non-element-level subdivision approaches
    - reorganization of resources into 5 or 6 top level facets
    - normalization of relationships (paper)
    

    View Slide