Corridor Workflow: Using profiles to control widths and more

[m_kingdon]

Hi all,

I want to present and discuss a workflow I used on a new project.  I have always been seeking a more intuitive and robust workflow for completing complex corridor projects.

This workflow uses profiles to control the widths of corridor assemblies and negates the need of external targeting offset alignments, polylines, or feature lines.

I decided to try this workflow on a specific project as the design had not been finalized.  I was fearful that the road centreline could change drastically and moving many polylines / feature lines would have been too much work.  I also found that working with offset alignments can be annoying whilst working on a previous project.

The workflow

I got the idea from another useful video by Jeff Bartels.
https://www.youtube.com/watch?v=W-f4Ep7TXyE

Here, he discusses using a custom subassembly which he calls a “NumberGenerator”.  This custom subassembly allows another subassembly to be linked to a profile.  i.e the width of a lane subassembly can be linked to a profile, so the profile controls the width of the lane.

I personally think “NumberGenerator” is a confusing name, I‘d call them “Profile Relays” as they relay the value of a profile.

Implementing the workflow

Anyway, I took this concept and used it to build a corridor that controls my road width, parking bays, footpath width and retaining wall heights.

The NumberGenerator subassemblies go in the assembly first, before the road, parking bay, footpath subassemblies.  A subassembly can only target values of another subassembly that is upstream.  i.e closer to the centre.

The road, parking bay and footpath subassembly are added, and their value (width) is overridden to the corresponding subassembly.

I then created copies of my road centreline alignment profile, reset the profile view datum to 0m and created a profile for each NumberGenerator

I then targeted these profiles in my corridor.  Each NumberGenerator subassembly targets one profile, i.e ParkingWidth NumberGenerator targets Parking Width profile.

See screenshots at end of post.

Opinions of the workflow

Pros:

• Surprisingly stable – I have encountered no glitches with my corridor so far.  Given that Civil 3D does not have to perform any spatial analysis (find polylines), instead the values are given as numbers from a profile.
• Adaptive design will follow centreline – it fulfils the main benefit of negating the need for offset alignments, polylines etc.

Cons:

• Long setup time – making the assembly, profiles and setting up all the targets takes a while.
• Skew widths of footpaths – a major and unfortunate limitation of corridor modelling in Civil 3D.  A possible workaround would involve extracting a featureline from the back of the parking bay and using that as the baseline for the footpath assembly.
• Fiddly, trial and error workflow.  Whilst the workflow adapts well to major changes in the centreline, making minor changes can be fiddly.  A dual viewport and station tracking setup is a must.
• Confusing to colleagues – this unorthodox workflow may require explaining to colleagues.  This might be unacceptable if many people need to work on the same project.

Conclusion

I hope one day to reach the golden hill of a perfect corridor modelling workflow.  Given the increasing demands from our surveyors, a few years ago a centreline and contours would have been sufficient, now they demand 3D strings along the kerbs.  I still worry that conventional corridor modelling is struggling to keep up.  I think this workflow is a good step on my journey.  The skew width problem and long setup time are real concerns though.

What do you think?  Do you use a similar workflow?  Do you have better suggestions?

I am happy to answer any questions.

The normal assembly without the overridesCivil 3D can not visualise an assembly with overridesSetting up the targets in the assemblyMake sure the number generator subassembly is above the normal subassemblySet up the number generators to target the profiles. Do not add any targets to the normal subassembliesMaking all these profiles and profile views can take some timeThis profile controls the widthChanging the profiles changes the modelFinal resultA problem due to Civil 3D only able to generator corridors perpendicular

[m_kingdon]

Some videos showing the workflow in action:
https://autode.sk/3iZwigM

https://autode.sk/3PrDsqr

https://autode.sk/3hnm8WO

I forgot to mention, I am aware of the new Corridor Transition Tool.  I think this tool will be a much easier workflow in future.  I just haven't found it very stable yet.  A graphical interface, similar to a profile, maybe via the project explorer, would be a nice addition to this tool in the future.

[cwr001]

Hey Mike,

as per usual, great stuff - thanks for this contribution! 🙂

I've been using the "NumberGenerator"-method for some time now and share your pro's and con's.

I'd add/expand on some thoughts:

* Civil3d still does a really bad job at handling complexity. No matter if you look at grading or more complicated corridors, it's really easy to reach a point where people fail to "keep it all in their head". This method at least allows to truncate some complexity from your design (you can get rid of some targets and alignments and so on).

I did encounter some bugs, especially when exporting 3d-solids - C3d at some point would suddently not extract the solids at every vertex of the profile(s) but along an 1m interval. I haven't tested it enough to really put my finger on it.

Working in a team with less experienced colleagues is a challenge indeed, as this approach really needs you to understand the way corridors work.

* You can (in my opinion) make the whole creation of assemblies a bit more cleaner (visually) by adding a SA.IsLayoutCondition to your subassembly. I've attached my number generator as an example (rename *.zip to *.pkt). It also tells you if there's no profile elevation found.

* I think Civil3d really needs to step up at one point and tackle corridor design, otherwise it will be replaced by software that does it better. We push more and more tasks to Revit because C3d is just bad to work with.

Corridor design did get some attention over the years but almost all of it (like the new transitions) is just cosmetic stuff - at its core it's basically the same glorified sweep it was 10 years ago.

I'd be happy if we got the functionality to rotate (skew) every intervall-instance as desired, had proper bowtie-functionality, easier PSet-workflows and - I'll die on that hill - "Dynamic Offset Profile with Superelevation from the Main Alignment" is one of the most needed things in this software! 🙂

[fcernst]

You said the new Corridor Subassembly Transition capability is unstable..

I'm curious now what problems you are specifically experiencing.. drawing crashing, drawing corruption, etc. ?

[m_kingdon]

I think I figured out my issue with the Transition tools.  I thought the greyed out values were locked values, like locked PVIs on a feature line taking elevation points from a feature line with a higher priority.  Nevermind, I am an idiot.

[fcernst]

Will that change.. or influence your Corridor workflow?

[m_kingdon]

Yes, I think the corridor transition tool fulfils the same purpose as the workflow I mentioned above, but without the need of having to use custom subassemblies or setting up all the profiles.

 I will still have to test the workflow thoroughly first though.  I tried using offset alignments in a previous complex road model, the workflow started well, but I started encountering difficulties later in the project. 

For example, I was using offset alignments with the widening tool to model parking bays along my roads.  The widening tool worked fine on the straight sections but refused to make changes to the offset alignment around corners.  I often had to add widening to a straight section of the offset alignment and grip drag it over the curve to get my parking bays modelled.  I also had to remove a few parking bays when the design changed and removing a widening region caused other regions upstream to shift/disappear. 

Overall, it was a nightmare.  I think I was pushing the intended purpose of the offset alignment too far. 

Hopefully, applying corridor transitions will be more robust and won’t suffer from these issues.

One trick I think AutoDesk missed was the ability to set the corridor frequency in these transition areas.  I added this as an idea here:

https://forums.autodesk.com/t5/civil-3d-ideas/corridor-transition-and-corridor-frequency/idi-p/11673...

[ChrisRS]

Most of this discussion is beyond me. I do appreciate it and am glad to see high level discussions like this. 

[sboon]

<chuckle>  

From back in the days when there were no custom subassemblies, unless you could program in VBA.

https://forums.autodesk.com/t5/civil-3d-forum/transitions-with-a-sub-assembly/td-p/4425639