Streamlining Corridor Workflows with Dynamo for Civil 3D

ELLIOT GRUBB: OK, so hello, everyone, and welcome to AU 2023, and to my class, Streamlining Corridor Workflows with Dynamo for Civil 3D. This class is really going to focus on some very specific workflows around corridors, and that should allow you to become more efficient in how you build and manage corridors and also manage things like code set styles as well.

Before we begin, I'll just introduce myself and tell you a little bit more about me. I am a BIM Development lead at Atkins in the UK Transportation business. I'm based out of Edinburgh, Scotland. I'm also an ISO 19650 certified Project Information Manager with experience on large-scale multi-million-pound highways projects in the UK.

As a Civil 3D SME, a large part of my role is being responsible for Civil 3D standardization across our UK Transportation business and being responsible for things like template production, standards, guidance, and training rollouts as well. I'm also a Dynamo for Civil 3D subject matter expert. I began using Dynamo when it was released for Civil 3D as part of Civil 3D 2020. I don't necessarily have the Revit background in Dynamo, as most other users do, and I'm passionate about automation in general, whether that be Dynamo, generative design, or even .NET programming as well.

So let's take a look at today's learning objectives. First learning objective is fairly self-explanatory. We want to discover how we can be more efficient when working with corridors by utilizing Dynamo in our day-to-day workflows. We're going to learn how to manipulate corridor geometry and manipulate subassemblies using Dynamo. We'll cover how to access corridors using the Python node, and we'll also learn how to create corridor transition sets, which were introduced in Civil 3D 2023, using Dynamo.

So that was our learning objectives, but what exactly are we going to cover and not cover? We're firstly going to run through a fairly simple workflow of creating corridors from polylines with Dynamo, before then going on to some more advanced stuff around corridor transitions via Python and also controlling subassemblies to generate transitions between polygonal shapes. We'll then run through the power of Dynamo for quantity extraction, with a fairly simple graph that gives us data that we can then visualize in PowerBI, really to illustrate the downstream uses of data that we can actually extract using Dynamo for Civil 3D.

We'll then run through how we can then manage our code set styles in Excel by utilizing Dynamo, but the one thing I really want to stress here is it's important to note that we're only going to cover some more advanced stuff here. We're not going to cover Dynamo basics. It's assumed you already have a basic understanding of Dynamo and Dynamo for Civil 3D.

We're also not going to do a full rundown of the Civil 3D and AutoCAD APIs. There's another-- there's a number of other good resources and classes and things that do break them down, if you are interested. Given that we only have one hour, there will be specific nuances that we just can't cover in the presentation due to time constraints, but all Dynamo graphs that are demonstrated today will be included in the class handout and class material, so you are free to look at those and pick them apart to your heart's content.

So let's take a look at a fairly simple but rather effective workflow around creating corridors with Dynamo simply from a polyline or a feature line. So although there's been some improvements in recent releases of Civil 3D, we all know that default tools for corridor creation can sometimes feel a bit outdated and sometimes un-user-friendly. To create a corridor from a feature such as a polyline or feature line takes a minimum of 20 clicks and three separate Civil 3D commands. And of course, we can't bulk, create multiple corridors or add multiple baselines with one command. We would have to actually repeat that process for each corridor or baseline or, indeed, region that we add.

So now you might be wondering why that's a problem. If you're modeling a section of highway, why would you want to be creating 10 corridors at once or even, indeed, create a corridor from a polyline? You would surely first design your alignment, your profile and things. This is predominantly aimed at those who are utilizing corridors to model ancillary items like ditches, barriers, fence lines, or even multiple curved islands in a car park, or a parking lot, if you're in the US.

So as I mentioned, the real use case for this isn't necessarily around new sections of highway, but scenarios where you may have a polyline or feature line geometry that you need to turn into a model of a linear item. This is particularly useful for things like street lighting, where you may have hundreds of dots to model that have initially been laid out using basic geometry such as the feature lines or polylines. It's also fairly useful for creating corridors for islands, so roundabout splitter islands, car parks, where you can obtain the levels from the surface and model those islands in one hit with a curbing subassembly.

So we're going to take a look at the graph in depth inside Dynamo in a second, but if we take a basic, high-level look at how we can achieve this, it's really, really quite simple. Firstly, we create the baseline simply by using the Alignment.ByPolycurve node. Now that's our horizontal baseline created, then we obviously need our vertical baseline.

So firstly, we create a surface profile using the Add Profile By Surface node from the Civil 3D ToolKit. Then we're going to create a design profile by simply joining the start and end elevations of the surface profile together by adding a PVI. When you look at the graph inside Civil 3D, you'll see that we have given users the option to choose whether to use the design profile or the surface profile when building that corridor.

Then it's a case of creating a corridor. We'll first create an empty corridor with CorridorExtensions.ByName, again, from the Civil 3D ToolKit, before we add the baselines we created previously. Then, finally, we add regions with the specified assembly and baselines and things.

So let's jump across to Civil 3D and take a look at this in detail. In this drawing here, I have a model that represents a street lighting network. I'll just maximize this for a second. We have a series of point-based assets connected by some dots. Now, at the moment, all that's representing these dots is a series of polylines, and what we wish to do is model these dots with a trench, a ducting trench subassembly, and model the duct itself using the corridor.

Now, creating a corridor for each of these ducts or adding each duct as a separate baseline manually would take some doing, so we're actually going to use Dynamo to create these corridors. So if we just open up Dynamo for Civil 3D here-- and we'll open up our CreateCorridors graph. Now I'm just going to make this window slightly smaller so we can see Civil 3D in the background.

So let's run through our inputs first of all. We obviously need to select the objects which we wish to create corridors from. In this case, I've already selected the 2D polylines representing our dots. I'm then going to specify the alignment name-- where we are creating multiple alignments, this is essentially just the prefix-- then the layer that we want to place the alignments on, profile style which we wish to use, the alignment style, alignment label set.

And you'll see we have this True/False node here as well. When this is set to true, multiple corridors will be created, so what I mean by that is one corridor for each polyline or feature line. So we're going to set that to True. If it were set to False, we would have one corridor with multiple baselines inside of it.

I'm then going to specify the surface from a drawing for which we wish to use to create the surface profile. In this case, I have this AU2023 surface in here, then the name for the corridor. Again, where multiple corridors have been created, this is simply just the prefix.

And we have another True/False node here, which specifies whether we wish to use the design profile-- that's the profile we create by simply joining the start and end elevations of the surface profile-- or do we wish to use the surface profile when we create our corridors. So in this case, I'm going to select False, and then finally, we have the assembly. Again, I've preselected that.

If I jump over to my Civil 3D model, you can see I have a ducting trench subassembly now. So we're just going to run this now. We'll give that a second to run through, create the alignments, create the profiles, and build the corridors.

And you can see there that we've modeled all of those ducts all in one hit. As we'll come to Toolspace inside Civil 3D and expand my Corridors, you can see we've produced 79 corridors for those 79 duct runs all in one hit using Dynamo, so, really efficient if you are modeling these isolated linear features. So moving on, then, next up we're going to take a look at corridor transition sets with Dynamo.

Now, with the 2023 release of Civil 3D we were given a new Corridor Transitions feature that allows us to create transitions by modifying subassembly parameters over station ranges, and what this allows us to do is manipulate corridor geometry without the need for targets or different regions in your corridors. Now, that's really useful, as you'll have less targets to manage, and as I said, it eliminates the need to have transition parameters on your subassemblies, things like start and end station parameters for widening, and the widening values themselves. It's also really easy to manage the transitions once they're created. There's a new section of the Panorama window in which we can change the stations' transition values, transition types, et cetera, et cetera.

And with 2024 releasing at the beginning of this year, an API was actually exposed to create these transitions. This, of course, gives us even greater flexibility and means that we can actually utilize these new corridor transitions in Dynamo. Now, being able to actually control these with Dynamo gives us real opportunity to automate things like dropped curbs, driveways, ADA curb ramps, if you're in the States, all in one click. You could have predefined Dynamo graphs set up with all the predetermined inputs required from the design standards, things like your dropped curb transition lengths and dropped curb width. All the user really needs to input is that corridor and the station of the feature that they're actually modeling.

It's also extremely useful for modeling widenings such as bus stops and laybys. As mentioned in the previous slides, there's no need to create offset alignments and widenings or add widening parameters to your subassemblies. You could quickly create this with standard dimensions using Dynamo, again, with some predetermined inputs.

Now, to create these transition sets, we're going to utilize the Python node in the Civil 3D API. As mentioned before, this will only work in Civil 3D 2024 and beyond, due to the fact that there was just no API for these transitions in earlier releases. This API was only exposed in Civil 3D 2024. So we're going to take a more in-depth look at the code in a few moments, but again, I'd like to stress that a detailed walkthrough and the graph itself is available in the handout. So you can pick this apart as much as you need to and read through it as much as you need to to get comfortable with it.

So the one thing I wanted to really cover in this class was how we can access the Dynamo corridor object in Python to then utilize those API properties and methods. And the graph we're using to create the corridor transitions, we're going to use the Select Object node to select the corridor we want to apply the transition to. Now, the output of that Select Object node that you can see in the image on the right there is a Dynamo object and is not the API corridor object that we need to apply the corridor transition.

The underlying corridor object is essentially contained inside that Dynamo object, so to obtain that underlying object, we actually need to unwrap it. And we can do this by using the InternalObjectId property, and what this does is essentially returns the underlying object ID in the DWG database. The one thing to remember here is it's not just corridors that have this InternalObjectId property. It could apply to all objects, such as alignments, surfaces, and pipes, you name it, so it is really useful if you want to pass a Dynamo object into a Python node.

So to get the internal object ID of the corridor and get the object, we can look at-- we can lock the document so there can be no other input whilst we execute this code. We then obtain the DWG database from the document and start a database transaction. It's then using that transaction that we can get the corridor object using that object ID we obtained with that InternalObjectId property I was talking about.

We then pass another parameter which tells Civil 3D to open the object for write because we want to change that object by adding the transition. If you only wanted to obtain information from the corridor such as its name, description, something like that, you can use OpenMode.ForRead. Because we want to change the object, that's why we're using ForWrite.

So now we have that corridor object we can use the API with it, and we've stored that object that we've obtained in that core that core variable you see there on the bottom line in the screenshot. Again, I must stress to read the handout, as this goes into greater detail on working in transactions and the purpose behind transactions and things as well. So now that we have that corridor object, let's actually take a look, a more in depth look at the steps required to create transitions with the API.

So firstly, we take that corridor object we obtained in the-- that we obtained in the previous step, and we get the baseline we want to apply the transition to. Now, in this case, for simplicity's sake, I've simply taken the first baseline in the corridor by using the first index in the list. I've used the Corridor.Baselines property and taken the first index using the zero you see in the square brackets there.

We then take the baseline we obtained and get the baseline region we want to apply that transition to. Again, for simplicity's sake, I've obtained the first baseline region using the baselines.BaselineRegions property, and then taking the first item in that list, index 0. In reality, you probably would want to either pass this as an input to the Python node or apply some kind of logic that searches for a specified baseline and baseline region.

So if we take a look at the next section, then, next is where we actually create that corridor transition, and we store that in this transet variable. To create that transition, we use the Corridor Transition Set Constructor from the Civil 3D API and pass the name of the transition set to be created, the baseline region from the previous step, the subassembly name, and the CorridorTransitionNameType.SubassemblyName. All this does is tells Civil 3D whether you're using the subassembly name or the subassembly class name, is that SubassemblyName parameter that we passed, is that, the name or the class name, the subassembly.

So if we move on, then, we've created that Corridor Transition Set object, but we still need to apply some additional information to actually create the transition geometry within that transition set and then apply the transition. So to do that, we use the Add Transition property of the Transition Set object that we just created and pass the subassembly parameter name we want to transition with. So that might be width, slope, anything that we want to use to transition that geometry.

So we then set the transition values using the transition we created for the specified subassembly parameter, so your start and end stations, start and end values of that parameter, and the transition type. TransitionType is a linear transition, parabolic, et cetera, et cetera. Again, in practice, you might want to pass this transition type as Input, but just to keep things simple, we've set that to Linear in our code here.

So finally, we want to append the current transition set to our transition set list and then apply these transitions to the baseline using the baselines.SetTransitions method and passing the transition set list. Then if we remember that transaction that we opened up to make these changes to the drawing itself, well, we need to actually commit those changes to the database, and that should be our transition modeled.

So let's step back and actually jump across to Civil 3D to see how this actually works in practice. So as I mentioned, these transitions can be extremely useful for modeling things like dropped curbs, curb ramps. You could have predefined Dynamo graphs set up, ready to run in Dynamo Player, that allows you to model those features. In this model, I have a simple corridor, two lanes with some footway and some curbs either side, and I've extracted corridors solids here just so you can see things a little better in this 3D view of the right here.

So I'm going to select the Dynamo Player here and find our Corridor Transitions Curb graph. And you can see the inputs we have here. We have the dropped curb length. That's simply the length of the dropped curb itself. The start chain is the start station where we want to apply that dropped curb, and our transition lengths on either side of that dropped curb.

You can see how easy it is to change the inputs there, but let's say those are OK. Let's model this transition here, so if select Run-- you can see my corridor rebuilding. You can see how easy that was to actually model that dropped curb in a couple of clicks, just by simply specifying these parameters here. In the real world, you would probably have graphs set up, as I mentioned, with predetermined values from your design standards and things.

The good thing is, as well, it's not just curbs that you can apply this to. If I come back to the Dynamo Player, now you can even use this to create widenings for laybys, bus stops, those kind of features that you would traditionally perhaps model with targeting offset alignments and widenings.

So we're going to select Corridor Transitions Layby, and we have the entry and exit lengths here, the width at the end, the width at the start, the widening length the start station, and the widening width. I'm just going to leave those input values as they are. Run this graph, you can see my corridor rebuilding now in the bottom right, and we have that transition modeled.

Now, if I come back to select my corridor, the handy thing about these transition sets is they're easy to manage and edit. So I've selected my corridor, and I'm going to choose Edit Corridor Transition in the contextual ribbon. And you can see we have that transition that we just created. The reason you don't see the curbing one anymore is because we reran the Dynamo player and the object binding receptor erased that.

What we can actually do is, by locking these values, we can simply change the start station, and you can see all of the other values move with that. So if we apply, you can see we've moved that widening 50 meters. So once they're created, they are really easy to manage as well, so the native Civil 3D tools. We're going to jump into something else here and actually look at control and subassembly parameters with Dynamo and an example of where you can use this for transitions from one shape to another.

So this is all centered around what I like to call this morphing subassembly, and it's really intended to be another tool that you can utilize for forming complex transitions between different shapes, things like curbs, barriers, perhaps retaining walls. And essentially all this subassembly does is allows you to model a morphing transition from one shape to another, and the good thing about it is that we can actually apply that to lots of different shapes. It's extremely versatile just by changing the parameters, which we're going to do with Dynamo, and I'll cover that in more detail in just a second. And the other good thing about the subassemblies, it means you don't have to create complex transition logic inside your more complex subassemblies. You can simply apply this morphing subassembly to a region in the corridor between the two regions you would like to transition between.

So how exactly does this subassembly work? It's really quite simple. All points are offset from the origin point and the subassembly composer with a delta X and delta Y offset. Each point has an initial and final parameter for its X and Y component to form the initial shape and final shape, and those points are obviously connected with links to form the shape, which we can then extract a corridor solid from.

So when we transition between the initial and final offset of each point across the core of the region, we do so with a fairly standard transition formula. We simply take the initial X component of the point, add it to the delta between the final and initial condition, and then use a fairly standard transition formula, which you will be familiar with if you've done anything in Subassembly Composer before.

So you may be wondering, where does Dynamo come into all of this? And so I mentioned controlling these parameters. That was with Dynamo. If we were to input those parameter values manually, that could start to get quite time consuming, particularly for subassemblies where you might have 10, 15 points. That's 30 parameters to deal with.

What we can actually do, then, is obtain these parameter values from the regions before and after the transition, essentially forming the initial and final shape parameters from the existing shapes already inside the corridor. So let's take a look at this in context. In this example, we have a corridor with three different regions. Region 1, on the left-hand side of my screen here, we have this high-containment curb, and we're going to use the morphing subassembly to transition between those two curbs.

Now, obviously, we need to input the correct parameters for the initial and final condition of each point in the morphing subassembly, so to do that, we're going to use Dynamo to obtain the X and y. Offset to each point on the applied subassembly in the last station of the first region, and the X and Y offset again to each point in the first applied subassembly of the last region. And all of those offsets are actually relative to the subassembly's insertion. So once we've actually obtained them, we're going to use those values to populate the parameters in the morphing subassembly using Dynamo to form that initial and final shape. We can then go and apply the subassembly to the transition region in our corridor, as you can see in the image there.

So once again, this is another scenario where we can use the API. We're going to use the API to read these values. We can get the applied subassembly from the applied assembly in the corridor, and from there, we can get the points that belong to the applied subassembly with this AppliedSubassembly.Points property. Now, I know I've been referring to applied assemblies and applied subassemblies. Those are simply the assembly that's been applied at a specified station on the corridor's baseline.

So now that we have those calculated points that are applied in the corridor, we can iterate a loop through the points and then obtain that offset from the subassembly insertion. So to do that, we use CalculatedPoint.StationOffsetElevationToSubassembly, and that basically allows us to calculate the X and Y offset for each subassembly point from that subassembly insertion. And again, because these are API members, we can use these inside Python nodes.

And now we'll just take a brief look at Python behind this. Again, I really want to stress that the class handout goes over this in much greater detail, and you have all of these graphs in the class material as well. In this particular code snippet, we're first obtaining the values for the initial shape in the transition, so we're reading the last applied subassembly in the region before the transition.

In that first section of code, we're getting the applied assembly collection for that region and counting the number of applied assemblies returned. If that number is zero, we'll set the output to an error message, as we obviously can't continue executing that. Then we obtain the last applied assembly from the last index in that collection, and then moving on to the next section, once we have that applied assembly, we can then get the applied subassemblies and store them in a variable.

So we then iterate through the list of applied subassemblies, opening each object for read. Then if the name matches the input we applied for Subassembly Name, we store that applied subassembly object in the applied subassembly variable. Again, similar to the previous stage, if the subassembly is not found, we set our output to an error message and break that loop, as we can't continue.

So once we have that applied subassembly, we use the Points property to obtain the points, simply just the points used to form that subassembly. We then iterate through that list of points to obtain that X and Y offset, and we store the results in the dictionary on the two lines you see there. The one thing you might notice here is that I'm using the Y component of the point for the X offset and the Z component for the Y offset, and that's because the X component is the station, with the Y and Z actually being the X and Y offsets.

So once we have the output from the Python node and we've cleaned up that data, it's then just a case of simply using the Set Parameter value by NameNode from the Civil 3D ToolKit to actually then go and set the parameters on a morphing subassembly. So let's jump across to Civil 3D and have a look at how this works in practice. Just going to jump across to my Morph Transition drawing.

So in this model, we have a very small section of carriageway, just 10 meters. We have the high-containment curb on the left here, and this comes down to a normal half path curb. Again, I've just extracted the corridor solids, just to make it easier to actually see what's going on, and you can see my assemblies down here as well. We have the morphing subassembly set here, and currently, the parameters on this morphing subassembly are set to be the same for the initial and final condition. If I select my corridor and just rebuild that or turn on the region, you can see the initial and final condition is the same, which forms some horrible geometry there.

So what we're actually going to do is use Dynamo to update those parameters from these two regions, so let's open up Dynamo. Open up our Morph Transition graph. Again, this is all included in the class handout, and let's just have a brief run-through.

So we have the corridor object and the transition region name, the baseline name, and the initial shape subassembly, the final shape subassembly, and the morphing assembly and subassembly name. Then get that subassembly, set all the parameters to zero before we do anything. Get the baseline region, and this is the Python script that we previously spoke about, where we can actually calculate the offsets based on the region before and the region after the transition. We'll also get the morphing subassembly because we're going to use that over here to set our parameters.

So there's four groups of nodes here. One set's the initial X, initial Y, final X, and final Y, using the output from that Python script. So let's just run this, and you can see, it's managed to obtain those values because the morphing subassembly has changed here.

And obviously, we still need to rebuild our corridor to see that change take effect, and you can see we've formed that transition simply by reading the parameters in the start and end. It can also be applied to a variety of different shapes, so let's select the ending curb type and come to our parameters and change this to Display Curb. Rebuild our corridor, and you can see that that doesn't form a nice transition now.

Come back to Dynamo. View on a graph, so update the morphing subassembly. You can see that's updated. And if we rebuild the corridor, I will take into account that change, and we have a nice transition again.

So really, really powerful, and as mentioned, you can apply this to many different shapes as well. Think things like barriers, perhaps channels, and maybe even retaining walls where you're going from one shape to another. And it's just another tool for forming these, these transitions.

So moving on, then, one thing I really wanted to, again, articulate in this class is how Dynamo can facilitate further activities downstream and how useful data that we extract using Dynamo can actually be for downstream activities. In this next section, we're going to look at extracting some basic quantitative data from our corridors and then using that downstream, particularly around visualizing the quantities in PowerBI.

So the example we're going to look at uses some fairly simple Dynamo graphs centered around extracting three key pieces of information from corridors and that's feature line lengths, solid volumes, and basic cut and fill volumes. And this is all heavily driven by codes in our subassemblies which we'll come on to in just a second. And as I mentioned, using Dynamo as the mechanism to export that data then allows us to actually visualize these quantities in tools like PowerBI.

And that actually provides a faster way to obtain quantities from your model, so there's no need to set up QTO, assign pay items to codes, materials, create sample lines, all of that kind of stuff that you would be used to if you'd used QTO inside Civil 3D. We can actually just get that data directly from the corridors using Dynamo and then use it in visualizations downstream. And as I really keep mentioning, it's driven by making full use of point and shape codes, with the exception of those Earthworks volumes, which we'll create volume surfaces for in Dynamo.

So here's an example of how we can use the data we extract from Dynamo. You can see here, we have curb lengths by type, all driven by point codes and corridor feature line lengths. We have pavement volumes, both type and pavement course, so we can accurately determine our surface course volumes, subbase volumes.

And again, this is all driven by subassembly point codes and then pulling that data out from the corridors using Dynamo and writing it to Excel before tapping into it in PowerBI. And this is a really, really basic example. You could report anything you wish from your corridor and report using this method. But you can see how powerful that is in terms of what we can visualize just from some very simple data sets that we obtain using Dynamo.

So as I mentioned in the previous slides, this is all heavily driven by point and shape codes and utilizing them properly and to their full potential. In the image on the right there, you can see how different subassembly parameters are driving the shape codes. If a user selects a different pavement type or PSV their subassembly, that's actually reflected in that shape code there. Similarly, for the curb, you can see I've actually appended the curb type to the point code, which then changes depending on the curb type selected inside the subassembly parameters on that curb subassembly.

So for reporting lengths of different curbs and barriers and any linear feature, We're going to actually report coded or feature lengths. And how we do that is, essentially, we get each corridor feature line in its code, get the Dynamo geometry of those feature lines, so that's the polycurves and the curves that make up those polycurves, the sum of the length of the curves for each polycurve, and then write the point code and the associated feature line length to Excel. Pretty simple, but as I said, it's quite powerful what we can do with that downstream.

And for the solid or shaped volumes, we'll obtain the corridor solids for the specified codes-- and again, that's all built up using the code you see in the image on the right there-- get the volume of each of those solids, and then write the code and the volumes to Excel, fairly simple. And then finally, for the cut and fill example you've seen in the dashboards, we create a corridor surface from the top links using Dynamo, before again using Dynamo to create a volume surface from that corridor surface and the existing ground surface, before writing the volumes to Excel. Now, in the example I've shown, we've only covered basic cut and fill in this example, but there's no reason you couldn't create different surfaces in Dynamo from different lengths for things like topsoil stripping, pavement excavation, et cetera, et cetera.

So let's jump across to Civil 3D and again look at this in practice. Now, in Civil 3D, I have this fairly simple corridor once again, two lanes, a curb on either side, with some footway here as well, and I've switched to my curbing code set style just so you can see the different curb types we have here. We have K8 curb, K2 curb.

Again, this is all driven by the subassemblies, and the footway's here in this light pink hatch. So, really a quite simple corridor. If I switch my code set style-- you can see I also have three pavement types as well, again, all just driven by shape codes and things.

So by including all of that information in the codes in our subassemblies, we can really start to drive some downstream quantification. And to do that, we're obviously going to use Dynamo to extract and export that data. So if I just reopen Dynamo from this drawing here-- and we're going to open our Corridor Quantities Extraction graph.

Again, I'll just run through this very, very quickly. We simply select the corridor we wish to extract the quantities from, get the point and shape codes, get the feature line geometry by code, and get polycurves, curve length, and the sum of those curves, and then the total length for each curve, before creating a dictionary and then writing that to Excel. Similarly, for the volumes, we simply get the solids by the code we extracted using this node, get the Dynamo geometry that represents that solid, and obtain the volumes and the sum of those volumes, and write the data to Excel for that specified code.

For the corridor surface from the top links, we can use Corridor.AddCorridorSurface. Again, we've just used Top, and we've set the style to No Display. Now, this Pass Through And Wait For node, this is simply a code block with this Pass Through And Wait For, and all this does is tells Dynamo to wait for the output of this node before passing the data from here into this node, because we want to make sure that that surface is actually created before we get the corridor surface by its name.

So once we've done that, we simply just create the volume surface using the existing ground surface and the course of the surface we created, get the cut and fill volumes, before passing that to Excel. So let's just run this graph.

You can see we've reported feature line shapes and surface volumes. It really is quite simple. I've put just the point code and the length, the total length of the feature lines belonging to that code. Similarly, for shapes, we just use the shape code and the volume associated to each code, and even simpler with the surface volumes, just the name of the volume surface and the cut and fill quantities.

Now if we jump across to PowerBI, you can see how we're driving dashboards using that very, very simple output. We can see the curb length by type. That's all being driven by the point code and the curb type appended to the curb point code, and we have pavement course volumes, and cut and fill volumes and pavement types as well, as embedded in the shape codes.

So let's come back across to Civil 3D. I'm just going to close this and just close my Dynamo because we're going to rerun this. Now let's come to our subassemblies and make some changes to the parameters here.

Let's make all our pavement AP, so we'll do that by selecting the Pavement Type parameter. You can see my corridor rebuilding there. And we'll make all our curbs on the left-hand side HB2 curbs.

And back to Dynamo. Reopen our Quantity Extraction graph. Just re-export that data.

Now that's finished running, now we can see we just have the type A pavement there now. Let's close this, reopen PowerBI, and refresh our data. And you can see how our pavement types change as well as our curb length by type.

So again, this example is really, really quite simple, but it's just to demonstrate the downstream uses of data that you can extract and mine from your models using Dynamo. And you could, in theory, take this to the next level and run lane reports, width reports, slope reports. Anything that you wish to report from your corridor and visualize, you could do so using this method.

So let's jump back across to PowerPoint now and look at the next example. So let's move on and look at one final workflow around creating and updating code set styles. Anyone that's ever had to build a Civil 3D template from scratch has probably had to go through the task of building corridor code set styles.

And if you're managing a lot of different code styles and, indeed, code set styles, that can become quite time consuming with the out-of-the-box tools inside Civil 3D. For example, a typical code set style in my template will contain over 600 codes. That's your point, link, and shape codes combined to deal with all the different combinations I've described in the previous example with the subassembly parameters.

Now, that is a lot of codes to manage, and as we're all aware, there's no sort and filter functionality in the default Code Set Style window and no ability to bulk-add codes. And we can't import codes from external sources such as Excel or even another DWG. Yes, we can import from subassemblies, but when you have many different code combinations driven by parameters, it can also start to get quite time consuming to import them that way as well.

So again, the solution, use Dynamo to manage your code set styles in a more user-friendly environment like Excel. We can write our code set styles to Excel and then make batch changes, create change, add codes, and then read those back into your model or your template with Dynamo. And there's some really, really good nodes set up in the Camber package that allows us to do that.

So let's take a look at the high-level process here. Using Dynamo, we simply select the code set style to export, get the code set style items, the codes that belong to that code set style, get the associated styles, label styles, pay items that are associated to each code, and then write that data to Excel. We can then update the code set styles in Excel. It's a user-friendly environment. You can sort, filter, bulk-add, as I just mentioned, and then we'll use Dynamo to read the code set style from Excel, organize that data, and then update the code set style with nodes in the Camber package, plus a little bit of Python for feature length styles and things.

So let's just take a very high-level look at the graph. It's really quite simple. We select the code set style we wish to export, get that point, link, and shape codes and all the styles, descriptions that are associated with them, everything you see, essentially, inside that Code Set Style window inside Civil 3D, then we output that data to Excel. It really is quite simple.

So once we've written that data to Excel and made the changes to the code set style in Excel, we now need to read those changes back into Civil 3D, so let's take a look at a section of the graph for point codes. Again, fairly simple, reading the data from Excel, add any new points to the code sets style, filter out the point codes before setting the description, label style, pay items, feature line style, et cetera, et cetera. Then we ensure that those new codes are created before setting our feature line style via Python and then finally our marker style as well.

So let's once again jump across to Civil 3D to look at this in practice. So now that we're in Civil 3D, I'm still using the same DWG as our previous demonstration. In this drawing, if I go to my settings, you can see I have this AU 2023 code set style here, and this contains around 600 codes, combined point, link, and shape codes.

So let's say I wanted to make some bulk changes to this code set style, adding some codes, changing some styles, et cetera. Obviously, we could do this manually by coming into the code set style, right-clicking, adding a point, but we can obviously only do that one at a time. We could use the Import Codes functionality to import from subassemblies, but that can also be quite time consuming when you have a lot of different code combinations.

So I just find this workflow of updating these in Excel a little bit quicker and a little bit more user friendly to make changes to the code set style. So I'm just going to close this, come over to Dynamo, and we'll open our WriteCodeSetStylesToExcel graph.

All we need to do is select the code set style which we wish to export. I've already specified the location of the spreadsheet, and we're just going to simply run this graph. I will write all of those codes to Excel, all the styles, feature line styles, everything that's associated with everything that you would see normally in the normal Code Set Style window inside Civil 3D.

So let's say I want to make some changes to this code set style in Excel. You can see I have point link and shape codes here, and as I mentioned, this mirrors the window you would see inside Civil 3D. So let's just add a couple of new point codes.

Call this AU2023.1, set the description of AU23, set the style, the marker style, to No Display. Let's set the feature line style to Curb Back, and we'll apply that to this point as well. Let's say we want to make some changes to some existing codes.