search

buildingSMART / IFC4.3.x-development

Repository to collect updates to the IFC4.3 Specification
Other
168 stars 86 forks source link

Requirements on identify of non-rooted entity instances #570

Open aothms opened 1 year ago

aothms commented 1 year ago

In 4.3 Object Attributes we have stated:

Resource-level instances (not deriving from IfcRoot) do not have any identity, such that two instances having identical state are considered equal. For example, if an object has coordinates described by an IfcCartesianPoint instance, another object with the same coordinates may have a separate instance of IfcCartesianPoint or share the same instance; such difference is a matter of data storage optimization and does not imply any semantic relationship

http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Attributes/content.html

At the same time, we have implementer agreements that impose specific requirements on referencing the same instance

In case of IfcPolyline the first and the last point may be identical, then it indicates a closed polyline. In this case they shall be identical by reference (referencing the same instance of IfcCartesianPoint.

https://standards.buildingsmart.org/documents/Implementation/IFC_Implementation_Agreements/CV-2x3-111.html

These two statements contradict one another. Any ideas?

Moult commented 1 year ago

There are a number of these contradictions (especially in the 4D/5D domain) that make me no longer recommend optimisation through non-rooted entity reuse. Here is one example: https://forums.buildingsmart.org/t/can-anyone-confirm-whether-or-not-reuse-of-non-rooted-entities-applies-to-ifctasktime/3609

aothms commented 1 year ago

@Moult I tried to understand this issue before. Maybe you can't find the time, but a quick instance diagram sketch would really help to understand. You seem to imply, that something inversely related affects the interpretation of something. But isn't a saner interpretation that the "meaning" is simply only contained on the inversely related thing? A bit similar to a geometric representation: you don't know where it is located globally until it's paired with a placement. But that still means you can recycle cartesian points (just should never associated a global positioning to them mentally). (But I'm probably missing sth).

Moult commented 1 year ago

Ah yes upon rereading that's correct. It does make it very annoying for native authoring though to keep on having to check whether it's a non-rooted entity that has been assigned in a way that has some intention (e.g. 1 task time per task, or 1 pset per element, etc) or whether it's been recycled.