ASE Civil

Paving Features:

Rules & Limitations

Summary

ASE Civil’s Paving Feature system is unique. There has never been a system before that provides such a high level of detail and flexibility for road design, profile creation and corridor modeling.

Nonetheless, like any other functional system, there must be rules that must be followed for the system to operate as intended. This page is intended to help make ASE Civil users aware of the types of design configurations and definition habits that could be problematic.

The Evolution of a System

In the first version, Paving Feature definition was a primitive process, by comparison to what it is today. Each Paving Feature’s station, offset and elevation was typed into ASE Civil manually.

Today’s version, especially with the “Auto-Define” feature, synchronization with Civil 3D Layout profiles and other advances, has automated a large portion of the task. But it’s still not perfect. Paving Feature Auditing still needs to be added to move the system closer to higher state of maturity.

Unfortunately, until more intelligence is integrated, a potential does exist for injection of user error. Fortunately, there’s help. Faithfully following the rules & recommendations provided on this page will undoubtedly help new users avoid many common pitfalls that trap most new ASE Civil users.

Core Project Element

If Marker placement, selection order or Feature assignment violates logical rules for paving model construction, failure may occur. Even worse though, bad data could be generated. Failures in Paving Feature design will affect every other vertical system in the application, since they all reference paving model data.

Time Well-Spent

Paving Feature definition on a long, divided road, can be a time-consuming, tedious, monotonous task. However, it is truly a rewarding experience to see finished profiles generated from that data instantly!

Paving Feature definition is an investment in design and production which will yield tremendous benefits later. ASE will provide Corridor Modeling, dynamic curb labeling, Profile Generation, highly detailed surfaces and contouring with accuracy, speed & simplicity that no other software can offer.

About Rules

References, Not Procedures

Rules are for reference only. They are not recommended as a step-by-step guide to Paving Feature definition.

Conceptual

Some Rules are recommendations that may not apply directly to a procedure. It’s important to gain a general understanding of how these rules are applied, so examples are provided when necessary.

Self-Help Source

Rules are a recommended reference for troubleshooting paving design or data sharing problems.

Remember the Concepts, Not the Details

Keep these ideas in mind when designing with ASE Civil. Use them as guidelines on how to restrict Marker selections when locating individual Features or when combining multiple Features. This will maximize your success working with this extremely effective, accurate, flexible & rapid road modeling system.

Order of Application

All Rules are independent. There is no order of precedence for applying one rule versus another. Paving Feature definitions are not physically applied to the design data until the data is shared. Only upon sharing the data does ASE analyze the definitions and build the alignment’s paving model, which is a real-time construct of all Paving Features defined on each component of the alignment.

Recommendations

Share Data Frequently

Sharing data intermittently make it easier to tell when a newly added definition corrupts the integrity of the paving model by violating a logical-design rule. If data has previously been shared successfully, then more thereafter, then data is shared again, it’s much easier to catch a problem because you can likely remember what you just did.

 

Define One Feature-Type at A Time

Build the definitions gradually, starting with grade breaks.

Then share those definitions to make sure no violations occur. In most cases, for known definition errors, a dialog will advise you of the issue.

Once that Feature type is successfully added on the entire component or on all components of the alignment, sharing without issues, then you can confidently more on to the next required type of Paving Feature.

 

Rules

 

Grade Breaks Are the Minimum Requirement

An alignment component needs two or more Grade Breaks to be eligible for inclusion in the paving model.

If non- Grade Break Features are defined on a component containing less than two Grade Breaks, a crash is almost certain to occur when the data is shared.

 

Grade Breaks are Terminators

The first and last Paving Features must be Grade Breaks. They indicate the beginning and end of each component of an alignment.

 

In less words

The ONLY Paving Features that require ELEVATED Design Markers are Grade Breaks and INTERSECTIONS CURB RETURNS.

 

Vertical Curves Require a Single Grade Break

Vertical Curve Paving Features must also include a Grade Break definition at the same Marker used for the Curve definition.

 

Grade Breaks that are not located at a vertical curve PVI may not occur within the limits of a vertical curve definition. If your data export cycles are crashing for some unknown reason, this could possibly be the cause.

Apart from grade breaks, most non-elevated paving features may exist within the limits of a vertical curve definition.

Curb Break features must use an even number of Design Markers. The first Curb Break Marker on an alignment component will designate the beginning of the first break in the curb line, while the last Curb Break Marker will designate the end of the last broken curb section. Curb Break definitions are most commonly used between the ends of two adjacent medians on a divided road.

On-Grade features may be used coincident with (Sharing the same Design Marker with...) any other feature.

When an override is used in the description of an On-Grade feature definition, it will be stored in the current project and will not have to be manually typed-in again.