Alternative approach to Corridor/Template Design - 3D Linear Method

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Mark Plum — Mon, 19 Jun 2023 21:30:13 GMT

Mark/ Shawn:

This technique reminds me of the manner in which I used to "string" model in InRoads SS2. I used "Generate Longitudinal Feature" and Generate Transverse Feature" all the time in that package. In fact, I used very few- if any at all- templates. Instead, these strings were projections from other strings, etc. In this manner, I could produce truly detailed and accurate models which I could not do (or with too much pain) with templates alone. There is much talk about how ORD produces "true" 3D models; I had been doing that for decades with InRoads; these were finished grade and subgrade DTM's (additional lifts would have produced much pain as well).

ORD is better in that this manner of thinking can better produce pavement lifts, coatings, and additional materials, of course. Still, the overall idea is sound.

Best Regards,

Mark

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Mark Plum — Mon, 19 Jun 2023 21:19:03 GMT

Smart stuff here, y'all. Thanks for some additional ideas!

Mark

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Shawn Cooke — Mon, 19 Jun 2023 20:58:48 GMT

I've used a very similar logic Mark! I've had this anchor type of control in larger/wider projects... Really helps break out corridor "buckets" and processing within or outside the main corridor dgn. Typically utilize Corridor Reference Point Controls that are used to grab the edge of internal pav corr edges. I try not to place a hinged corridor or linear template directly to another corridor - there are always exceptions in the case of smaller range Linear Templates, but cause too many issues otherwise. Depending on the control needed, I use the same alignment for all respective hinged corridors (so they all use the same alignment when possible) and float the actual tie point (e.g. used for control) away from the template origin. When necessary the Secondary Alignment option for the Point Control can be toggled to have the external corridor's angle at a 90 degree from their tie point. [Example project: Multi-Lane project, 4 pav corridors (2 corridors ea. direction, split at crown point), 2 End Condition corridors for each direction.]

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Chris Roym — Sun, 18 Jun 2023 16:45:43 GMT

I am relatively new to Openroads and I have started using and advocated in my team this approach in modelling our corridors. The ability to change and apply different types template side grading situations is very simple, as opposed to building complicated templates with end conditions, display rules etc.

Coming from Inroads, I have created corridors built with templates that tries to capture all possible design situation that may occur on my design and it has always been a struggle for others to decode how I did my work, and vice versa. But is not the case in ORD using this method. With this methodology, I've also noticed that learning curve was faster because some of guys I've worked with have never used corridor modelling or templates in Inroads, tries to avoid it but suddenly, they were doing it in ORD. All they have to start is with base template and corridor, and attach the different side grading templates that have already been prepared.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Mark Shamoun — Sun, 18 Jun 2023 12:20:21 GMT

btw i have the Model Container Idea here if you want to vote:

Introduce the concept of seperate | Bentley OpenCivil Ideas Portal (aha.io)

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Mark Shamoun — Sun, 18 Jun 2023 12:16:22 GMT

Hi Aaron,

You are preaching to the choir regarding the power of scripted design model generation using input files in MX. I am of the opinion that there is no more efficient (and logical) method of building a 3d design model as that, but the move to Digital Engineering focused delivery has moved us into a more graphical way of working. If only MX just got enhanced to incorporate 3d solid/Mesh components (like 12d) it would all be looking much much different right now.

The challenge with building a scripted input file-like system for ORD is not the model building part of it, but how to manage referenced data and keeping object IDs alive for downstream referenced dependencies. This referencing, although very powerful, is also a curse for automation from what i am seeing. Because you can have copies of the same reference attached, all with elements with the same name, my understanding is the way it identifies unique instances of elements is using an attachment instance identifier and not simply the DGN file\model name. This is a big general problem with the software, meaning that the specific attachment instance is where the links are made so if you detach a reference, that link is broken and it doesnt see it as the same thing if you reattach the exact same file (i hope this all makes sense).

The key to opening up ORD to automation is to introduce the concept of unique Model containers (like MX and 12d, etc. etc.). If specific DGN model links were made using a redefinable unique ID like Reference Logical name for example, instead its specific attachment instance, then you could script it all by telling it specifically what DGN model you want the data to use and the data link would not be broken permanently if a DGN was detached, etc. So you could have a delete/create process like an MX input file Nest or 12d Chain quite easily. I believe this is why Civil 3D uses Data Shortcuts for linking reference data and not direct xrefs, because there needs to be a cataloguing of all objects to keep links alive.

There's nothing stopping the creation of a scripted geometry and corridor creation process right now, the issue is that you would lose the smarts of dynamic object linking and the persistence involved with that. If we got a Model Container enhancement that allowed for Model ID - Feature Name linkages instead of the attachment ID - element ID one we have now - sky is the limit. You could go into a reference file, delete everything, rebuild it and as long as the names were the same all links would stay alive (saving alot of grief users have now trying to keep elements alive).

Imagine how much simplier it would all be - instead of Corridor Reattach, a couple of simple properties for the corridor (Model ID, Feature Name), likewise so for Offset Geometry, Corridor Point Controls, etc. etc. There is a debate on how you would handle nested references, but in my opinion the software shouldnt allow you to build relationships to these. After some hard lessons over the years we only use nesting for export container files and Drawing Production workflows. It would likely improve performance as well if the Civil Model side of things didn't do Nesting as well IMO.

You can see i've put some thought into this hahaha...

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Aaron van der Heyden — Sat, 17 Jun 2023 09:51:57 GMT

I'm almost only using this method as I have seen no benefits, only problems, using the corridor method that Bentley promotes. It is almost completely useless in most cases, especially in urban situations where you're tying into a lot of existing infrastructure. It is fine if you are doing long linear greenfields projects and investigating alignment routes, but once you get into the detail, trying to achieve every situation in a template is near on impossible and provides more problems then benefits.

I think that Bentley need to consider reassessing the way OpenRoads works in the background, and I hope that they look at trying to implementing some system similar to the way input files from MX used to work, although this thread dates back to 2018 so I'm not holding my breath. Not only did input files keep a record for others to follow in a logical manner, in files that were barely 100kb, but if anything were to go wrong you could recreate the model from scratch in 5 minutes. In fact, the first thing that would be done when running an input file would be delete the model and then create a fresh model.

Off topic, but this also applies to creating cross section and long section sheets, where you could make a modification in an input file in 2 minutes, or even copy an existing one and change a couple of strings using find and replace, and you would have your sheets ready to go. I'm yet to see any huge benefit of these named boundaries, besides the fact that they take 10 times as long to create and if you make a mistake, its back to the beginning. Gone are the days of changing a few lines of text.

A mix between running input files and having templates would make OpenRoads nearly perfect, in fact writing macros in MX were pretty close to the way templates are created, it was just missing the "Component" element which is basically joining strings together in 2d and extruding them along the horizontal and vertical to create a 3d element with volume.

I am a fan of the depth of detail you can achieve in OpenRoads, however getting there is certainly more painful than it needs to be.

Mark, I know you're a talented guy so do you think it would be possible to create something that that will allow us to run MX style input files to create alignments and apply templates to those alignments from the template library? Or would that be beyond the capability of the software?

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Mark Shamoun — Sat, 17 Jun 2023 08:27:28 GMT

Hi all,

Just resurrecting this thread based on some developments in this space.

We have now completed 2 of the largest road infrastructure projects using a watered-down version of this workflow and have found it much more efficient and superior to the full cross sectional template workflow we used since our first OR technology project around 8 years ago.

As our standard workflow we now have 1 corridor for pavement edge to pavement edge (so 2 for dual carriageway projects) and attach "compound" Linear Templates to the edges, eg. a concrete barrier LT is attached to a corridor pavement edge linear feature and then another LT is attached to the back of the barrier, etc etc.

There can be some draw backs for users who are not aware of certain things, like the need to "anchor" some LTs to a static feature like a point or line to ensure it doesn't move when parent linear feature extents change, ensuring the parent LT linear feature isn't deleted so it's child LTs don't vanish or reattaching a child LT to another parent when a component needs to be removed, etc. But we do have processes to accommodate this.

Has anyone else moved to a workflow like this in the years since Alex's original post? We found it almost a necessity to speed up project delivery and minimise template maintenance that was a nightmare for the poor soul who had to come in after.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Dennis Wadas — Thu, 20 May 2021 16:46:16 GMT

If I can offer a word of advice with this method: Make sure you have a good plan on how to name corridors, alignment, profiles, etc. Just think about getting to the earthwork part of the job. You will want to be able to simply select all the corridors you need for that earthwork in a simple list. If you name them in a good way, they will pop up in a nice alphabetical list that you can select in one big chunk. If you name them bad you will spend all kinds of time hunting and pecking through your corridors to select the right ones. This is so important that I have heard of some modeling managers actually deleting corridors if they are not named per the plan.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Alex Badaoui — Thu, 20 May 2021 14:52:43 GMT

Some have said their email gets blocked when sending to the above email address. If you have a query and you have trouble emailing me, send it to alexander.badaoui@gmail.com thanks.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Alex Badaoui — Fri, 01 Nov 2019 14:11:49 GMT

Thanks for reaching out. Hope you find the videos I sent useful to share with your team as an alternate approach to modeling complex jobs.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

David Coe — Thu, 31 Oct 2019 17:13:38 GMT

Hi Alex,

Thanks very much for sharing this information. I plan to share this post with coworkers. You mentioned you have tutorial videos you are willing to share?

Can you please email these tutorial videos to me?

My email: david.coe@wsp.com

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Alex Badaoui — Tue, 07 May 2019 22:01:27 GMT

What Zane is pointing to, which he demonstrated on a project we are working on together, is the processing time for analysing end conditions with an active terrain model is very resource intensive. If you have corridors that don't require an active surface (like pavement, curbs, etc), placing them in a separate file to the corridors that depend on the active surface (like End conditions) makes the processing for both files noticeably faster than if they were in the same file.

It may not seem logical, but 2 files with less data works faster than 1 file with lots of data. I can't speak for the processing time on ORD Connect, but in SS4 it makes hours of difference in processing time, especially on large projects with multiple alignments.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Zane Pratt — Tue, 07 May 2019 20:17:42 GMT

I was suggesting modeling the pavement with corridors and modeling the end conditions with corridors and point controls or linear templates. Modeling all the pavement with surface templates is difficult do the geometry limitations in ORD. Not sure about civil cells and end conditions. Seems a little complicated.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Josh Shen — Tue, 07 May 2019 19:55:45 GMT

Zane,

If I understand you correctly, I would model only the pavement in one file, and then reference that file into another dgn to create the end conditions based on the 3D geometry created by the pavement file. This would eliminated the need to clip the main corridor, as I can create multiple corridors for the end conditions and leave gaps where I need to insert a driveway.

Also, many tutorials on the web trains people to build the end conditions along with the pavement into the civil cell. I'm assuming I would only create the pavement with a surface template and add in the end conditions once the civil cell has been placed.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Zane Pratt — Tue, 07 May 2019 19:00:20 GMT

The best advance I would give you, is model using a modular approach. Break your corridors into small segments and files. Eleven miles is a long corridor to model. Many designers out there still try to model larger areas like you have described in one file and one giant corridor. This can be done, but the processing and complexity of the corridors create a lot of problems down the road. To help with processing , I would suggest modeling your pavement separate from your end conditions and also separate the driveways (civil cells) into separate files.

The existing terrain will get processed from the limits of the terrain, so clipping the existing into a smaller piece or pieces is very beneficial to processing as well. Also , only attach the existing terrain to files that require it for processing. i.e. end conditions.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Dennis Wadas — Tue, 07 May 2019 18:44:16 GMT

I think the best bet would be to split you main corridor into several dgn files. I think Alex told me one time to keep them under 2 miles. Maybe try 1 mile with all of your civil cells you are using. I normally wouldn't use a civil cell either - but driveways are so easy.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Josh Shen — Tue, 07 May 2019 18:36:16 GMT

Thank you all for the quick replies.

So we did create civil cells for the driveways, but unfortunately, at a certain point, the model begins to process really slowly each time you try to change a dimension on a civil cell. Eventually, we had trouble even opening the files themselves.

We suspected that this was because we clipped the main corridor with the civil cell terrain boundaries, so it had to reprocess the entire model every time a change is made. So we resorted to not clipping the corridors; however, this affects the appearance of the final model. Has anyone discovered a threshold of civil cells that a DGN can contain before it starts crashing, or is there a list of do's and don't's (things to watch out for, not just how to create them), when working with civil cells?

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Alex Badaoui — Tue, 07 May 2019 18:34:21 GMT

Civil Cells are a great tool to use in a limited circumstance. The creation of a custom working civil cell is extremely complex, but if you can master its creation it would save a series of corridors using Linear Method.

If you were to approach it using linear method, what I have done (as I don't use Civil Cells because they are difficult to diagnose, and novice users have a hard time using them) is constructing break lines for the driveways, and applying surface templates over small terrain models to cover the driveway area using these break lines. The only corridors created are the curb corridors, as the curb height is controlled parametrically or via vertical point controls.

It is extremely fiddly to do this approach, but so is the set up in getting a Civil Cell to behave the way you want it to, and be able to modify it later. In this kind of micro-modeling, there is no simple solution.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Dennis Wadas — Tue, 07 May 2019 18:20:38 GMT

Josh,

Just like Mark said below, I'd try to put together a civil cell for those driveways. That would save you tons of time.

There is a key-in command "Corridor Reattach" that will allow you to associate an existing corridor to a new alignment. Do some searches on this and I'm sure you'll love it. Just remember that changing the alignment cause stations not to match the old alignment so you will need to change station ranges on your controls.

Dennis

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Mark Plum — Tue, 07 May 2019 18:12:25 GMT

I am not sure which software package you are using, Josh. (I am on ORD Connect 2019 R1). Personally- and in keeping with the aforementioned package- I would not use the linear method. I would create a civil cell and place the driveways in that manner. Nonetheless, this discussion has been entirely interesting and extremely thought provoking.

"...although the lack of ability to insert VPIs is still a pain": VPI's are inserted using the MicroStation command "Insert vertex" (BENTLEY: Please, please, please repeat that command within the geometry workflow rather than a MicroStation command!).

Mark

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Josh Shen — Tue, 07 May 2019 17:53:41 GMT

Hello,

We are working on a project that requires modeling 150+ driveways along a 11+ mile rural corridor. How would you all suggest modeling these with the linear method?

Also, this question is not particularly related to the linear method (which I've been exploring, and it seems great), but since there are a lot of experienced modelers here, I'd thought I'd post it here:

When you're in the early stages of planning, and the alignments and profiles can change from day to day, what's the best way to set up the corridors so that you don't have to redo your model with every change? If I want to insert a curve into an alignment, it seems that the only way is to break it and re-complex the road. However, this effectively creates a new alignment that is no longer associated with its previously dependent corridors. Edits to profiles seem don't seem too bad, because you can break it and set the new profile as active again, and the corridors will still process (although the lack of ability to insert VPIs is still a pain); it's the changes to the alignments that make me think whether or not modeling is really effective for early stages of planning.

We also experienced a situation where another colleague made changes to a profile in the SS2 way with legacy tools, but since you can't import a profile without also importing a new alignment, the change cannot be perpetuated through the 3D model without recreating everything. Is there a workaround for this transition between SS2 and SS4?

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Alex Badaoui — Fri, 21 Dec 2018 14:21:57 GMT

The less information in each corridor, the simpler the template becomes, the less controls per corridor need to be applied, and the faster the model will process. By having all elements modeled into separate corridors, templates are recycled and therefore always consistent throughout every project.

Ditches especially should be isolated, even into their own DGN. Corridors that require a target surface (active terrain model) absorb drastically more processing power than those which do not require a target surface. A practice we follow here is a DGN containing all the lane, curb, shoulder, barrier, etc corridors (i.e. all corridors that do not require a target surface, non-end condition corridors) and a separate DGN containing all end condition corridors. Even though this is more data to manage, the processing time is drastically reduced. Once a terrain model is active in a DGN, processing becomes an immediate issue. By using it when needed, the rest of the model works better.

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Frank Zeng — Fri, 21 Dec 2018 07:36:26 GMT

[quote userid="682396" url="~/products/road___site_design/f/geopak-inroads-mx-openroads-forum/168424/alternative-approach-to-corridor-template-design---3d-linear-method/495409"]that seems to work best in my opinion is to model pavement and end conditions as separate corridors. [/quote]

I second that point, but what about road shoulders and roadside ditches, should I build them into separated corridors or merge them into the end conditions?

RE: Alternative approach to Corridor/Template Design - 3D Linear Method

Dennis Wadas — Fri, 07 Dec 2018 15:12:14 GMT

I love that the videos are on the Bentley site too. Sometime videos are on YouTube and my company actually blocks the youtube site for obvious reasons. Thanks again Scott!