Upgrade to Pro — share decks privately, control downloads, hide ads and more …

IFC5: Adequate complexity maximum reliability

IFC5: Adequate complexity maximum reliability

Thomas Krijnen

June 30, 2022
Tweet

More Decks by Thomas Krijnen

Other Decks in Technology

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