IFC 4.3 Made Easy: Practical Tips for Civil 3D Users

ELLIOT GRUBB: So hello, everyone, and welcome along to AU 2024 and to my class, "IFC 4.3 Made Easy, Practical Tips for Civil 3D Users." We're going to spend some time today looking at IFC workflows in Civil 3D. And the goal here, really, is to give you more confidence in exporting IFC 4.3 files from Civil 3D and ensuring you get the most out of the IFC 4.3 plugin for Civil 3D.

Before we begin, allow me to give you a little introduction to myself and tell you a little about me. I currently work as BIM development lead at AtkinsRealis in the UK transportation sector based out of Edinburgh, Scotland. I'm an ISO 19650 certified information manager with experience in large-scale, multi-million pound UK highway projects. A large part of my role, however, is spent acting as a Civil 3D subject matter expert responsible for template standards, guidance, and training in the UK transportation business.

Working in infrastructure, my journey with IFC really started when the IFC 4.3 schema was first published, and then not too long after that, the Civil 3D IFC 4.3 plugin was released, which really spurred on my excitement around IFC. I'm also a Dynamo for Civil 3D subject matter expert. I spend a lot of time looking at how we can make our workflows more efficient by leveraging Dynamo, but I'm also extremely passionate about automation, including Dynamo generative design or writing code in C# or Python. This is my second time speaking at AU after first speaking in 2023. It's a real pleasure to be back speaking.

So let's then take a look briefly at what we're going to cover today. We'll cover some of the basics of IFC 4.3, although I will say straight away, this is not a class on the IFC 4.3 schema or the IFC schema in general. There are other resources available for that. And we'll then go into the IFC 4.3 extension for Civil 3D, and some of the improvements that have been made over previous versions.

We will then take a look at how we can configure the IFC 4.3 extension, looking at the config and mapping JSON files, including some best practice for mapping Civil 3D objects. We'll also go and take a look at alternative ways to generate and edit the config files using the likes of Excel and Dynamo. And then we'll go on to export some IFCs from Civil 3D, view those IFC exports in Revit, and some of the other downstream tools, and then we'll round things off with some IFC property mapping detail and how we can map Civil 3D data to IFC property sets.

So as I mentioned, this is not going to be a class on using the IFC schema. There are some great resources already available, which I have included links to in the handout. But I think it's important just to run through some very basic concepts which we'll rely upon once we start to look at the mapping and the configuration files in the Civil 3D IFC extension.

So you may be wondering fundamentally, what actually is IFC? And essentially, all IFC is an open file format for exchanging information built on the common IFC schema. One key thing to remember is the IFC is not intended for round-tripping or sharing of live data, and it doesn't support bidirectional, design-level data exchange. It's very much an export format and not a native file format, so do bear this in mind.

The great thing about IFC, though, is it's a vendor-neutral format in order to get around some of the interop issues that we see far often in today's world, I'm sure you are familiar with. The IFC schema, though, defines a set of rules and guidelines as to what can be included in an IFC file, but also how these entities should be organized and categorized to maintain data integrity, which is crucial to ensuring the exchange of data between those different software and different platforms.

So the schema itself contains three main definitions. We have objects, and these represent physical assets or entities, such as buildings, walls, furniture, pavement, and so on, as well as more abstract entities, like persons, organizations, spatial zones, as well as annotations. That's things like labels and tags. And really, objects are the core building blocks in an IFC file and are defined as instances of IFC object as well as its subtypes, like IFC product, IFC actor, and IFC spatial element.

Moving on to properties, it's simply information or attributes associated with objects, and they define more detailed characteristics of an object, such as material, dimensions, or other attribution. In the IFC schema, properties are often handled through the IFC property set and provide context and details for how an object is described beyond its basic geometry. Then finally, we have relationships, which are there to describe connections and interactions between objects. IFC defines various relationship types, and these relationships specify how objects are connected to each other, and that could be anything from grouping elements into spatial hierarchy, assigning materials, or defining other connections between elements.

So if we take a look at previous versions of IFC prior to 4.3, one of the biggest issues for us was these earlier versions of IFC were only developed with buildings in mind, and there wasn't any provision for linear infrastructure. It really was quite difficult to map entities properly from infrastructure models or Civil 3D models. And then exports to these earlier versions of IFC was possible using the old IFC export in Civil 3D, but the resulting IFC objects often contained little intelligence or domain-specific information because there was just no provision in the schema for infrastructure.

So anyone who's ever tried to export IFC from Civil 3D in the past will be more than familiar with IFCBuildingElementProxy and the resulting IFC files that just contain lots of these BuildingElementProxy objects. And then obviously, the spatial breakdown in the previous versions only really catered for buildings. There was no spatial breakdown for infrastructure projects, given there was no other infrastructure entities in there.

So then finally came IFC 4.3, which was formally improved and published as ISO 16739 back in April 2024. And this technically means if you were being asked to deliver a project in accordance with the ISO 16739, you're obliged to deliver IFC 4.3. And with IFC 4.3, that introduced three entirely new domains. We've got ports and waterways, rail, and road alongside those existing domains for buildings, which really allowed us to start delivering linear infrastructure projects in IFC. You'll notice here in the diagram that the tunnel domain is in yellow, and that's not currently included in IFC 4.3 but is included in IFC 4.4, which is expected to release soon.

Now across these three domains, we were introduced to a whole range of new entities relating to linear infrastructure. We've got 62 new entities and 294 predefined types, to be exact. And this was a huge step forward for IFC, as it meant we could really start to seriously consider being able to deliver IFC on infrastructure projects, and it was no longer just this buildings format.

So one other important area I want to cover is looking at how IFC objects use predefined types to enhance the way we describe entities in an IFC model, and why this is important in the context of Civil 3D. So any IFC objects that derived from IfcObject have a predefined type attribute. Now the value for this attribute is selected from a predefined list of options specific to that entity, and this basically allows us to further describe an object without needing to add a new entity altogether to the schema.

So in some cases, the predefined type can be set to user-defined or not defined. When it's set to user-defined, the object type attribute can be filled in with custom free text to classify that object according to your project-specific needs. When a predefined type is assigned, the value will then also determine which IFC property sets are available and can be assigned to that object. So we can really control whether to use predefined type or object type when we configure the export from Civil 3D, so we can have that flexibility as to how we actually describe objects, particularly when predefined type isn't suitable or we need to be more detailed.

So now that we've covered the basics, let's go and have a look at the Civil 3D IFC 4.3 extension in some greater detail. So with the release of IFC 4.3, we also got a new extension for Civil 3D for exporting and importing to and from IFC utilizing the latest IFC 4.3 schema. Not only does this allow us to export compliant IFCs in terms of mapping but also allows us to write IFC property sets and QTO directly from Civil 3D, making sure we can output data-rich IFCs.

And we'll go into this in a bit more detail later on in this session, in terms of being able to export data, but one of the key things to note here is the plugin is available for Civil 3D 2022 and above, and you can download that from the manage.autodesk.com portal for those that have access. The plugin is really configured through a series of JSON files, and those allow us to control how Civil 3D data is mapped to IFC entities. We'll dive deeper into this configuration process shortly, but once the plugin is installed, you can access it from the Add-ins tab of the ribbon in Civil 3D, or if you're old school, utilize the commands in the command line.

So the IFC 4.3 extension obviously brings some significant improvements over the traditional Export IFC command in Civil 3D. And some of those key enhancements-- first and foremost, it offers full support for the IFC 4.3 schema, which is obviously crucial for delivering linear infrastructure. There's also far greater object support with the extension. The majority of Civil 3D objects can now be accurately exported to IFC. Think surfaces, alignments, profiles, corridors, [INAUDIBLE] points, pipe networks, bridges, feature lines, all of the objects you would expect to be able to export are exportable.

And perhaps one of the most welcome improvements is no more BuildingElementProxy. Now we're actually able to map objects correctly without the use of proxy elements, which gives us better object representation in the resulting IFC files. And then finally, we also have much better performance as well as the exported IFCs being able to pass validate.buildingsmart.org.

So let's take a look at the two main configuration files that we use to control the IFC 4.3 extension. These can initially be created using the Save Mapping and Save Config buttons on the ribbon or running the commands in the command line. But first of all, we have the IfcInfraConfiguration JSON, and that contains your higher-level settings such as what Civil 3D object types are contained in an export, such as, do we want to export surfaces, do you want to export alignments, and so on.

We can also specify the IFC version to export to, so we can currently export to IFC 4, IFC 4.3, or the draft IFC 4.4 schema. We can also control the attributes against IFC facility and also specify the root facility element in our structure, i.e. As IfcRoad or IfcSite. And then we also get into the attributes against IfcProject. That's metadata such as the name of your project, amongst some other things. And there's also a couple of settings to control how imports are handled in there as well.

Then we have the IfcInfraExport mapping file, and this is where we actually define the mapping rules for how Civil 3D and AutoCAD objects are mapped to IFC entities at a more granular level. We can map our Civil 3D objects to IFC entities and specify subtypes, whether that be a predefined type or a user-defined type, and we can control whether specific layers or styles are exported or not at a more granular level. We can also utilize RegEx checks in here as well to make things a bit easier when you produce your mapping files.

So let's go ahead and take a look at the configuration file now in a bit more detail and some of the things to be aware of here. Now with the configuration file, this can actually be located in and read from a number of different directories on your system. And this hierarchical setup supports the addition of options or overriding previously established settings, depending on where that IfcInfraconfiguration file is actually located.

So let's go ahead and take a look at that structure of how those files are read and processed, depending on the name and location of that config file. So the extension will first check the program data folder. This is obviously useful for your standard or enterprise or system-wide settings related to your standard company templates. Next it will go and check the DWG folder, and if the file exists in here, it will override any settings from the previous location. This one's useful for project-wide settings relating to a series of DWGs, for example.

Next up, it'll go and check the IfcOutput folder, again, overriding anything set in previous config files. This is useful for override specific to a group of IFC files. Then we have settings related to a specific DWG by prefixing the config file with the DWG name, making sure that that's located in the same directory as the DWG. Then finally, we have the IFC file-specific configs by prefixing the config file with the IFC name, again, making sure it's located in the same directory as the IFC file. Key thing to remember here, though, is that lower levels will override higher levels until no match is found.

So once we're ready to generate the configuration file, we can save this by clicking the button in the ribbon or launching the [? IfcInfasave ?] config command, and that can be obviously saved into any of the locations described on the previous slide there. Now the file itself contains a relatively simple JSON structure that allows the editing of various settings. We're going to take a look at this in a little more detail in just a second. But a list of these options can also be found in the Civil 3D help documentation with a bit of more information on what they actually do.

Now whilst we do have text editors like Notepad++, editing these files directly isn't always the most user-friendly thing in the world, and can start to become quite tedious. And this is where we can be a little bit smarter by using the likes of Microsoft Excel to generate these files. So let's have a look at the configuration file now, and how we can actually generate this file in Excel.

So I have on screen here a configuration JSON file that I'd previously exported for this dataset, and you can see it's structured fairly simply, and there's various options around how Civil 3D handles exporting and importing. Now, whilst this is a fairly simple structure, directly editing these JSON files in a text editor isn't always the most user-friendly thing. It does get tedious, and it can be very easy to make errors when you're inputting information into here.

So as I mentioned, I have found the best way to generate these files is simply by using Microsoft Excel. So if I just jump across to Excel here, you can see now, we have control of all the same settings in a much more user-friendly environment. We have the settings themselves in column A, exactly as per the JSON. And if you hover over, you will see there's some additional information on exactly what these settings do to give you some assistance when you're producing these.

Then we have the value to assign to these settings on the right-hand side in column B. You will see there's input validation on these as well to prevent the user from assigning incorrect or unsupported values, something which you just can't do when editing the JSON directly. Then we have the path to generate the configuration JSON file based on these settings. We have the button, which contains a macro that will generate the JSON with the specified settings and the path that we entered.

Remember when you're doing this to consider the directories I was talking about earlier, when you're actually generating these files. I'd like to stress, though, that this spreadsheet is available as part of the class materials, so please do feel free to make use of this and edit it to your heart's content. But before we do any generation of configuration files, there is a couple of specific settings I want to draw your attention to that are definitely worth some extra consideration.

You'll see here we have the default IFC set parameter, which controls whether an IFC file is a .IFC file, or a compressed .ifczip file is created. Remember the IFC is essentially just a text file, so with larger datasets, this can become quite large. So if you are working with large models, do consider using the ifczip to keep those file sizes down.

Then we obviously have settings relating to whether specific object types are exported or not. You'll notice I have most of these set to True, but there is one I want to draw your attention to, and that's the ExportSurfaces. I would recommend this is set to Off or False, as large surfaces, particularly existing ground, can really impact IFC file size.

And this scenario would export a separate IFC for your existing ground surface or existing ground model. When you're working on the medium to large-sized projects, you probably have a separate model for this, anyway. And then that way, the same existing ground surface isn't being exported into each corridor IFC, for example. You can have that separate IFC, and then you're only needing to export this once. But for the purposes of this demonstration, I've got this set to True.

You'll also notice I have some less intelligent AutoCAD objects like polylines disabled, as these tend to just make files messy, and we don't always want these to be exported, particularly if you're batch exporting via scripts and things or running Civil 3D in the headless console mode. Then of course, we have the IfcVersion to export to. In most of the cases, this will obviously be the latest IFC 4.3 schema, but the draft 4.4 schema is obviously there as well if you are dealing with assets relating to tunnels and things.

Then we have attributes for the author of the IFC relating to IfcPerson and IfcOrganization, so we can embed details of the originator in the IFC file. Then we have the information around IfcFacility, where we can specify the root facility type. In this case, that's IfcSite, and we've also specified some other attribution, like name and description and also an address in there as well.

Now the same goes for IfcProject attributes. You'll also notice in here that we can specify the global ID or [INAUDIBLE] which becomes extremely useful when working on larger projects where multiple companies may be involved in delivering the project. If, for example, the client specifies a global ID for the project, we can input that here, and that just means that when the client comes to [INAUDIBLE] this info, that the project [INAUDIBLE] is consistent across all IFC files, no matter where they originated from.

Then we have the property-mapping paths, which allow us to specify locations of the property-mapping files. I'm going to cover these in greater detail later on, so don't worry about these too much just now. And then finally, we have some import parameters. The ones I really want to draw your attention to here are the ImportOrphanProducts, which, when True, will allow entities that are not part of the IFC spatial breakdown to be imported.

And then we also have the ImportIfcProperties, which, when set to False, will not import any attribution from the [? IfcPropertySets ?] in Civil 3D. Now that gets particularly useful if there's a large amount of data on the IFC file, and you don't want that to bloat the DWG by creating lots of unnecessary property sets and things. So we've obviously configured all our settings in here. All that would be left to do is to simply generate that JSON file. You can see it will tell us that's been generated successfully into that directory. So it's generally much, much easier and much more user-friendly as opposed to editing the configuration file directly.

So now that we've covered the configuration file, let's go on to have a look at the object mapping file. Similar to the config file, we can generate the mapping file initially by running the SaveMapping command or choosing the button in the ribbon, and then that will generate the contents of the file based on the contents of the drawing-- for example, all your styles, layers, block names, and so on. Now the IfcInfraExportMapping file can also be read from multiple directories in a similar fashion to the config file with some slight differences, which I'll run through in a second.

Now the first match mapping file will be used. And as I mentioned, I'll explain this, but it's important to note this can be overridden by a specific file path using the Civil3DInfraConfigFilePath environment variable. And where that environment variable has been used, only that file will be processed. In scenarios where no mapping exists, that's when a best guess will be used, based on some other hardcoded rules.

So let's take a look at the mapping file processing order. The key thing to remember here is the first match mapping file will be used, and any subsequent matches will be ignored. So the extension will first check for a mapping specific to the IFC file by prefixing the mapping file with the IFC file name, making sure that the mapping is obviously in the same folder as the IFC file output.

Then we can apply the same rule but for a specific DWG file. Then the plugin will go read mapping from the IFC folder, and that can become particularly useful when we need to map or specify mapping for a set of IFC files, like in scenarios where a separate mapping file is used for IFC 4 and another mapping file is used for IFC 4.3 exports.

If a match is still not found, it will then check the DWG folder, which is useful for project-level settings or mapping specific to that set of DWG files. Then it will go and check the project folder, which can be set in the IfcInfraConfiguration file. And then, finally, we have the program data location, where you can place your system-wide or enterprise-level settings. Remember, if none of these mapping files exist, then our best guess will be used based on some hardcoded rules inside the 4.3 extension plugin.

So let's go ahead and take a look at the basic syntax of the mapping file. So when you open up the map in JSON, you'll see it again follows a relatively simple structure categorized into several 3D entities, such as styles, layers, block names, and corridor codes. Now within each section, there's an entry for the style layer or code name, and the only exception to this is bridge parts, which I'll come on to later.

We can then specify the IFC entity we wish to export the object to, and this follows the format of IFC entity, followed by a period, followed by the predefined type. If the type entered is not a predefined type enumeration item from the IFC schema, then the plugin will write the nominated type to the object type attribute and then set predefined type to user-defined. It's important to note that predefined types are case-sensitive and should be uppercase if you're using a predefined value from the IFC schema.

We then specify whether the item is exported or not with the True or the False flag there at the bottom. If for some reason, you specify an invalid mapping, the extension will try its best to generate a valid IFC file, even though the mapping is invalid.

So one key point to remember is that entries in the mapping file are read from bottom to the top. Now this might sound a bit counterintuitive, so let me explain why that's the case. First, this reading order is designed to be consistent with the JSON file read order. But there's another aspect we need to consider, and that's when working with regular expressions in these mapping files. When you're writing or reviewing RegEx patterns, remember that the bottom-to-top read order means that any patterns at the bottom or any entries at the bottom of the file can potentially override those or prevent those found higher up from being read and being exported.

So let's look at this RegEx mapping in our mapping file in more detail, and how we can actually utilize regular expressions for the name property in that JSON file. Now you might be wondering initially why this is so beneficial. So by making use of RegEx, we can actually reduce the overall number of lines in that mapping file. And that becomes especially helpful when dealing with more complex Civil 3D models and templates with lots of styles, where defining each of these manually and mapping them manually for each individual instance can become quite time-consuming and tedious.

So RegEx really allows us to define patterns instead of individual entries, which streamlines that whole mapping process. One key area where this can make a difference is with more robust Civil 3D naming conventions and templates. If we name things consistently in Civil 3D, RegEx can really help us in producing our mapping files by consolidating multiple entries into just a couple of lines.

So let's take an example of exactly how RegEx works in our mapping file. In the example you see here on screen, we're mapping a series of shape codes, all of those shape codes start with Pavement. Now because of the way Civil 3D reads the mapping file, it's important to remember that entries are processed from the bottom to the top, so let's break that down.

The .* syntax in RegEx that you see on the bottom entry there tells the plugin that any shape code starting with Pavement will be exported as IfcPavement with the flexible predefined type. Now because this wildcard match captures everything that begins with Pavement, more specific shape codes like PavementCapping, PavementBinder, PavementSubbase that you see above won't be processed separately. Instead, these will be exported as IfcPavement.flexible due to the wildcard match already being found on the bottom entry. So really bear this in mind, and make as much use of this as possible when creating your mapping.

Now it's also important to note that Civil 3D goes through a process when deciding how an object should be mapped, as there's multiple methods for how that object can be mapped. There are stages in which it does this, and again, latter options always overrule previous options. Now, Civil 3D will first make an estimation based on hardcoded rules in the plugin as to what the object should be mapped to. For example, your alignment object is hardcoded to always export to IfcAlignment unless it's overridden by below stages, and other objects like TIN surfaces are hardcoded to export to IfcGeographic element with a predefined type terrain.

Next, the layer mapping is used if that's defined in the mapping file, and one important thing to note here is that if a False flag is assigned at a layer or style level, then subsequent checks will not actually occur, and the object will not be exported. So bear this in mind if you are assigning False to nominated layers in the mapping file. The next item that's checked is the mapping that's actually defined in the mapping file against the style or the block name or the code, and that can vary slightly depending on the object type, for example, corridor solids. So do check the handout for some more details. And then finally, if a mapping is defined in a property set that sits on the object in Civil 3D, then this will then be used to map the object.

So I mentioned mapping via Civil 3D property sets on the previous slide there. The key thing to remember here is if a property set named IfcObjectProperties exists, with a property named IfcExport, the value of this property will be used to do that export mapping. It's also worth noting that this property set is created automatically when an IFC is either imported into Civil 3D or an IFC is exported initially or-- correction, sorry-- if a DWG is initially exported to IFC.

You'll also notice that the global ID property populates whenever we export IFC, and that's to ensure that the remains the same on subsequent exports. Another small quirk that you may come across is that Civil 3D won't natively allow you to create this property set via the defined property sets window due to the colons between IFC and export as being recognized as an invalid character. But if you do want to create this without initially exporting to IFC, you can do this using the likes of Dynamo if you so wish.

So now that we know how to actually configure the mapping, let's take a look at some ways we can map objects and ensure we're spatially breaking things down properly. I will say here that there's no correct way to map physical objects. I have just found that this method works best for me in the templates that I've developed in the projects that I'm delivering.

Now, the IFC 4.3 schema is structured around a spatial hierarchy, which is crucial for organizing our projects in a logical way. In Civil 3D, objects can be mapped specifically to align with this IFC spatial breakdown, allowing us to maintain compliance spatial structure in the resultant IFC files. So at the highest level, we have IfcProject, which represents your overall project, and that IfcProject can then contain one or many IfcSites, which then represent different locations or sites within that overall project.

These IfcSites can then contain one or many IfcFacilities, which can be subtypes such as IfcBridge, IfcBuilding, IfcMarineFacility, IfcRailway, or IfcRoad. If we think in the context of Civil 3D, that IfcRoad might be an individual corridor that represents some highway. So the IfcProject and IfcSite details are defined in the configuration file, but let's take a look at how we can map IfcRoad.

Now we could map the corridor style in the mapping file, but most of the time, we won't even need to do this, as Civil 3D has some hardcoded rules that will map a corridor to IfcRoads, or if the base [INAUDIBLE] is IfcRail, it will map the corridor to IfcRailway. Then moving down to the next level, which caters for the longitudinal breakdown of a road, we have our IfcRoadPart with predefined type road segment, and we can map this to the baseline. Civil 3D will automatically populate the usage type attribute to longitudinal, and it's important to note that Civil 3D will also automatically export any subsequent baseline regions to IfcRoadPart with predefined type road segment and again, usage type automatically populated as longitudinal.

Now let's take a look at the next level, which is our lateral spatial breakdown. Now all of this mapping is done to the subassemblies, and all use IfcRoadPart, which has a range of predefined types to cope with various different cross-sectional features. For example, you can see I have my slopes mapped to IfcRoadpart.RoadsidePart, my pavement or sidewalk marked to IfcRoadPart.Sidewalk, we have the carriageway mapped to Carriageway, and so on and so forth. Civil 3D will automatically give these a lateral usage type attribute when exporting so again, you don't need to worry about that.

Then looking at the most granular mapping, which is the physical assets that make up our project. Now these physical entities are still spatially contained in that overall spatial structure of the IFC and are usually related to, then, an IfcRoadPart. In this scenario, we've mapped everything to our subassembly shape code. For example, my pavement layers in both the carriageway and the footpath are mapped to IfcCourse with predefined type Pavement. My earthworks elements are mapped to IfcEarthworksFill. Those in red simply mean I've used the user-defined type and utilized the object type to further classify the object.

You can also see there that I have a blocked map to an IfcSign there as well. And again, I've included this dataset in the class materials with all this mapping, should you wish to go in there and explore that further. And again, just to reiterate, this is the way I map my physical assets. Every project may be different, and there isn't necessarily always a correct way to map the physical elements. Then finally, we also have the ability to map our corridor linework to IfcAnnotations so that we have some lines in our IFC file representing these features. In this scenario, this has been mapped to the corridor point code using the point code to populate the object type attribute in our IFC file.

So let's actually go and take a look at some mapping, some exporting and viewing IFCs in Revit and some different downstream viewers. So you can see on screen here, I have a Civil 3D model consisting of a corridor representing a section of highway. I've data shortcutted an alignment [INAUDIBLE] profile and an existing ground surface, which is turned off at the moment.

You'll also notice I have this bridge structure here, which was actually created in InfraWorks and then pushed back to Civil 3D. If I come to Toolspace and open the bridge, you can see that there's various elements associated with that bridge such as bearings, decks, girders, and so on. Again, this dataset is available as part of the class material if you do wish to do some testing with this data yourself.

Another one that I want to note is I've defined the IfcProject base point here using the button on the ribbon of the IfcInfraSetProject base point command. Because we're dealing with large coordinates, some downstream viewers sometimes have issues with distorted geometry due to those large coordinates, and this works in a very similar way to the Revit project base point, to those that are familiar with that. So to create the mapping file based on the content in this file, I just need to run the IfcInfraSaveMapping config, which will then prompt me to save that mapping in the location of my choice.

I'm just going to cancel this and switch over to the mapping file that I've previously created for this dataset. And if I just go to the top here, you can see, first of all, that I have avoided mapping [INAUDIBLE], as it really gives us less control, and there's a lot more work, particularly for larger models and templates. If I expand alignment styles, you can see all alignment styles are mapping to IfcAlignment. Remember, if that mapping did not exist, alignments are hardcoded to export to IfcAlignment by default. And then you can see I've mapped my baseline to IfcRoadPart.RoadSegment in line with the breakdown on the previous slides that I was showing earlier.

Then if we move down to bridge structure components, we can see how the bridge that sits in my Civil 3D drawing from InfraWorks is actually mapped. The bridge itself will default to IfcBridge, but we can see there are some additional options for bridge components that give us control over the spatial breakdown of that IfcBridge. For example, we have IfcBridgePart.Substructure as well as the mapping of the physical component, so IfcWall.Abutment for an abutment.

If I come down to shape codes-- bear with me one second-- you can see how I've mapped these as per the spatial breakdown on the earlier slide as well. So we have a capping layer of our pavement, for example-- is mapped to IfcCourse.Pavement. So you can hopefully appreciate how extensive we can be with the mapping config. But for larger models or templates, this could potentially become quite a time-consuming process.

So with that in mind, I'd like to demonstrate some additional ways we can actually create or edit this mapping file. So if I come down to the map point code section, you can see I have all of my point codes mapped to IfcAnnotation.Line. Nothing fancy going on there. But let's say there was a scenario where we have lots of point codes, and we wanted to export these corridor feature lines to IFC but set the predefined type to user-defined and use the point code as the object type, so for example, IfcAnnotation.TopOfCurb instead of IfcAnnotation.Line.

So I'm just going to switch back to Civil 3D, and you can see I have a Dynamo instance open here. And we can really take advantage of the likes of Dynamo to generate and edit our mapping files. So in this graph, you can see this is a fairly simple script which gets the point codes from a specified corridor and then updates the mapping file via Python. We can specify the section of the mapping file, whether we want to export that, and then the mapping file location as well.

OK, so if I just run this and then jump back to my export mapping file, you can see that's been modified, and you can see we've now introduced those different mappings entirely by using Dynamo. So this is obviously a fairly simple example, but there's no reason the same approach couldn't be adopted for more complex activities or even creating the mapping file from scratch. Again, this Dynamo script is included in the class material, so feel free to use or modify this to your heart's content.

So now that I have the mapping in place, I'm just going to jump back to Civil 3D, and we're obviously ready to now export this file to IFC. So I'm just going to select my corridor, select my bridge, and run the IfcInfraExportSelected command, and we'll replace the existing file. That will go into the export, based on all the configuration files, and then I can obviously view this in some of the open-source free IFC viewers like Open IFC Viewer.

So you can see here we have my corridor with all the corridor solids. We have our bridge components in there as well. You can see the spatial breakdown. So we have our IfcProject, we have our AU 2024 site, we have our IfcBridge, we have our IfcRoad, which is spatially broken down correctly into the individual parts, and then the physical assets such as the IfcCourse here with the predefined type Pavement. So you can appreciate some of the outputs, now, from the IFC extension and viewing those in some of the downstream viewers.

Now what we can also do is take advantage of IFC 4.3 to improve interoperability between Civil 3D and Revit. So if I switch back to Revit 2025, here, you can see I have a blank Revit file open. Now I'm by no means a Revit user, so please do bear with me here. But you can see I have already linked in the IFC that we exported, and you can see I'm able to view the content of that IFC inside Revit. We have all of our corridor solids here along with the bridge.

If I zoom to the bridge and Tab Select, you can see that's coming through in Revit as a wall because it says, been mapped correctly. Similarly, with the girders and things as well underneath, this should come through as IFC structural framing. If I Tab Select those, you can see we have Revit structural framing. We see all of the data that started out in InfraWorks came into Civil 3D and is now visible in Revit.

Similarly, for our corridor solids, if I just Tab Select one of these, you can see we have all of the information there that we would typically see in Civil 3D as well that's associated with this. So it's really powerful in terms of being able to improve that interoperability between Civil 3D and Revit. Here I'll just select another feature, and you can see we get all of that data that we would expect to see there.

If I jump across to my site plan view, we can obviously section this data as well. And jump across to my section view, we can see that IFC coming through with our corridor features and our bridge features from InfraWorks. Again, selecting it, I can select the corridor Solids I see all of the data that I would typically see inside the Civil 3D property set.

Now remember what I said earlier about IFC being an exchange format. This means there are some limitations. This is obviously all solved geometry you're seeing and not a direct link to the corridor, for example. Key thing to bear here in mind, though, is that the surfaces that come through IFC from Civil 3D to Revit are unable to be converted to topo solids or topo surfaces at this time, but I can still annotate things in here as well. I can take spot elevations and so on. There are some things you can do with tagging as well.

So if we jump back to our presentation now-- and one final area of configuration I want to cover is around property mapping. Now another great feature of the IFC 4.3 extension is the functionality to allow us to fully customize how data from Civil 3D is created and mapped to the IFC property sets, and this gives us a lot more control over the data that's actually going into the IFC files from Civil 3D. We can control how general object data, user-defined COGO point properties, pipe data, property sets, DWG data is actually written to the IFC export, and having that flexibility ensures that the data can actually be exported in a way that meets project-specific requirements that you might have had dictated to you.

This is especially valuable when writing to IFC property sets and IFC quantity sets, as we can ensure that the right information associated with the right objects and the right IFC property sets with the correct data types are being exported. So we can configure how data is mapped during the IFC export using two key files. We have the IfcInfraExportPropertyMapping CSV and the IfcInfraExportPropertyMapping JSON. These files can be automatically generated based on the contents of the current drawing using the IfcInfraSaveProperty templates command or by using the button on the ribbon.

The location of these mapping files is specified in the property template paths and property management path sections of the IfcInfraConfiguration JSON file. Any files located in the DWG directory will automatically be recognized on export [INAUDIBLE]. So if no mapping files exist, then all Civil 3D properties will be exported by default, and a best guess will be used in terms of their data types and things in the IFC.

So the property mapping JSON file really allows us to customize how IFC property sets are defined and control how properties are created in the IFC file. The file contains a JSON array of IFC property set definitions. Each item includes the property set name, description, property set template type from the IFC schema, the applicable IFC entities that the property set's going to apply to, and that may be IfcElement to apply to many, or even IfcSite or IfcProject.

Within each property set, there's an array of individual properties. Each property includes its name, description, and data type, such as IfcLabel or IfcBoolean, which gives us more precise control over how that data is actually represented in the IFC. If the property mapping JSON does not exist, the IFC plugin will use hardcoded rules to make a best estimate based on the data in the Civil 3D drawing. However, having this file obviously gives us full control over how that data is written.