IDS checking attributes inherited from IfcTypeObject
A while back I had a conversation about IDS and filtering for userdefined types. Here's a link https://github.com/buildingSMART/IDS/issues/178#issuecomment-2649562586
From that conversation I (mistakenly?) learned, from an IDS perspective, that an IfcObject inherits from its IfcTypeObject.
With that in mind, I am trying to make a Specification that validates the Tag attribute of an object where the Tag attribute is defined on the related IfcTypeObject.
For the attached model and IDS, I want to check if all IfcSign.PICTORAL have a Tag that meets a pattern. Since the signs are standardized, I've put the Tag attribute on the IfcSignType, expecting each instance of IfcSign defined by the IfcSignType to inherit the value of the Tag attribute.
Why doesn't this work?
Comments
As I understand it, the definitions of the Tag attribute are a bit different.
IfcSignType:
"The tag (or label) identifier at the particular type of a product, e.g. the article number (like the EAN). It is the identifier at the specific level."
IfcSign:
"The tag (or label) identifier at the particular instance of a product, e.g. the serial number, or the position number. It is the identifier at the occurrence level."
The attribute in IfcSign does not inherit from IfcSignType.
A workaround could be Pset_ManufacturerTypeInformation.ModelReference, the only pset (that I found) with tag-like information that IfcSign inherits from IfcSignType.
That makes sense. Tag on the IfcSignType is the MUTCD code (R1-1 for a stop sign), Tag on the IfcSign is the product instance (Serial Number: 123ABC).
In general, do attributes on a type not get inherited by the instance using the type? There is a clear distinction between type attributes and instance attributes. And the PREDEFINEDTYPE discussion that led me down this path is a special case.
the following might be helpful too relative to the
tagattribute.Thanks
As far as an IDS is concerned, I think I want to make sure all IfcSign are defined by an IfcSignType and all IfcSignType have a properly formatted Tag.
Click on Object Information -> Object Metadata -> Attributes -> Edit (for a type and for an instance), you will see the difference and the attributes that are not inherited, there are few.
GlobalID and Name are obvious, Tag really leaves doubt, but Description I can't see a use case where the description of an instance would be different from the type... but there is always someone who will need it. :)
@Rick_Brice @walpa there seems to be a few misunderstandings here.
Pset_ManufacturerTypeInformation.ModelReferenceis the manufacturer's model number of a product (i.e. from their product catalogue).Pset_ManufacturerOccurrence.SerialNumber, which is the manufacturer's unique instance identifier. This is appropriate on an occurrence (hence the pset name).R1-1, then the appropriate place to store this is in IfcSignType's Name attribute.If none of that is what you're looking for, I had a look at the psets available for IfcSign{Type} and it looks like an omission by buildingSMART, which means you need to create your own pset. Maybe because MUTCD is not an international thing? I don't know. It seems used here in Australia too.
If it's going down the road of a custom pset, maybe we should look at publishing some of these known shortcomings as data dictionaries that our local buildingSMART government chapters can share and endorse.
Ultimately bSDD is our goal. A key piece of data is the MUTCD code. Each standard sign type has one. MUTCD is US Federal Highway Administration, Manual on Uniform Traffic Control Devices. With some googling, it looks like Australia has its own version of a similar standard. I suspect there are many similar standards around the world. I suspect at some point, there will be a base DD that handles all the common stuff and agency (country, state, etc) versions that build on top of the base DD.
As you know, I'm a beginner and I just jump in and try stuff. When I get confused, I ask questions. Thanks for the explanation.
My guess of why it's not in IFC is because it's not international. One thing I've been proposing in Aus is for buildingSMART Australia to be the steward of government / country-wide properties. So for example
bSA_Sign.MUTCDCodeI guess. Maybe you can propose abSUS_Sign.MUTCDCode? In bSDD we can relate the two together and ensure we match data types.I’m hoping eventually the BIM work going on in the US for infrastructure will ultimately develop a national data dictionary of signs. I would guess that all countries with standard signs would give a designation to each. The MUTCD code is a specific example of that more general concept.
In the US building Smart USA is working in close alignment with AASHTO and FHWA to achieve our BIM objectives.
This explanation seems more aligned with Name attribute. “ Optional name for use by the participating software systems or users.”
On IfcElementType, Tag = “ The tag (or label) identifier at the particular type of a product, e.g. the article number (like the EAN)”
On IfcElement, Tag = “ The tag (or label) identifier at the particular instance of a product, e.g. the serial number, or the position number”
@Moult , can you clarify?
Thanks