Is there any restriction to use IfcRepresentationMap::MappingOrigin ? Now IfcAxis2Placement3D(origin (0,0,0),,) commonly used (all the buildingSMART examples use it) => Some downstream apps (CAD tools (even certified), viewers etc…) are unable to handle other than this.
In real BIM-projects observed whatever IfcAxis2Placment causing geometry interpretation errors. I would say, IfcRepresentationMap::MappingOrigin is duplicated with fcMappedItem::MappingTarget and thus redundant.
Couple of remarks:
I agree, mapped item is overly complicated, with two transformations, but I also see some use in them where with the first you can redefine an origin point (as part of the map) and the second matrix on the item then enables you to rotate around that point.
If you can share the file you that caused interpretation issues I think it’d very helpful. We have had several occasions on the forum where implementations were improved as a result of forum threads.
I think for IFC5 we need to decide for ourselves if we still want mapped items, or we only just allow representations to be shared directly. There are some cases where (nested) mapped items create efficient exchanges, but I’m personally not convinced it’s worth the added complexity and issues.
My biggest concern is that now some downstream applications (even certified ones) are unable to handle this correctly.
-Hannu-
I have also noticed that all applications cannot handle “mappingorigin” correctly. But I think that “mappingorigin” is needed, or at least our software needs it. One use case is when user using block definitions from DWG to create IFC model. In DWG format there are concepts “Block definition” and “Block reference”, Block definition is same as IFC IfcRepresentationMap and Block reference is same as IFC IfcMappedItem. Block definition has basepoint property which is often 0,0,0 but not always and Block reference has insertion point property. So, mappingorigin is needed, here is one model where it has been used: iv-kone.ifc (1.2 MB)
Hi, I think all has been said above. The reason, why to introduce the IfcRepresentationMap::MappingOrigin was to use the same mapped representation, i.e. the “block” or shape of an element geometry to be inserted, but to modify the insertion point (e.g. be centric by ground area, centric by volume, lower left front corner, etc). As @JPa said, I would have one shape of a pump, but can insert it centric, by inlet port point, outlet port point, etc.
Whether or not this may have taken the flexibility to far can be debated. But since it is legal and used today, it is difficult to restrict it now. So we need to emphasis to those, failing to correctly import that they need to improve.
Publishing the example file on the buildingSMART test case repository could be a first step. @jwouellette do you have instructions for how to do it?
If you have access to the Sample-Test-File repository on the bSI GitHub site, you should be able to make a request which I, @stefan.markic, @igor.sokolov, or @berlotti shoudl be able to approve.
The repository is open for everyone wishing to contribute. If you DM me your GitHub user name I can assign you the correct rights, if you’re not allowed to open a pull request - although that should be possible.
Be sure to include some sort of screen shots / other supplementary material in order to showcase what kind of content can be expected when interpreting the file.
Hi @Jpa - care to take a look if we’re interpreting your file correctly? There should be figures of the content from all possible angles submitted with the pull request.