Introduction #

One of our users raised a concern about a huge difference in the cut and fill values between our software and Civil 3D used by the contractor (the difference was around 90,000m^3 to 110,000m^3). This prompts us to further investigate the cause of the discrepancy despite the identical physical appearance of the Original Terrain and the As-Built.

In the project file shared by the user, there are two groups of survey data, (1) OGL WBC representing the original terrain and (2) ASBUILT WBC representing the actual earthwork done in the project.

As for the contractor side, there are three groups of surfaces, (1) OGL2 representing the original terrain, (2) A1 representing one area of the as-built, and (2) B1 representing the remaining area of the as-built.

Results comparison: #

The cut-and-fill results obtained by the contractor in Civil 3D have been made as the baseline for this comparison.

Based on the results obtained, the variations in the cut and fill volumes fall below the 10% range as normally accepted by the industry. But still, why are there some differences at all between the MiTS project file and the Civil 3D?

Troubleshooting Process #

This is not our first time receiving such inquiries from users and this is proven by a few case studies available on our website that involve discrepancies in earthwork quantities. We are quite confident that our software results are correct as running the same Civil 3D file in our software by integrating the data exactly as it is into our software will yield quite a similar result.

We have provided a step-by-step guide on this which emphasizes the importance of (1) controlling the survey data (mesh) area involved in the cut and fill and (2) having the same profile for the original terrain and the as-built when making comparisons to the earthwork quantities

Step 1: Controlling survey group mesh area #

In this case, it is a must for us to ensure the mesh area involved in the computation in MiTS is exactly the same (or very much similar) to the mesh area in Civil 3D because the “mesh area” is typically the area that is involved in the As-Built comparison between the two surfaces.  Note that while users can adjust the setting with our Alpha Value Settings feature in MiTS, they can’t do the same in Civil 3D.

The approach to triangulation (meshing) for survey data differs significantly between MiTS and Civil 3D. Civil 3D typically generates the mesh area to precisely follow the boundary of the survey data, while MiTS defaults to maximizing the mesh area.

Triangulations or meshes illustrate the connection and interpolation between the survey points to depict the terrain. From the provided images, MiTS generates more triangles compared to Civil 3D, likely influencing the discrepancy in the cut and fill volume. MiTS incorporates a larger as-built mesh area for the cut and fill computation, and the additional triangles connecting the points may portray a slightly different terrain. 

On top of this, the difference in the number of points used for triangulations between MiTS and Civil 3D is also suspected to be another factor contributing to the volume discrepancy.

The images above show the area in MiTS when the Alpha Value is set to maximum and boundaries are applied

Changing number of nodes and triangles in MiTS #

Following the discoveries above, the existing ASBUILT WBC group was separated into two different groups – A1 and B1 as per in Civil 3D. Then, the two groups were adjusted to;

• Replicate the number of points used by using ‘Use All Survey Points’ feature

• Replicate the number of triangles through the Alpha Value Settings

It should be noted that once we have a sufficiently large number of triangles ( in the range of thousands), the result will be reasonably accurate. Adding in more numbers of triangles won’t do much to improve accuracy.

Creating similar boundaries in MiTS #

Upon comparing the “controlled” triangulations in MiTS to the Civil 3D, a minor difference persists for the mesh area – something that is expected as both software have their ways of doing the meshes.

However, this variance can be addressed by utilizing our Boundary feature. By applying boundary to both areas, A1 and B1, users can precisely extract the cut and fill volume within the desired scope, just as what the engineer has done to the as-built areas in the project file. However, it is imperative to ensure the as-built areas closely match the surface boundary in Civil 3D, without omitting any as-built points.

Controlled triangulation area in MiTS and Civil 3D #

Results Comparison: #

To ensure that the MiTS and Civil 3D are comparing on exactly the same triangle or surface area, we apply both alpha settings adjustment and the boundary drawing. The above are the closest results when the area is almost the same in Civil 3D and MiTS.

Despite the triangulations in MiTS closely matching those in Civil 3D, including the number of nodes, triangles, and the boundary of the cut and fill areas – the volumes computed in MiTS still differ somewhat from those in Civil 3D. To put some numbers in comparison, the difference in area between MiTS and Civil 3D is 306*1000 m^2 and 309*1000 m^2 for Surface A1, a difference of about 1.08%, but the cut volume is 5.34% difference. There must be something else that is going on.

So we need to go to the source of Civil 3D, literally– the Civil 3D file used by the contractor is now needed.

Step 2: Checking on the profile of the OGL and As-Built #

Upon initial inspection of the survey data and the as-built profile, without conducting an in-depth comparison, the data uploaded in MiTS appears to be identical to that in Civil 3D.

But, this appears not to be the case as we will soon see.

Comparing the number of points for each group of survey data #

We noticed that only the number of points for the OGL used by the engineer in MiTS is slightly more than the Civil 3D of the contractor. However, this should not bring much difference if the x, y, and z coordinates of each of the points overlapping with the as-built are similar between the two software.

Reimporting the OGL into MiTS #

Armed with this insight, we decided to reimport the original terrain data to compare each of the points, ensuring there are no differences in the x,y, or z coordinates.

With 7000++ points available in the form of Tin Surfaces for the original terrain in Civil 3D, the best way to reimport the data is by using our MCIntegrator – a plugin that allows users to directly integrate or sync over the surfaces from Civil 3D into point form in MiTS without any loss of data and with minimal effort. 

Firstly, the Civil 3D file is bind to the MiTS project file and the surface, OGL2 will need to be defined under the parameters including its sync mode which can be referred from our MCIntegrator Tutorial Video.

Then, once the sync is successful, the surface group defined will appear as one of the survey groups in MiTS. As shown, the data might not appear to overlap the existing survey groups in the MiTS project file due to the difference in the origin point defined.

To resolve this issue, user can move the location of the newly synced survey group by using the Move feature. To easily move the survey point group, user can activate the text display setting and the necessary snap settings for the cursor to easily detect the point.

Lastly, rerun the cut and fill analysis with the reimported survey point group (OGL2) as the base surface and A1 or B1 as the comparison surface. Since the as-built has been separated, the cut-and-fill analysis will need to be done for each of the groups.

Results comparison (With survey points from Civil 3D file): #

After re-running the analysis with the reimported survey point group from the Civil 3D file of the contractor, the cut and fill volumes yielded in MiTS and Civil 3D are nearly identical with a percentage difference of less than 0.6%.

These results confirm our earlier suspicions regarding the disparity in the survey data utilized in both software for the cut-and-fill analysis.

And the mystery was solved when we compared the points one by one on the Input Screen.

Unraveling the truth #

With both the existing WBC OGL and the reimported OGL2 available in the same project file, the comparison can be done easily for each of the points.

By using the ‘Show All’ feature for survey terrains and showing the z values of all of the survey points via ‘Text Display Settings’, we can see that there are quite a number of points that have different elevation values between the WBC OGL group and the reimported OGL2 group!

Conclusion #

Upon closer examination of the survey data above, the comparisons for each point may reveal discrepancies in the elevation or the Z levels. In this instance, the variation can go up to 1 meter in certain cases, which initially might seem insignificant for the cut and fill computations, but when considering the entirety of the project area and the multitude of points involved, even minor differences can compound, leading to more significant disparities in the overall results.

This revelation underscores the importance of ensuring an apple-to-apple comparison when addressing disparities in the earthwork quantities– the only way is to use the exact same surface profiles for comparison. Appearance is deceptive; what appears to be the same point can fall apart upon closer examination. Which is why it’s always worthwhile to get the original source for comparison.