Autodesk
ENH: Ability to reference external export class mapping
Enhancement Description
Context
In Revit 2025, the ability to set export class mapping was moved from the File menu to the IFC export settings. This is generally a great idea since different projects require different IFC schemas for export.
However, along with this, the way the export class mapping is referenced has changed from file-based to DataStorage object.
Problem description
Unfortunately, this approach doesn't scale very well. Since the class mapping is now stored in the model there are some dire consequences:
- Class mappings need to be stored in every model. (For new projects this can be remedied by including the class mappings in the project template, but not for upgrading from previous Revit versions...)
- In case of any changes, class mappings need to be updated in every model.
This is not an issue if you deal with only five models but is no joke if you're dealing with hundreds.
Proposed change
As an alternative, allow users to specify the class mapping as a name or a path in the export settings JSON file.
So both "CategoryMapping": "myIFCClassMapping_IFC2x3" and "CategoryMapping": "C:\myfolder\myIFCClassMapping_IFC2x3.txt" would work.
Revit Version
2024.0.x
IFC for Revit Addon Version
24.x.x
Windows Version
11 22H2
So I thought I had found a clever workaround for this by using the option to export multiple models at once. I added the class mapping to one of the models and exported all of the models with those export settings. Unfortunately, the class mappings were only applied to that one model in which they were actually stored. It's nice to now have a functioning interface for the mapping but I didn't expect it to be such a productivity killer.
Is this a one-time cost to upgrade old files, or do you expect this to be an ongoing issue? I'd like to understand the upgrade workflow - is there something we could do to make the upgrade better? Or do you just want a way to use the current mapping to all files? And how does that work for custom categories, etc.?
@AngelVelezSosa Thanks you for your interest and let me give you some context first:
-
Frequency:
We have class mappings for IFC2x3 and IFC4 (and probably IFC4.3 soonish once that becomes a client requirement). These get revised on an annual basis (coinciding with the rollout of a new Revit version) for a number of reasons (mostly decisions to change the default mapping of a category to a different PredefinedType or even class as well as new categories being added to Revit in recent releases). -
Project lifespan:
Projects typically run over multiple years. So they are affected multiple times over the course of their lifespan. -
Scope:
In the last two years we've had only one single Closed BIM project (not counting competitions) so IFC export is a must in virtually all of our projects. That's a three-digit number of models.
That's why in the past (when we only had one mapping table, i.e. before clients started requiring IFC4) it has saved us a lot of time to be able to define the class mapping as a path via the Revit.ini - just very easy to push a new Revit.ini to all users. Once we needed to support more than one IFC schema, users on IFC4 projects had to change the class mapping path manually, of course. And users on IFC2x3 and IFC4 projects had to start juggling - which is why I think it's generally a great idea that the class mapping is part of the export settings instead of a per-user setting. I actually remember us talking about this at the last ITF Live I attended. I also think it's great to have an editor with a modern interface for the class mappings that doesn't break the encoding like the old editor.
But I would like to keep being able to centrally manage the mappings and easily push changes for the entire firm, for all those models.
Having said all that, we found out this week that we can still (at least currently) circumvent this entire issue programmatically for the majority of our models. Most of our project models aren't exported manually and API-wise it looks like the FamilyMappingFile property in the IFCExportOptions has not been deprecated. So as long as that option remains available in the API we are safe for the most part.
I added today's earlier comment to the issue because there are always cases that aren't automated. Today I had to export a two-digit number of test and reference models and found myself having to add class mappings to all of them. So yes, if I had a wish (or two) I would like to be able to...
- reference the path to a mapping file (stored in a central location) in the export settings as an alternative to a mapping stored in the model itself
- use the class mapping from one model (the one with the active view) when exporting multiple models at once
Sorry for the long rant ;-)