Open aothms opened 2 years ago
Proposal for classification association:
It sounds as though the only parameterisation is in IfcDistributionControlElement. The relationships are all about external references.
Edit: evidence is because in IFC2X3 the original usecase was an attribute known as ControlElementId with this description "The ControlElement Point Identification assigned to this control element by the Building Automation System"
There are three types of external references (I copy pasted key bits of existing doc descriptions):
I disagree with the current usage of classification. IP addresses, MAC addresses, BACnet Object Identifier in a Building Automation System etc is not a hierarchical tree that classifies information - it may be a tree that signifies network setup, but not the information you are referencing in the network. So the whole concept of "tokens" in a classification system which denote hierarchy is not meaningful. This statement is makes no sense in terms of information to a user: "oh this element is on 127.0.0.1 so the parent classification of similar elements must be 127.0.0".
The problem is that the alternatives aren't very good either. Documents are not correct. It's clearly a different concept.
By process of elimination we should use a library reference - in the original usecase, a Building Automation System would be the external data library, and you'd refer to a key within that system. But there are still problems:
That said, I still think it's good to keep classification of objects separate from what I call "How elements are linked to external systems". I'd propose introducing formal concepts for library references, and rewording the library descriptions so that a revision control system is just one example of the systems you can link to, but BACnet et all are good examples of other systems.
So the parameterisation would disappear, and be merged into the docs as guidelines in IfcLibraryReference or in the newly added Library Association concept.
I actually asked this to @jmirtsch in the past: "How would I associate an IFC element to say a Brickschema dataset"? After looking at the three external reference types, we came to the same conclusion.
Thoughts?
Issue reported by @Moult
Annotation_IfcGeometricCurveSet_Annotation2D
Any point or curve
Issue:
Not rendered in HTML. Reason is that the parametrization contradicts the definition of the template. So I skipped it.
This is reported here https://github.com/buildingSMART/IFC4.3.x-development/issues/113
Solution:
Proposal for classification association:
Thanks for clearly outlining the issue.
The problem is that the alternatives aren't very good either
How about a property set? It seems as if that would be inline with how similar meta-data is expressed. I'd also consider an IP address maybe a (somewhat even potentially dynamic) property of an element. It certainly doesn't classify it.
And a tangent
IfcDistributionControlElement
If we make it a pset we should probably make it applicable also to things like:
IfcCommunicationsAppliance and IfcMobileTelecommunicationsAppliance
If it were a property set, it would have to be applied to a lot of stuff. It's definitely not restricted to distribution control elements. It would extend to spatial elements, and IfcProcess for sure (at least for systems like Brickschema).
Proposal for constraint association:
All the 4 out of 5 constraints make sense to me, and in fact in the process of implementing. One of them I think could be a duplicate but I need a closer look. But I'm not sure what your question is. Perhaps I can explain what they are to you (verbally if necessary) and you can make a call on what needs to be done.
In short, it describes scheduling constraints. For example, if I change the amount of work to be done in a task, there are two possibilities: either it takes longer to complete the task, or I need to employ more resources to achieve it in the same duration. These constraints describe exactly how to express it in IFC using IfcConstraint.
Admittedly there is an element which I noticed the other day (IfcReference) which has some outdated and just incorrect documentation. Maybe that is what is causing your validation to fail or other confusion? I will fix the incorrect docs, but let me know if a verbal explanation helps.
For control assignment:
I know about half of these in detail, and the other half I know the theory but never implemented. I'm not quite sure what the question is again sorry. I'm looking in the IFC4 docs and it seems as though there are two ways of presenting the information depending on whether the second column is filled in in your spreadsheet. I'm not sure which approach is preferred, or what the distinguishing factors are to choose parameterisation or non parameterisation.
IfcProcess for sure (at least for systems like Brickschema).
Groovy. I wouldn't see how a process can have an IP or BACnet id, but I guess it's a matter of how you map things. General pset is fine to me.
But I'm not sure what your question is.
Twofold.
(a) When we document parametrizations like this the implicit or explicit meaning is also that other elements wouldn't use this concept as part of "General Usage" (whatever that may mean, there's different interpretations of that, but I would see it as the union of all MVDs, with certain areas less elaborated than a specific MVD). Are we saying that we don't foresee other elements to use constraints? If the rows in this association table are just examples, then I think it should be that, an example file or something else not too normative.
(b) The parametrization table doesn't make a lot of sense.
IfcConstructionResource
Parameters="DataValue=IfcPositiveRatioMeasure;Attribute1=Usage;Attribute2=ScheduleUsage;"
Parameters="DataValue=IfcDuration;Attribute1=Usage;Attribute2=ScheduleWork;"
IfcTask
Parameters="Constrained Attribute=TaskTime.ScheduleStart;"
Parameters="Constrained Attribute=TaskTime.ScheduleFinish;"
Inconsistent between the two entities. Attribute2
I can't find in the template. Constrained Attribute
makes even less sense I think.
How about this proposal then:
Solution:
After verbal discussion:
Classification: will convert to library.
Constraint:
Control:
Element Nesting:
@aothms are we missing a diagram for element connectivity? The reason I ask is because there is this quote on IfcWall's docs:
Walls with openings that have already been modeled within the enclosing geometry may use the relationship IfcRelConnectsElements to associate the wall with embedded elements such as doors and windows.
This sounds very suspiciously similar to Element Nesting. In fact, I would say that perhaps IfcRelConnectsElements is more descriptive than "nesting", and can work for signs on doors or whatever.
are we missing a diagram for element connectivity
Related https://github.com/buildingSMART/IFC4.3.x-development/issues/186
If there's time I indeed think It's a good way to unambiguously show the direction wrt Related/Relating ConnectedFrom/To
One potential complexity is that we have both inheritance on the level of template (well mostly table of content like subdivision) inheritance of the applicable entity and also inheritance of the relationship (IfcRelConnectsElements) have subtypes with their own related template. Potentially that could be a confusing mix, but I'm not sure if it has an actual impact on anything.
By the way, to solve the constraint one instead of writing documentation to cover it, I'll just convert them into diagrams since that explains it much clearer. Here's a snapshot from IFC2X3 when they actually did have diagrams (every other concept usage for these things have diagrams... except for the constraints, which were lost in the 2X3->4 transition) - maybe explains why in IFC4 there were invisible tables that had captions but no content, maybe a bug in IFC4.
Anyone for anyone's interest here is a good example of a constraint diagram - it will take me a little time to audit them and ensure they accurately portray the IFC4 constraint concept usages:
Here is the completed table for controls
RelatingControl | RelatedObject |
---|---|
IfcActionRequest | IfcActor |
IfcControl | IfcObjectDefinition |
IfcCostItem | IfcProduct |
IfcCostItem | IfcProcess |
IfcCostItem | IfcResource |
IfcCostItem | IfcTypeProduct |
IfcCostItem | IfcTypeProcess |
IfcCostItem | IfcTypeResource |
IfcCostSchedule | IfcCostItem |
IfcCostSchedule | IfcActor |
IfcEvent | This is wrong, should be the row below because IfcEvent is not the RelatingControl |
IfcWorkCalendar | IfcEvent |
IfcPerformanceHistory | IfcGroup |
IfcPerformanceHistory | IfcProduct |
IfcPerformanceHistory | IfcProcess |
IfcPerformanceHistory | IfcResource |
IfcPermit | IfcActor |
IfcProcedure | This is wrong, should be the row below because IfcProcedure is not the RelatingControl |
IfcWorkCalendar | IfcProcedure |
IfcProjectOrder | IfcActor |
IfcProjectOrder | IfcTask |
IfcTask | This is wrong, since IfcTask is not the RelatingControl |
IfcWorkCalendar | IfcWorkCalendar |
IfcWorkCalendar | IfcTask |
IfcWorkControl | IfcTask |
IfcWorkSchedule | IfcTask |
IfcWorkSchedule | IfcActor |
Here's the table for Object Nesting:
RelatingObject | RelatedObjects |
---|---|
IfcActionRequest | IfcActionRequest |
IfcAlignment | IfcReferent |
IfcConstructionResource | IfcConstructionResource |
IfcCostItem | IfcCostItem |
IfcEvent | This is wrong, IfcEvent is not the RelatingObject – see row below |
IfcTask | IfcEvent |
IfcPermit | IfcPermit |
IfcProcedure | IfcTask |
IfcProjectOrder | IfcProjectOrder |
IfcTask | IfcTask |
IfcTask | IfcProcedure |
IfcTaskType | IfcTask |
IfcWorkSchedule | IfcWorkSchedule |
Note that there are a few ones debatably missing from this table. For example, should an IfcTaskType also be able to nest IfcEvents and IfcProcedures? Potentially yes (it's not written in the docs, but I feel as though the intention is there). I haven't implemented that part yet so I can't say with 100% certainty, so keep in mind that this table may need some additions in the future.
Here's the review on Port Nesting:
IfcDistribution port has this description, I've annotated it inline:
[The ]()Port Nesting concept applies to this entity.
Sure. I personally reckon these sentences are superfluous and should be deleted.
Distribution ports are indicated on products and product types using the IfcRelNests relationship where RelatingObject refers to the enclosing IfcDistributionElement or IfcDistributionElementType respectively. The order of ports indicates logical ordering such within outlets, junction boxes, or communications equipment.
This sentence does not sound correct. This is not the Port Nesting concept. This is the Element Nesting concept. This sentence should be taken out of this concept usage, and put into the Element Nesting section.
Ports may be further nested into sub-ports, for indicating specific connections on components or pins.
Not an MEP person. Seems plausible. But I have no idea what the allows subport combinations would be.
a. I don't believe sup-port nesting has ever been used. b. However, consider a UK small-power plug and a socket. These can be represented as a port-to-port connection. If necessary the each port, one on the plug and one on the socket could be dis-aggregated into three sub-ports, one for live, one for neutral, one for earth. c. Given the increased interest in off-site, modular construction of multiple service frames, it could make sense to have a port to control how the frames fit together and then sub-ports for the individual pipes, wire harnesses and ducts to ensure continuity. d. My suggestion would be to keep the possibility open.
Product Placement review:
The concept usage 'Product Placement' for entity 'IfcProduct' in MVD 'GeneralUsage' is not modeled in UML
Will just move docs to ObjectPlacement attribute. Makes more sense there.
Property sets for objects:
The concept usage 'Property Sets for Objects' for entity 'IfcObject' in MVD 'GeneralUsage' is not modeled in UML
Nothing meaningful. Already repeated in IfcPropertySet docs. Deleted.
Quantity sets:
The concept usage 'Quantity Sets' for entity 'IfcDistributionElement' in MVD 'GeneralUsage' is not modeled in UML
Nothing new. Deleted.
Ports may be further nested into sub-ports, for indicating specific connections on components or pins.
Not an MEP person. Seems plausible. But I have no idea what the allows subport combinations would be.
a. I don't believe sup-port nesting has ever been used.
I think the idea is also valid and maybe at that time when we really start using it should be a different (hierarchical) template. Is there any way we can just move this one statement on sub-ports to the documentation of IfcDistributionPort itself?
This table is for Spatial Decomposition, but if you read it right to left you get Spatial Composition :)
RelatingObject | RelatedObjects |
---|---|
IfcProject | IfcSite |
IfcProject | IfcBuilding |
IfcProject | IfcFacility |
IfcProject | IfcBridge |
IfcProject | IfcMarineFacility |
IfcProject | IfcRailway |
IfcProject | IfcRoad |
IfcProject | IfcExternalSpatialElement |
IfcProject | IfcSpace |
IfcSite | IfcSite |
IfcSite | IfcBuilding |
IfcSite | IfcFacility |
IfcSite | IfcBridge |
IfcSite | IfcMarineFacility |
IfcSite | IfcRailway |
IfcSite | IfcRoad |
IfcSite | IfcExternalSpatialElement |
IfcSite | IfcSpace |
IfcExternalSpatialElement | IfcExternalSpatialElement |
IfcBuilding | IfcBuilding |
IfcBuilding | IfcBuildingStorey |
IfcBuilding | IfcSpace |
IfcBuildingStorey | IfcBuildingStorey |
IfcBuildingStorey | IfcSpace |
IfcSpace | IfcSpace |
IfcFacility | IfcFacility |
IfcFacility | IfcFacilityPartCommon |
IfcFacility | IfcSpace |
IfcBridge | IfcBridge |
IfcBridge | IfcBridgePart |
IfcBridge | IfcSpace |
IfcMarineFacility | IfcMarineFacility |
IfcMarineFacility | IfcMarinePart |
IfcMarineFacility | IfcSpace |
IfcRailway | IfcRailway |
IfcRailway | IfcRailwayPart |
IfcRailway | IfcSpace |
IfcRoad | IfcRoad |
IfcRoad | IfcRoadPart |
IfcRoad | IfcSpace |
IfcFacilityPartCommon | IfcSpace |
IfcBridgePart | IfcSpace |
IfcMarinePart | IfcSpace |
IfcRailwayPart | IfcSpace |
IfcRoadPart | IfcSpace |
Spatial Container & Spatial Containment:
My feel is that this should be the rule and not go into any further detail:
RelatingStructure | RelatedElements |
---|---|
IfcSpatialElement | IfcAnnotation |
IfcSpatialElement | IfcElement |
IfcSpatialElement | IfcLinearElement |
IfcSpatialElement | IfcPositioningElement |
just a note - the concept usage (or general usage) at least in IFC4.0 time frame was never done in a complete fashion, meaning that if a concept usage is not specified, it is illegal. Rather it has been used to enhance the documentation, meaning that here it shows a particular importance (or just, someone was interested in it).
I just note this, so there is no surprise that many of such general usages are missing. I also assume that this work to improve will take more time and can continue after the March deadline.
meaning that if a concept usage is not specified, it is illegal. Rather it has been used to enhance the documentation ...
Wait, it is illegal or it is not illegal? :)
sorry - "if a concept usage has not been specified, it does not mean, that it is illegal" (absence does not mean disallowed)
A note @aothms not sure if you've done it already but I updated the table in https://github.com/buildingSMART/IFC4.3.x-development/issues/403#issuecomment-1059089846
@TLiebich I'm fully agreeing on that statement. Do you have an idea on how we can put that into words? For example as a sentence above the "General Usage" table in the concept pages [0]. Ideally it should cover these three cases in the same statement:
Here's an attempt:
Concepts may have particular importance to common or standardised industry practices and scenarios. The table below shows a recommended list of general usage patterns that users may adopt.
I think it's good. The question perhaps is whether it needs a bit more explanation, such as:
The concept diagram above provides a generic mechanism to fulfil such practices and scenarios. The rows in this table establish specific uses of these templates, which may be further documented on the individual pages referred to.
Ugh
Edit: meant to be combined with the above
Righto, here's an attempt to merge - with the intention to display like this:
X.X.X.X Concept Title Foo Bar
Blah blah blah description
The following diagram shows the generic classes and relationships used when applying this concept. In addition, concepts may have particular importance to common or standardised industry practices and scenarios. For these specific usage scenarios, the table below shows a recommended list of general usage patterns that users may adopt.
[diagram]
General usage
[table]
I tried to keep the language simple so I avoided terms like template.
Wonderful. Is it an idea to just write it in the template.html instead of appending to each and every markdown. Maybe with some intelligence to check if there is actually a diagram and a table? Well, you decide.
Done - not the cleanest templating but does the job.
Consolidated list of material set names:
Class | Name |
---|---|
IfcActuator | Casing |
IfcAirTerminalBox | Casing |
IfcAirTerminal | Casing |
IfcAirToAirHeatRecovery | Casing |
IfcAirToAirHeatRecovery | Media |
IfcAlarm | Casing |
IfcAudioVisualAppliance | Casing |
IfcBoiler | Casing |
IfcBurner | Casing |
IfcBurner | Fuel |
IfcCableCarrierFitting | Casing |
IfcChiller | Casing |
IfcChiller | Refrigerant |
IfcCoil | Casing |
IfcCommunicationsAppliance | Casing |
IfcCompressor | Casing |
IfcCompressor | Refrigerant |
IfcCondenser | Casing |
IfcCondenser | Refrigerant |
IfcController | Casing |
IfcCooledBeam | Casing |
IfcCoolingTower | Casing |
IfcCoolingTower | Fill |
IfcDamper | Blade |
IfcDamper | Frame |
IfcDamper | Seal |
IfcDistributionChamberElement | Base |
IfcDistributionChamberElement | Cover |
IfcDistributionChamberElement | Fill |
IfcDistributionChamberElement | Wall |
IfcDoor | Lining |
IfcDoor | Framing |
IfcDoor | Glazing |
IfcDuctSilencer | Casing |
IfcElectricAppliance | Casing |
IfcElectricDistributionBoard | Casing |
IfcElectricFlowStorageDevice | Casing |
IfcElectricGenerator | Casing |
IfcElectricMotor | Casing |
IfcElectricTimeControl | Casing |
IfcEngine | Casing |
IfcEvaporativeCooler | Casing |
IfcEvaporativeCooler | Media |
IfcEvaporator | Casing |
IfcEvaporator | Refrigerant |
IfcFan | Casing |
IfcFan | Wheel |
IfcFilter | Casing |
IfcFilter | Media |
IfcFireSuppressionTerminal | Casing |
IfcFireSuppressionTerminal | Damping |
IfcFlowInstrument | Casing |
IfcFlowMeter | Casing |
IfcFurniture | Finish |
IfcFurniture | Frame |
IfcFurniture | Hardware |
IfcFurniture | Padding |
IfcFurniture | Panel |
IfcHeatExchanger | Casing |
IfcHumidifier | Casing |
IfcInterceptor | Casing |
IfcInterceptor | Cover |
IfcInterceptor | Strainer |
IfcJunctionBox | Casing |
IfcLamp | Bulb |
IfcLamp | Conductor |
IfcLamp | Filament |
IfcLightFixture | Casing |
IfcMedicalDevice | Casing |
IfcMotorConnection | Casing |
IfcOutlet | Casing |
IfcOutlet | Conductor |
IfcOutlet | Surface |
IfcProtectiveDevice | Casing |
IfcPump | Casing |
IfcPump | Impeller |
IfcPump | Seal |
IfcRailing | |
IfcSanitaryTerminal | Casing |
IfcSensor | Casing |
IfcSolarDevice | Casing |
IfcSpaceHeater | Casing |
IfcStackTerminal | Casing |
IfcSwitchingDevice | Casing |
IfcSwitchingDevice | Conductor |
IfcSwitchingDevice | Surface |
IfcSystemFurnitureElement | Finish |
IfcSystemFurnitureElement | Frame |
IfcSystemFurnitureElement | Hardware |
IfcSystemFurnitureElement | Padding |
IfcSystemFurnitureElement | Panel |
IfcTank | Casing |
IfcTransformer | Casing |
IfcTubeBundle | Casing |
IfcUnitaryControlElement | Casing |
IfcUnitaryEquipment | Casing |
IfcValve | Casing |
IfcValve | Operation |
IfcVibrationIsolator | Casing |
IfcVibrationIsolator | Damping |
IfcWasteTerminal | Casing |
IfcWasteTerminal | Cover |
IfcWindow | Lining |
IfcWindow | Framing |
IfcWindow | Glazing |
IfcCableFitting | Casing |
IfcCableFitting | Conductor |
IfcCovering | Front |
IfcCovering | Fill |
IfcCovering | Back |
IfcDuctFitting | Casing |
IfcDuctFitting | Coating |
IfcDuctFitting | Insulation |
IfcDuctFitting | Lining |
IfcPipeFitting | Casing |
IfcPipeFitting | Coating |
IfcPipeFitting | Insulation |
IfcPipeFitting | Lining |
IfcCableCarrierSegment | Casing |
IfcCableSegment | Conductor |
IfcCableSegment | Insulation |
IfcCableSegment | Screen |
IfcCableSegment | Sheath |
IfcCovering | Trim |
IfcDuctSegment | Casing |
IfcDuctSegment | Coating |
IfcDuctSegment | Insulation |
IfcDuctSegment | Lining |
IfcPipeSegment | Casing |
IfcPipeSegment | Coating |
IfcPipeSegment | Insulation |
IfcPipeSegment | Lining |
IfcReinforcingBar | Core |
IfcReinforcingBar | Coating |
IfcBeam | LoadBearing |
IfcColumn | LoadBearing |
IfcCovering | Lining |
IfcCovering | Finish |
IfcMember | LoadBearing |
IfcPlate | LoadBearing |
IfcSlab | LoadBearing |
IfcSlab | Insulation |
IfcWall | LoadBearing |
IfcWall | Insulation |
I also checked on Spatial Containment again, in terms of docs, the vast majority have a copy pasted paragraph that simply states the containment is mutually exclusive with aggregation (i.e. appears once in the spatial hierarchy).
More than happy to purge these copy pasted paragraphs and mention it once in the concept doc page.
Aggregation
Two issues here:
Solution:
Axis 2D Geometry
Solution:
Body Geometry
Issues:
Solution:
Body Tessellation Geometry
Issue:
Solution:
Classification Association
Issues:
Solution:
Constraint Association
Issues:
Constrained Attribute=
does not relate to a defined term it seems.Solution:
Control Assignment
Issue:
Solution:
Element Nesting
Issue:
Solution:
Group Assignment
Issue:
IfcGroup -> IfcRel -> IfcProduct
. This is wrong in two ways (a) I think it should be reversed (b) the entity on the right now should not be IfcProduct (IfcGroup isn't an IfcProduct) but IfcObject probably.Solution:
Material Constituent Set
Issue:
Solution:
Material Layer Set Usage
Issue:
Solution:
Material Profile Set Usage
Issue:
Solution:
Object Nesting
Issue:
Solution:
Object Typing
Issue:
Solution:
Note that this will also be reflected in the entity where rules that are derived from the ObjectTyping concept.
Port Nesting
Issue:
Solution:
Product Local Placement
Issue:
Solution:
Product Placement
Issue:
Solution:
Property Sets for Objects
Issue:
Solution:
Quantity Sets
Issue:
Solution:
Spatial Composition
Issue:
Solution:
Spatial Container
Solution:
Spatial Containment
Issue:
Solution:
Alternative solution:
Spatial Decomposition
Solution:
Type Body Geometry
Issue:
Solution: