Support for IFC 4.3 #353
Comments
|
Hi Adam, yes, we have a plan to implement it in the next few months. What is your use-case for this? We would be very interested if you had any data we could use to test & validate our implementation. Or, would you use xbim to create an infrastructure data? In any case: Would you be interested to participate on the implementation in some way? Martin |
|
Hi, I also would like to push this topic ahead. Up to now no vendor in our authoring pipelines supports 4.3 but it will happen. Especially concerning IfcBridge and IfcRoad. |
|
Hi @BerNold, We did a proof of concept 18 months back for the bSa Rail room where we implemented the entities and IfcAlignment2DHorizontal as a proof of concept for Ifc5. These are still in the ifcrail branches of Essentials & Geometry. Obviously it wasn't a full implementation of the alignment geometries but could be a starting point. At the time the schema was very much pre-release. Regenerating the schema with the 4x3 Express entities should be trivial. But as you allude, the Alignment implementation will require some effort & testing. We actually have a project scheduled to start in October when we'll implement 4.3 + Alignments officially. If you'd like to get involved I'm sure Steve & Martin would appreciate any input if you've some time! Andy |
|
@martin1cerny We are using xbim to extract properties, quantities and other data from IFC files. We are also building a tool on it for running automated checks on IFCs. While most of our customers are planning/building residential and commercial buildings, there is an upcoming infrastructure project—railway in this case. They are currently stuck with IfcProxyElements. But as soon as these new elements are available in the planning software, we want to be able to support them. On the mid-term we want to be able to reclassify these proxy elements to proper building elements, be it IfcWall or IfcBridge and output new IFC files with xbim. As for participation, absolutely. When you guys have an implementation plan for this, let us discuss and see where we can be of help. |
|
Hi Andy, Cheers, |
|
Good stuff! @eriadam Just on the railway scenario, if you're interested there's a preview of what we did for the IfcRail room at https://ifcrail.azurewebsites.net/ - There's still a lot of BuildingElementProxies in the model (that wasn't the focus), but what you should see (looking at the Properties tab) is some of the new entity types (e.g. IfcRailway, IfcRailElement etc), and more significantly the ObjectPlacement of things like the sleeper is using IfcLinearPlacement relative to the IfcAlignmentCurve. You can also download the unofficial IFC file. Be aware this was a pre-release schema - some things changed on the way to ifc4.3 (so you'll see thing like IfcRailwayPart in place of IfcBuildingStorey, which didn't make the cut) |
|
After a short search I could find some examples for IFC4x3: |
|
Hi all, we have started to work on IFC4x3: https://github.com/xBimTeam/XbimEssentials/tree/feature/Ifc4x3/Xbim.Ifc4x3 This is just an initial code for the schema implementation but allows to do some basic tests and is complete for scenarios where you want to write IFC4x3 files. Geometry engine will not work with this as of yet. |
|
Hi @martin1cerny , |
|
Great. Happy to hear any feedback. Here is the overall list of new entities: Namespace: Rail
IfcAlignment2DCant
IfcAlignment2DCantSegLine
IfcAlignment2DCantSegTransition
IfcAlignment2DCantSegment
IfcAlignment2DVerSegTransition
IfcAxisLateralInclination
IfcDirectrixCurveSweptAreaSolid
IfcDirectrixDistanceSweptAreaSolid
IfcDistributionBoard
IfcDistributionBoardType
IfcElectricFlowTreatmentDevice
IfcElectricFlowTreatmentDeviceType
IfcInclinedReferenceSweptAreaSolid
IfcLinearAxisWithInclination
IfcLinearPlacementWithInclination
IfcMobileTelecommunicationsAppliance
IfcMobileTelecommunicationsApplianceType
IfcRail
IfcRailType
IfcRailway
IfcTrackElement
IfcTrackElementType
Namespace: SharedBldgElements
IfcBearing
IfcBearingType
IfcCaissonFoundation
IfcCaissonFoundationType
IfcDeepFoundation
IfcDeepFoundationType
Namespace: SharedInfrastructureElements
IfcBorehole
IfcBuiltSystem
IfcCourse
IfcCourseType
IfcEarthworksCut
IfcEarthworksElement
IfcEarthworksFill
IfcGeomodel
IfcGeoslice
IfcGeotechnicalAssembly
IfcGeotechnicalElement
IfcGeotechnicalStratum
IfcImpactProtectionDevice
IfcImpactProtectionDeviceType
IfcPavement
IfcPavementType
IfcPlant
IfcReinforcedSoil
IfcSign
IfcSignType
IfcSignal
IfcSignalType
IfcSolidStratum
IfcVoidStratum
IfcWaterStratum
Namespace: ProductExtension
IfcBridge
IfcBridgePart
IfcFacility
IfcFacilityPart
IfcRelPositions
Namespace: PortsAndWaterways
IfcConveyorSegment
IfcConveyorSegmentType
IfcLiquidTerminal
IfcLiquidTerminalType
IfcMarineFacility
IfcMooringDevice
IfcMooringDeviceType
IfcNavigationElement
IfcNavigationElementType
Namespace: Road
IfcKerb
IfcKerbType
IfcLinearSpanPlacement
IfcOpenCrossProfileDef
IfcRelAssociatesProfileDef
IfcRoad
IfcSectionedSurface
Namespace: StructuralElementsDomain
IfcTendonConduit
IfcTendonConduitType
Namespace: SharedComponentElements
IfcVibrationDamper
IfcVibrationDamperType |
|
Hi @martin1cerny, I had a first try with the Ifc4.3rc1. There are some remarks and questions from my side. First, when using Ifc4.3 the compilation of geometry warns about a class clash in XbimEssentials Ifc2x3 and Ifc4.3 at IfcValueHelper. I‘ve solved this by using partial classes and renaming the clashing methods. But actually, I‘m not sure, whether they are generated or not. The concept of IfcAlignment has been completely refactored by bS. There are a lot of changes between 4.1 and 4.3. I.e. IfcAlignmentHorizontal has been renamed and moved to be derived from IfcProduct. Means, the geometry would have to maintain two different implementation. I‘m also not sure, how the class generation process handles the name change. Since there‘s an interface Ifc4 abstraction layer, it might cause conflicts. The rc2 had significant changes, too. Is there a possibility to regenerate/update the Ifc4x3 branch and merge the changes of rc2? I‘ve started to take over the IfcRail implementation by hand, since there is no way to merge those changes automatically. Furthermore, I guess it would be easier to completely forget about 4.1 implementation since there are too many conflicts and changes (and no real impact to the final model since the alignment part wasn‘t connected to the model anyway). Cheers, |
|
Hi @bekraft, thanks for your work! IfcValueHelper is partially generated, so I'll have to change this in the code generator. I run my own comparison on schemas and RC2 changes are significant (summary bellow). I have regenerated the schema to be RC2, so you can try it. I'm trying to handle name changes, but if it is also moved in the inheritance hierarchy, it should now be independent and should not cause any problems. Any suggestions and contributions are most welcome! |
|
Hello, may I know what is the status of IFC4x3 support in xBim? Is it fully implemented now? If yes, how to use it? Just build IFC4x3 branch and use it for xbim Essentials? and xbim Geometry need any special version or not? I am interesting in try Xbim toolkit to process IFC4x3 file. |
|
There is a new feature branch and project work item #450 for Essentials and xBimTeam/XbimGeometry#400 for Geometry. |
Hello,
Do you maybe already have plans about supporting the upcoming version of IFC 4.3? It is already a release candidate.
https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/
We would be very interested in this IFC version due to the new infrastructure types it adds (IfcRoad, IfcRail, etc.).
Thanks,
Adam
The text was updated successfully, but these errors were encountered: