I have come across situations where people wish to upgrade / downgrade from / to IFC2X3 and IFC4. I think that @jonm has built some tools around this, but I’m not sure if any mappings that it uses is public. I’d like to build similar tools, but wanted to first ask if there were any public resources available around this mappings, preferably computer interpretable? If not, I guess I could make do with the HTML docs, but it is slightly less than ideal.
I’d also propose that if there is no automated changelog, one be made available for IFC4 → IFC5 and all future IFC versions? It will greatly help drive adoption of more up-to-date standards, I believe, if developers can make it easy for users to upgrade.
Otherwise, you could always use the schema_by_name() declaration_by_name() all_attributes() in IfcOpenShell to try and work out which entities exist in the target schema and the attribute types on them.
Yep, appendix F is what I meant by the HTML docs. It’s parsable I think, as it looks pretty structured and neat, but there seem to be a couple things I’ve noticed like:
Some things are omitted (I assume they are ommitted because they are typo issues), like IfcStairFlight has NumberOfRiser in IFC2X3, renamed to NumberOfRisers in IFC4.
There is no description on how data is mapped, e.g. IfcDateAndTime vs IfcDateTime, or IfcDocumentElectronicFormat.
Yes, checking the schema via attribute name would be a fallback. I guess I was wondering if there was another resource I missed Or if somebody has already built a tool
Be aware that those change logs are incremental. The attribute NumberOfRiser was only renamed in IFC4 Addendum 1, not in the initial IFC4 version. If you find actual omissions, it might be worth reporting them, to update the change logs.
Great discussion. I’ve been thinking about this a lot lately too. Would be great to share approaches here, especially given the common mention of IFC as an archival format.
Related to @Moult’s notes on Appendix F: Are some changes in the change log serialization-specific (see Columns 2 and 3 of the main table in Appendix F)?
What does it mean, for example, for IfcWorkSchedule to change its Identifier attribute to Identification, but with an X in the ifcXML column only?
The changes as such are not serialization specific. I understand the columns to flag whether the change breaks compatibility for the respective implementation method (AKA serialization if you like). If the flag is set, the change breaks forward compatibility of a system implemented for the old version of the standard and backward compatibility of a system implemented for the new version of the standard. Hence old software may fail with new version input and new software may fail with old version input.
The effects of changes in the standard differ between implementation methods, because of their implementation specifics. For example, SFP does not contain attribute names, hence it forgives attribute renames, not so for XML. XML does not rely on attribute order, hence it forgives attribute deletion, not so for SPF.
Thanks @tauscher! That explanation, especially the second paragraph, clarified the intent of those columns. If only that explanation could be in a header paragraph to Appendix F (did I miss it?)!
@all: Does this imply Appendix F does not provide sufficient information with which to build an “IFC version migrator” from, per discussion above? For example, if an entity/attribute/enum value is deleted, how would the migration tool know what to migrate the source entity/attribute/enum to? The simplest approach might be to just delete it and pipe out a log of all “unmigrated assets”, but I can’t prove this wouldn’t cause irrevocable damage to the migrated file.
The shortest path to victory seems to be using an authoring tool or library (e.g., IfcOpenShell) to import the IFC file in the schema version you have and export again in the version you need. It’d be great if we could eventually get to the point where we didn’t have to rely on vendor tools to do the heavy lifting here and instead the data model itself (like some extended, semantically annotated version of Appendix F) could drive the migration directly. So +1 to @Moult’s request for automated changelogs. Happy to keep chewing on this if there’s interest.
How important is automated forward-migration of IFC files (e.g., from IFC4 to IFC5) to you?
Not important
Somewhat important
Very Important
0voters
How important is automated backwards-migration of IFC files (e.g., from IFC5 to IFC4) to you?
Not important
Somewhat important
Very Important
0voters
Which IFC serializations/implementation methods would you need migration support for (choose all that apply)?
IFC-SFP
ifcXML
ifcOWL
ifcJSON
ifcSQL
ifcHDF
0voters
Would you be willing to pay for IFC file migration as a service?
No, it should be freely available and centrally hosted
No, it should be freely available for localized hosting
It’s early days, but I’ve successfully run it on a few simple files.
As it matures, we’ll distribute it as part of the BlenderBIM Add-on and IFC Patch utilities, so conversion can happen local / remote / GUI / CLI / whatever.
I’m having to make a series of decisions on how to handle graceful conversion. Some examples:
When downgrading, IfcExternalSpatialElement, should it be discarded, or converted into IfcSpace, or something else entirely?
When downgrading, IfcMaterialConstituentSet, should it be converted into IfcMaterialList? What about IfcMaterialProfileSet, should it also be converted into a list, or discarded?
When upgrading, should lists be converted into constituent sets, or be maintained as a deprecated list?
Can I propose to buildingSMART that a document be published about the upgrade and downgrade procedure so that this can be standardised?
Or if somebody has already built a tool 