Export with PsetMapping - Unwanted Unit Conversion Occurring

[JulesBuh]

Unwanted Unit Conversion Occurring

When exporting the type parameters using the property set mapping the NominalLength, NominalWidth and Nominal Height converts the values to feet, whilst the source attributes are written in millimeters as expected.

Ifcxml

Original Params in one part of the ifc (exporting the Revit Parameters as property sets)

Mapped Params in another part of the ifc (exporting the Mapped Parameters using the IFC2x3 Extended FM HandOve View.txt )

Ifc

At first I thought it was just ifcxml, but then checked the ifc output and the same appears there too.

Original Params in one part of the ifc (exporting the Revit Parameters as property sets)

Mapped Params in another part of the ifc (exporting the Mapped Parameters using the IFC2x3 Extended FM HandOve View.txt )

[JulesBuh]

... I should have added that I had already checked the unit assignment is millimeters. The concerning thing is that there isn't even any indication that this had been converted and no record in the SIUnits with a reference against the value, so to someone who would bring this into COBie and be expecting this information to be correct, this would be a major issue in UK delivery of projects. Had there been an indication that this was recorded in feet, you would at least know that you could do a conversion, but in the absence of a reference to a Conversion Unit you can't even assume the properties need correcting because unmapped parameters direct from Revit report in the correct Project Units.

[jmirtsch]

Thanks for reporting. This one should be easy to resolve and shouldn't require code changes. The FM property exporting mapping file seems to have been created prior to the expansion of nominating the nature of the property (such as length), and nominated these properties as numbers (reals). Hence no scaling or consideration of units (You can see the numeric value is an IFCREAL). I've set up a pull request here to revise this: https://github.com/jmirtsch/revit-ifc/commit/90efd019c73cdc1f082df13bc6c024984c6226ff

You can make the changes locally in your local copy of the property mapping file in the interim. Post a reply if it doesn't resolve the scaling.

[JulesBuh]

Thanks for the response. To clarify can I use any of the IFC types in the mapping file to nominate I.e. http://www.buildingsmart-tech.org/ifc/IFC4x1/final/html/annex/annex-b/alphabeticalorder_definedtypes.htm and would I exclude or include IFC at the front?

[jmirtsch]

It doesn’t handle them all yet. I didn’t explicitly check what was enabled but I did include those known to be enabled from another file. Of course they can be expanded in the source code if others are needed.

There’s also been some prototyping and exploration of custom user interface to set these values such as enumerations or dates etc. Also on how to map multiple parameters to one property (ie first found from list)

[JulesBuh]

Yes, I suppose the types that might have difficulty are the ones that aren't expressed as single values such as complex numbers and compound plane angle - you'd surely need a few revit params to map to one property or perhaps some kind of string syntax to capture in a single field with delimeter notation?

Thanks for your help, I'll check out your advice.

Is there a branch for the prototype interface? I'd be happy to give it a go.

[jmirtsch]

Complex properties was another concept I meant to mention. The advanced mapping being able to construct complex properties from multiple parameters was another idea to enable with this provision.

The branch with this work isn't on a public repo yet, but I can enable it as a branch on my fork (or I'll discuss with Angel about a branch here).

[JulesBuh]

I've updated the FM file to suit and it works.

I'm curious about two other things, if the data type has already been defined in the shared parameter or project file, whether its necessary to also define it again in the pset mapping?

Secondly just on the logic for Type and Instance, If I have an object with a Type parameter and an Instance Parameter of the same name (but different guid so both can exist in the project), would I be able to set it so that primarily the instance gets sent to the pset, but if the field is null the type version of the same name goes there instead.

The practical example is as follows: A door manuafacturer has provided their fire rating for the product in general. It is therefore a type parameter as all doors of the same type have a firerating. However from a design perspective some of the doors don't need to be fire rated, (they are essentially the same door type so they were modelled as the same family type) but to reduce costs the designer might set an instance version of firerating. Ideally I want to be able to put one or other to the same pset. Thinking of instances more like overrides of the type so there is a set order of priority. Continuing on this scenario, later in the project the construction record needs to be drawn up, so when on site variations occur, a lot of type information ends up needing to have minor variations, i.e override at an instance level for what was generalised at a type level earlier on in the project. Due to the combinatory effect of variations across all parameters it would be impractical to create new family types for each combo permutation of params, so an instance level override would be far better suited.

[JulesBuh]

IfcMaterialDefinition

Is there also any intention of utilising the shared parameters and asset properties attached to materials and being able to assign them to:

 e.g the ifcMaterials that are written, each may have extended properties that would ideally also want to be mappable.

[CNiedermoser]

I'm currently having the same issue with a conversion of the value to feet happening on ifcexport of an revit length parameter to real:

12335= IFCPROPERTYSINGLEVALUE('StationierungAnfang',$,IFCREAL(13123.3595800525),$);

12336= IFCPROPERTYSINGLEVALUE('StationierungEnde',$,IFCREAL(13156.1679790026),$);

12386= IFCPROPERTYSINGLEVALUE('Stationierung_Anfang',$,IFCLENGTHMEASURE(4000.),$);

12387= IFCPROPERTYSINGLEVALUE('Stationierung_Ende',$,IFCLENGTHMEASURE(4010.),$);

Exporter: Revit2021 v.21.4.0.0

Is there a solution/update to this issue available? thx.

[AngelVelezSosa]

The fact that it is exporting as ifcreal() implies to me that the StationierungAnfang parameter is not marked a a length parameter, but as a text or number parameter. Can you check?

[CNiedermoser]

thx for the quick reply.

Within Revit the Parameter Stationierung_Anfang is set as Length. For the export I am using "custom propertyset" which points to: StationierungAnfang Real Stationierung_Anfang

With this i expected to just to stay the same value, without the unit.

We want to have the real units in revit, but we are forced to use real in ifc as the lowest common...

[AngelVelezSosa]

OK, that won't work currently, and I am torn as to what is the "right" behavior. In Revit, the value is stored as some arbitrary unit (for length, in Imperial units). If you specify length as the custom value, then it will properly convert to Metric. If you specify real as the custom value, it will just treat it like a random number. Now, likely, the real solution is to treat it like a length and just use IFCREAL, but that's not an actually correct IFC file. I understand that the rest of the world is more civilized and almost exclusively uses Metric, but ifcreal is not associated with any unit, and as such requires the receiver to understand what the value means. IFCLENGTHMEASURE tells them the exact interpretation. So, to understand the core issue, why IFCREAL instead of IFCLENGTHMEASURE?

[CNiedermoser]

We are using IFCREAL because we also use Civil3D in the same project, which has limitations the other way round: There we can only use IFCLENGTH in rare parameters. Everything not directly geometry linked can only use IFCREAL.

The correct way would leave us with mixed units for the same parameters in the project. Maybe the step to go is ifc post processing and change out all IFCLENGHTMEASURE to IFCREAL - not pretty but definitly does the trick.

thx again!

[AngelVelezSosa]

That would do the trick and I will alert the Civil3D team about this limitation.