Corridors vs. Profile Elevations

I recently fielded a support request that cited slight elevation differences between the tops of 4" curbs on the ASE corridor model versus the elevations labeled in the profile output generated by ASE in the same locations.

Unfortunately, It's True

Referencing images and feedback from the client and the source Code of ASE Civil applied to sample projects, I was able to verify this report independently. Here’s an image from the client illustrating their verification of the logical discrepancy between the methods used to elevate objects created in the drawing by ASE Civil despite referencing identical data sources in each instance.

The Core Issue

The Profile Generator rounds PVI Elevations from the Paving Model file to two decimal places.

The Corridor Model-builder uses all available elevation accuracy without performing ANY rounding.

The Resulting Error

Elevations calculated from the C3D surface built from ASE's Corridor Model as source breaklines (ASE's default when using the Surface Mgt toolbar) will yield different values in some areas versus the profiles.

Where this may occur is unpredictable. It all depends on the initial elevation and the gradient to the next vertical control point. Depending on which output you’re referencing for elevations, there may be differences of zero to a few hundredths of a foot. However the differences will be more prevalent at the tops of 4" curbs or anywhere the curb-height is not a multiple of 0.1.

Developer’s Response

I’m shocked that this issue lived so long in ASE without being noticed by me nor reported by anyone else. My guess is that maybe others are NOT referencing surface elevations when labeling curb in plan-view, e.g. grading plans? I have no idea.

Whatever the reason my mistake remained undiscovered for over a decade, it’ll be resolved in SP12 to be released on 11/22/2021.

So thereafter, ALL elevations from ASE corridor models will match their associated profile output since the rounding will be consistent between both systems.

FG Elevations via Surfaces

I've always discouraged surface sampling for labeling elevations from plan-view. Surfaces contain geometric errors between vertices due to tesselation of the surface to create a human-viewable object.

ASE Recommendations for Plan Labels

When I first developed the corridor modeling system, I knew there would be inherent errors in the elevation values sampled for plan labels because of surface tessellation. Increasing the elevation accuracy from a surface required unreasonably-high resolution to reduce the effects of tessellation.

Alternative Method

To eliminate the need to build huge surfaces, I provided a better method of retrieving these design values along roadway surface sections without referencing a surface object.

ASE Data Referencing

ASE Civil’s leader labeling command provides several options for selecting elevation sources when creating elevation-dependent plan labels as shown below:

Selecting the ‘ASE Road Data’ flyout requires selection of a road component (Center, Left, Right, etc.) to provide the finish design elevations for any station along that component.

The Advantage

When referencing ASE Data for paving design elevations, you’re not getting surface values, you’re getting the calculated value at a given station and (this is important) a component, based on the actual profile design on that component. It’s the most accurate elevation information that can be retrieved from your design model because it’s based on the source, not the output built from the source.

The Disadvantage

The party-crasher of the ‘ASE Data’ method of elevation retrieval is that you are bound to the selection of a point on the paving control line of a specific component.

Weigh The Benefits

So FG elevations from surfaces are not always spot-on accurate within 0.01’, a surface elevation may be retrieved from anywhere within a large area. FG elevations from ASE Data will give you bullseye accuracy everywhere, so long as it’s along one of the alignment’s design components (L1,L2,CL,R1,R2).

You’ll have to decide what works best for your project design. But at least after the next service pack is released, you won’t have to worry about elevation differences between ASE’s generated profile output and the corresponding corridor model output. They’re all gonna speak the same language now.