[IFC Tunnel] [Geotechnics] Uncertainty modeling

[larswik]

Input from geotech team:

• IfcShapeModel: the idea is that this is a regular geometric representation that plays a different role: it is not the exact geometry, instead it is part of a particular Scenario (maybe the Scenario is its representation context). A Scenario is a collection of particular assumptions about an uncertain situation, e.g. the position of a fault. Ensembles of Scenarios are supposed to span the range of relevant Scenarios for consideration. For example, one can have a Scenario for the “highest”, “lowest” and “average” position of a fault, each coupled with a representative geometry. Of course, this is just a suggestion. If you think that a new subtype of IfcProductRepresentation makes more sense, I see nothing that speaks against it.
• The UncertaintyTextureMap is supposed to represent the expert’s color-coded confidence in the geometry it is mapped to. For example, when mapped to a surface representing a contact, the texture could express the following: the lower the value in the blue channel, the less confidence we have in the representing geometry, and in reverse – the higher the value in the blue channel, the more confident we are that the geometry represents the actual contact surface. The same principle could be used for representing the distribution of other parameters over a 2d surface (e.g. magnetic properties). So this would be a new application of an already existing concept in IFC. Do you think this is a reasonable strategy?

[galina-p-tuwien]

After the meeting on 30th of May, 2022, we determined that there are at least two different ways to assign colour to geometry (as additional information carrier):

• per vertex colour

• texture mapping

[galina-p-tuwien]

For the definition of uncertainty values, we could use the (currently deprecated) complex property or a list / table propery:

• for interval values:

• for enumeration values

[galina-p-tuwien]

Additionally, also at the meeting on 30th of May, 2022, we discussed the following:

• For the mapping of uncertainty to the geometry as a colour, the correspondence between the colour and its semantics (meaning) can be put in a property set.

• The concept of scenarios and ensembles of scenarios can be implemented as follows: If we have scenarios A, B and C concerning geo-elements X and Y, we can put together an ensemble as a collection of IfcGeoScienceModel objects, each corresponding to scenario A, B and C, respectively. Each scenario contains IfcGeoScienceFeature objects, each corresponding to geo-elements X and Y, respectively. Within each scenario, the geo-element is represented by its own IFC object with its own property sets and geometric representations. This means that the same physical entity will have multiple representations as a IfcGeoScienceFeature object. The distinction between the different IfcGeoScienceModel objects can be done through their descriptions, e.g. “Gotech Model”, “Scenario A for model D”, etc.

[Airy59]

About the suggestion to use complex properties : why were these deprecated in the first place?

[larswik]

About the suggestion to use complex properties : why were these deprecated in the first place?

From what I can see here in the official documentation (IfcComplexProperty), it has not been deprecated yet. There is a GitHub issue concerning "NextGen", Issue, which obviously has no resolution yet. However, others (@SergejMuhic ?) might know more. From my personal point of view, the concept of complex properties can be quite useful in many cases (e.g. one suggested above which captures "Uncertainty interval" in a "by-value fashion"), similar to the "struct" concept available in some programming languages. However, the issue mentioned above, seems to indicate that the recursive nature of the IfcComplexProperty might not be well supported in current software?

[Airy59]

Talking about usage - geometries for instance are specified with tolerances, because things embodying the geometry may get deformed or wear down in the course of their lifetime. Measurements will be performed to see if things need repair or replacement. Actual things will be measured, and measures come with uncertainties. The entity in charge of maintenance needs to decide whether the (uncertain) measurement matches the (toleranced) nominal or acceptable value. The choice between complex type and property set representation of both tolerances or uncertainties also depends on whether property sets may be nested (contain other property sets). Say, the property set "observed length, height, width" with each value of complex type "Length range", possibly time-stamped (with date of measurement), to be matched with the property set "specified length, height, width", possibly versioned (with maintenance manual version).

I think too that complex types and Psets can carry the same semantics.

Are nested Psets feasible and acceptable in IFC?

Then, there would be remaining questions (about computing efficiency, ease of transformation and implementation...) that seem platform-specific to me, so I pass.

[galina-p-tuwien]

These are several examples of an uncertainty property set and how it could possibly describe uncertainty in other property sets attached to the same entity. Do you consider this a feasible solution?

And here is a complete example of uncertainty associated with a borehole interval:

[galina-p-tuwien]

Additionally, we need an entity describing uncertainty anywhere, as in the example below. These are uncertainties not associated with a particular model element or chainage and can be situated literally anywhere. We would need an object to be able to attach the information and location to. Could this generic uncertainty entity be included?

[Airy59]

Indeed, we need that. The world is not digital and most IT experts sometimes think about errors, but tend to forget about uncertainties that are essential to real-world engineering, eg. mechanical engineering. One of the many use cases is track layout and track maintenance, incl. predictive maintenance.

Airy Magnien

Envoyé à partir de Courrierhttps://go.microsoft.com/fwlink/?LinkId=550986 pour Windows

De : @.> Envoyé le :jeudi 26 janvier 2023 07:41 À : @.> Cc : Airy @.>; @.> Objet :Re: [bSI-InfraRoom/IFC-Specification] [IFC Tunnel] [Geotechnics] Uncertainty modeling (Issue #421)

Additionally, we need an entity describing uncertainty anywhere, as in the example below. These are uncertainties not associated with a particular model element or chainage and can be situated literally anywhere. We would need an object to be able to attach the information and location to. Could this generic uncertainty entity be included?

[grafik]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F41187423%2F214773157-b40fc18d-88b6-4b97-992d-b80e2062239d.png&data=05%7C01%7C%7Ce73f56c2353941f3ff6d08daff68635b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638103121043743853%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Tad%2FOI5%2BaFYJt0SobfGA7xl6ZH8gUgxUPuj8TntlaGo%3D&reserved=0

— Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FbSI-InfraRoom%2FIFC-Specification%2Fissues%2F421%23issuecomment-1404613595&data=05%7C01%7C%7Ce73f56c2353941f3ff6d08daff68635b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638103121043743853%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bn2t5R%2FkmR0lWqcSnvgTY0npLPDgZ6apyFp4bHWWYOE%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAHVZJMCYEUDDN35JDS2MDGTWUIMCNANCNFSM5WOU62FA&data=05%7C01%7C%7Ce73f56c2353941f3ff6d08daff68635b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638103121043743853%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RlbWBUHE0%2FtozqkL1uj7fPg1YjJQNwJl197HO63aqw8%3D&reserved=0. You are receiving this because you commented.Message ID: @.***>

[larswik]

Additionally, we need an entity describing uncertainty anywhere, as in the example below. These are uncertainties not associated with a particular model element or chainage and can be situated literally anywhere. We would need an object to be able to attach the information and location to. Could this generic uncertainty entity be included?

Could one option be to use IfcAnnotation with a new PredefinedType=.UNCERTAINTY.?

[galina-p-tuwien]

Could one option be to use IfcAnnotation with a new PredefinedType=.UNCERTAINTY.?

I think an annotation should suffice. Thanks!

[larswik]

For the uncertainty properties, I can see a couple of options (there may be more):

• One as described in the proposal.

  • Pros: Uses existing mechanisms.
  • Cons: a bit obscure with the property reference by name from another property in another Pset. Would need a Pset name as well.

• Define a separate IfcPropertyUncertainty entity including an attribute referencing IfcSimpleProperty (including an inverse attribute in IfcSimpleProperty). Maybe even add ability to connect to other entities?

  • Pros: Solid connection between property value and uncertainty. Doesn't affect serialization. Small extension to the schema.
  • Cons: Can be misused (e.g. attaching uncertainty to IfcText). Means extending the schema. UML diagram illustrating principle below. I didn't develop the typing of attributes here.

• Define a separate subtype of IfcSimpleProperty like figure below.

  • Pros: Conveys the information cleanly. Pure extension (nothing existing is being touched)
  • Cons: Means extending the schema.

[larswik]

@galina-p-tuwien: Can you check the discussion above? Questions:

• Preferred solution
  • My preference would be in the reverse listing order
• Only measure values?
• Can the uncertainty rating be predefined?
• Are there other ways to specify uncertainty?

[galina-p-tuwien]

• My preferred solution is the last one – it is very clear and cannot be misused as easily as the second one.
• I think there will be more than measured values, e.g. estimated, calculated according to various guidelines etc. Probably best to have a sort of predefined type attribute to cover that.
• The uncertainty rating can be predefined – e.g., as category 1 to 5, or it can be fairly loosely specified as an interval with upper and lower limit, or as a standard distribution with mean and variance, etc.
• The only other way I can think of is the one where an uncertainty is located somewhere as an object (i.e. your proposal with IfcAnnotation).

[Airy59]

Concerning the last solution :

• what is the relationship between attribute NominalValue and role UncertainValue ?
• I'm not sure I want to bind units with a property; I'd rather bind units with values. Maybe the rationale was to "factor out" the unit, and have the uncertain value and the uncertainty expressed, forcibly, with the same unit. That may be a small saving in memory space, but embedding a unit in a property makes little sense (semantically). Or is the unit only characterizing the Nominal Value only?
• "Nominal value" is a hazy term. A value may be specified in a specification, for instance, and be called "nominal". If the spec is amended, the nominal value becomes a superseded value. I won't put it there. See below:

Generally speaking:

• values of properties may be specified (with tolerances), measured (with uncertainties), or predicted (with confidence ranges): different terms, but measures should be able to be matched with specifications or predictions, and predictions should be derived from measures (using wear and tear laws or models)

I'd recommend:

• to keep this "bigger picture" in mind even though we only focus on specs vs. measurements, in the case of testing & commissioning, if I'm not mistaken;
• hence, to make sure it is possible to match any of the above "uncertain values"
• sticking to the terminology is probably important for the model to be understood, so maybe we have no choice but having the same pattern repeated in UML, just to keep class and role names aligned with engineering practice

[galina-p-tuwien]

@larswik: This is an example for uncertainty as a subtype of IfcSimpleProperty in the specific case of the GeoLogInterval (with very small changes).

[Airy59]

Is the underlying standard still ISO/TS 21749:2005 ?

[SergejMuhic]

@larswik: This is an example for uncertainty as a subtype of IfcSimpleProperty in the specific case of the GeoLogInterval (with very small changes).

What I do not understand is the connection from IfcUncertainty to an IfcPropertySet. I do not see it in @larswik diagram. It would also cause problems most likely. My understanding was that UncertInterval should cover that data.

[galina-p-tuwien]

@Airy59: No, this is a simplified version discussed in the Geo subgroup. @SergejMuhic: That is correct. This is the change I added in order to accommodate things like the lookup table without having to define a new type. But it is just a suggestion...

[larswik]

What I do not understand is the connection from IfcUncertainty to an IfcPropertySet. I do not see it in @larswik diagram. It would also cause problems most likely. My understanding was that UncertInterval should cover that data.

In my UML above, i didn't include the specifics for:

• UncertRating: a kind of uncertainty classification (maybe not predefined?)
• UncertInterval: the interval in which the value certainly (or most probably with a certain confidence?) resides. These needs to be specified!

The idea was to model these as explicitly as possible and would provide a kind of simple property (thus can be part of a Pset) with uncertainty without any "obscure pointers" between Psets. This kind of value could then be a part of any predefined or custom Pset and carries a value with its uncertainty (i.e. no "pointers" needed).

Shall we try to elaborate this approach?

[galina-p-tuwien]

Shall we try to elaborate this approach?

Yes, please. In the example I tested above I wanted to indicate that the types of uncertainty are not exhaustively covered by concepts like “rating” and “interval”. For that reason, I proposed a pset that can contain further details, but, as I said, it was just an attempt at greater flexibility. Should we compile a fixed list of possible uncertainty types in the Geo Subgroup?

[larswik]

Should we compile a fixed list of possible uncertainty types in the Geo Subgroup?

If this is possible, yes please!! If necessary, the proposed model could be extended with a couple of specific subtypes for IfcUncertainty (if this makes it better).