Open pipauwel opened 4 years ago
Can't we make them ENTITIES with attributes?
Note the implication here, that then
#1 = IfcSite(...., (1,2,3))
becomes
#1 = IfcSite(...., #2)
#2 = IfcCompoundPlaneAngleMeasure(1,2,3)
This is bad new for IfcIndexedPolyCurve
. By using TYPE IfcArcIndex the entire curve can be defined in one entity instance as opposed to spread out over multiple references when using ENTITY.
Whether we need IfcIndexedPolyCurve is a 2nd question, as it can only cover a subset of geometries that IfcCompositeCurve can describe, although the latter a bit less efficiently.
lets come back to the original question. What is the source of the issue:
to have defined types being aggregates? or to have attributes with a defined data type being an aggregate?
in the above case, one other solution could be:
ENTITY IfcSite
SUBTYPE OF (IfcSpatialStructureElement);
RefLatitude : OPTIONAL LIST[3:4] OF INTEGER;
RefLongitude : OPTIONAL LIST[3:4] OF INTEGER;
RefElevation : OPTIONAL IfcLengthMeasure;
LandTitleNumber : OPTIONAL IfcLabel;
SiteAddress : OPTIONAL IfcPostalAddress;
END_ENTITY;
regarding IfcIndexedPolyCurve
- this is strange - the entity had been introduced on IFC4.0.1 as a request to simplify IFC (same as the overall theme for this thread) and now removing it again for simplification?
At that time, we did an extensive survey - see here: IFC4_Add1_IndexedPolyCurve_Definition.pdf
Principle agreement on this. Find solutions case-by-case.
PS: keep IfcIndexedPolyCurve, but on two (or three) star conformance level
There are very few TYPEs equivalent to a collection (LIST, ARRAY, SET). Examples are:
I suggest to encode these differently. As a result, we can likely more easily translate all TYPEs to known datatypes in other languages (e.g. xsd:dateTime, xsd:integer, etc.), rather than having to encode exceptions for these particular cases. Can't we make them ENTITIES with attributes?