Giter Site home page Giter Site logo

Comments (14)

jmirtsch avatar jmirtsch commented on August 26, 2024 1

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).

from revit-ifc.

AngelVelezSosa avatar AngelVelezSosa commented on August 26, 2024 1

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

from revit-ifc.

JulesBuh avatar JulesBuh commented on August 26, 2024

... 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.
siunitassign
siunit

projectunits

from revit-ifc.

jmirtsch avatar jmirtsch commented on August 26, 2024

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: jmirtsch@90efd01

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.

from revit-ifc.

JulesBuh avatar JulesBuh commented on August 26, 2024

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?

from revit-ifc.

jmirtsch avatar jmirtsch commented on August 26, 2024

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)

from revit-ifc.

JulesBuh avatar JulesBuh commented on August 26, 2024

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.

from revit-ifc.

JulesBuh avatar JulesBuh commented on August 26, 2024

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

correctdatatypeconfig
correcteddatatype

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?
shareparamdatatype

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.

from revit-ifc.

JulesBuh avatar JulesBuh commented on August 26, 2024

IfcMaterialDefinition

Is there also any intention of utilising the shared parameters and asset properties
attached to materials and being able to assign them to:
<xs:element name="IfcMaterialProperties" type="ifc:IfcMaterialProperties" substitutionGroup="ifc:IfcExtendedProperties" nillable="true"/>
<xs:complexType name="IfcMaterialProperties">
xs:complexContent
<xs:extension base="ifc:IfcExtendedProperties"/>
</xs:complexContent>
</xs:complexType>

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

from revit-ifc.

CNiedermoser avatar CNiedermoser commented on August 26, 2024

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.

from revit-ifc.

AngelVelezSosa avatar AngelVelezSosa commented on August 26, 2024

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?

from revit-ifc.

CNiedermoser avatar CNiedermoser commented on August 26, 2024

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...

from revit-ifc.

AngelVelezSosa avatar AngelVelezSosa commented on August 26, 2024

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?

from revit-ifc.

CNiedermoser avatar CNiedermoser commented on August 26, 2024

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!

from revit-ifc.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.