LOIN and modeling question

Rick_Brice

I'm trying to improve my overall BIM knowledge. I read the Level of Information Need ISO 7817 document and learned from it that different information exchanges may have different information requirements. That's kind of obvious - but I wonder how this is implemented in practice.

One examples for this is Dimensionality of information. A pipe can be provided as a 1D line for length quantity takeoff purposes and a 3D volume for clash detection purposes.

How is this handled from a practical point of view? Would you create two distinct models, model the 3D representation because it is the more strenuous requirement, or somehow embed both representations in the same model?

If multiple representations are in the same model, how is that done? Is that related to an IfcProductRepresentation being able to have multiple Representations where each IfcRepresentation is associated with an IfcRepresentationContext with different RepresentationIdentifier and RepresentationType?

Moult

In practice we tend to break it down so that each project stage has requirements for geometry and non-geometry data (properties, classifications, relationships, etc).

Geometry defines the geometric detail of the object that we need for that particular project phase. This ranges from:

1. not needing any geometry at all (i.e. so long as it's captured as a database line item, it's cool) (e.g. fall arrest lines on roofs, sealant, backing rods...)
2. needing to know a single point coordinate or start/end lines (with +- tolerance) (e.g. existing landscape trees)
3. needing to know nominal bounding box dimensions (e.g. provisional spatials for equipment during concept stages)
4. needing to know generic body shapes (e.g. prior to product selection, during clash detection and design coordination stages, starting to get ballmark volumes, areas, and lengths for QTO)
5. needing to know specific manufacturer product body shapes with any critical geometries (e.g. during construction, where actual products are procured and certain parts of the shape are important for checking buildability, safety, etc)
6. needing to know everything such that it can be fed into fabrication equipment (e.g. mostly structural steel, custom joinery, etc)

This is given in a matrix for per project phase and per IFC class + predefined type. Others probably do variations along this theme, using acronyms if they feel like it (like LOD, LOd, LOG, LOIN, LOGN, LOIJFN, OLGNHL, ...).

In terms of parametric geometry to aid QTO (e.g. thou shalt use circular profiles so we can easily find out the radius) we probably would specify this in the future but right now we're quite lax and forgiving. IfcOpenShell can do quite a lot of clever tricks with QTO that saves us from being too pedantic on a topic most modelers don't know much about (representation context? huh?).

This is audited in terms of bulk QTO checks and visual checks.

Non geometric information is also specified, such as:

• quantities (we distinguish between quantities that you manually provide which is a non-geometric requirement, versus quantities that can be derived from geometry, which is a geometric requirement)
• containment (where is it?)
• system assignment (hot water? supply air? gas suppression?)
• names, descriptions
• types

This is audited typically using IDSes and schedules where IDSes fall short.