Georeferening IFC2x3, where are my ePset values?
IFC2x3 does not include the MapConversion mechanism that IFC4 introduced.
Therefore, applying geo‑location in IFC2x3 is preferably done using extended property sets (Psets). In theory, these custom Psets can be used in the same way as in IFC4.
However, I cannot find these Pset values anywhere in Blender Bonsai.
Where in Blender Bonsai can these property‑set values be viewed or edited?
Here is the snippet of the code for sample Schependomlaan NL
26=IFCSIUNIT(*,.LENGTHUNIT.,.MILLI.,.METRE.);
#1080894=IFCPROPERTYSET('1j0BKFYSHAawb_$qvTqZ$w',#1080893,'ePset_MapConversion',$,(#1080897,#1080898,#1080899,#1080900,#1080901,#1080902,#1080903));
#1080905=IFCPROPERTYSET('2pI55O_OX1WfSfmdlCRXM4',#1080904,'ePset_ProjectedCRS',$,(#1080908));
#1080897=IFCPROPERTYSINGLEVALUE('TargetCRS',$,IFCLABEL('EPSG:7415'),$);
#1080898=IFCPROPERTYSINGLEVALUE('Eastings',$,IFCLENGTHMEASURE(185542.),$);
#1080899=IFCPROPERTYSINGLEVALUE('Northings',$,IFCLENGTHMEASURE(428121.),$);
#1080900=IFCPROPERTYSINGLEVALUE('OrthogonalHeight',$,IFCLENGTHMEASURE(20.),$);
#1080901=IFCPROPERTYSINGLEVALUE('XAxisAbscissa',$,IFCREAL(1.),$);
#1080902=IFCPROPERTYSINGLEVALUE('XAxisOrdinate',$,IFCREAL(0.),$);
#1080903=IFCPROPERTYSINGLEVALUE('Scale',$,IFCREAL(0.001),$);
Comments
Its on the project. You need to click the project object in the outliner.
@magicalcloud_75
silly but honest question: wouldn't it be easier to upgrade the file to IFC4?
thanks
A screenshot to accompany Dion's comment.
I got confused when previously when editing spatial decomposition objects as I did not know I had to select them in the outliner:
Yes, that would be the easy way out — just stick your head in the sand :P
But we live in a BIM world that’s massively overloaded with IFC2x3 files. They need to be post processed for geolocation to begin with.
In my opinion, upgrading them to IFC for this purpose would be a very wrong approach and mistake.
. Would this be the right place? The values don't show here
@magicalcloud_75
tell me about it ;)
kindly advise if you will, why is it a wrong approach and mistake? I'd like to understand
thanks
Upgrading a model to IFC4 solely for georeferencing is unnecessary and creates the false impression that the file is a fully compliant IFC4 deliverable. In Dutch we would say “using a cannon to kill a mug".
A more honest and effective approach is to apply an extended property set to the existing IFC2x3 models and work with software vendors to ensure backward‑compatible support. (Not easy, i know..) But that way, the model stays true to its actual schema, and georeferencing is handled in a transparent, standards‑aligned way.
Still looking for these 2x3 values in Blender..
ePSet_ProjectedCRSproperty set defines the CRSyou have to also add
ePset_MapConversionproperty set to be able to add the data of the location:@magicalcloud_75
thanks for the info
I can see, 13 years after IFC4 was released (if I'm not mistaken) , there is a long way to go before implementing newer IFC standards..
like when people ask you to send a DWG 2013 version file :D
cheers
You are right. I don't think i will not be using IFC4x3 or IFC5 for a bridge in my lifetime..
Sorry but i still don't understand. The data is there in the file (attached sample). I don't to add any data, i want to check / read the available data.
Are we talking about the same mechanism?
@magicalcloud_75 I see. This file has these ePsets assigned to the IfcSite.
I am not sure whether it is a Bonsai bug that it offers these ePsets for creation for IfcProject instead of IfcSite or if that is correct. From experience when in doubt, Bonsai is right :)
According to this paper from 2020, it should be a property of IfcProject
https://www.buildingsmart.org/wp-content/uploads/2020/02/User-Guide-for-Geo-referencing-in-IFC-v2.0.pdf
It was discussed in relation to IfcSite here: https://forums.buildingsmart.org/t/geolocation-standards-in-ifc2x3-and-ifc4/2329/28
This sample 2x3 file has these ePsets assigned to IfcSite: https://github.com/Moult/ifc-test-files/blob/master/src/ifc-spf/geolocation-ifc2x3.ifc
I am not able to find anything in the schema documentation, but I am notoriously lousy at searching information there :)
@Moult would you be kind enough to clarify whether
ePset_MapConversionandePset_ProjectedCRSshould be assigned to IfcProject or IfcSite?Nice! Thanks @semhustej
Personally i would not care less what you put it under in the standard.
Scripts search the keywords so they don't mind either.
For the next guy or girl reading this. Under 'site' 'object' 'pset'
IfcProject can have multiple IfcSites, I am not sure if it would make sense (or if it is possible) for each site to use different CRS. I don't think it is possible to achieve in Bonsai UI.
So with this in mind it would make sense to use the above mentioned ePsets for IfcProject.
IfcProject is correct (as per the official buildingSMART published document), IfcSite is wrong (it was considered at an earlier stage hence the discussion and the test file, but is no longer relevant).
@magicalcloud_75 you might want to fix your file by copying the pset over to the IfcProject.
Having it on IfcProject is important because 1) it guarantees it exists even if there is no IfcSite 2) there may be multiple IfcSites which may contradict or omit data 3) it is the closest match to the actual IFC4/4X3 location, which is related to the project. Software will also implement it on the IfcProject, not the IfcSite, e.g. IfcOpenShell will not check IfcSite.
Thanks @Moult
So we can conclude the site puts the addition information for IFC2x3 in a wrong place. Nice to know
i will report this back to the developers of the site. geo.buildingsmart.nl
After more than 30 years of IFC2x3 location is still not working properly .. :)
@Moult btw this is not a test file from back then, the IFC2x3 was 'freshly' geo-referenced using the BuildingSmart NL tool. Did you get a change to check the results?
ifc-georeferencer-Massamodel S1_28992.ifcis incorrect because it applies the properties to the site. It should apply the properties to the project instead.The BuildingSmart checker doesn't ppo up this 'error'.
Georeferencing never was very strong supported in IFC.
Can we help fix this?
I would guess BuildingSMART expects IFC 2x3 to not be georeferenced.
Yes, i guess.:) And i guess that BuildingSmart never officially implemented the idea they came up with. Just move foward and don't look back. Long live IFC5
No, the reason is because the validator is an automated tool and relies on automated computer descriptions of behaviour to run. This means it can check things like SPF syntax (ISO10303-21), IFC schema, where rules, and then gherkin definitions of implementation behaviour. So naturally the low hanging fruit is the fully automated stuff, and the next priority are the human conventions that need to be transcribed into code.
The biggest bucket of human conventions are known as "implementer agreements" which everybody agrees is not a great approach (i.e. computer definition is better than ambiguous human agreement) but was popular during IFC2X3. So that was tackled first. Fallback georeferencing for IFC2X3 is unique and as far as I know the only backwards compatible proposal of its kind, and therefore missed as a human definition.
I have reported a bug for it to be included: https://github.com/buildingSMART/validate/issues/310