Motivation #
How do you resolve earthwork quantity disputes?Anonymous
Frequently we receive such inquiries from our users. Often when our users– who are consultants– present their earthwork quantity results, their clients would come up with an alternative figure. Often, the clients will just present a single number, with no backup information, which makes result verification impossible.
That’s why when we received a similar query from Perunding CSS the other day (also there is no extra information beyond a single number), we felt that this was a golden opportunity to document down the steps we went through, to build a case study on “how to resolve quantity dispute with concrete actions”, so that other consultants who face the same problem can derive benefits too.
The Site Setup #
The original site is a palm oil estate, located at Hulu Langat. The owner wants to convert it to a residential area. A salient characteristic of a palm oil estate is that there are criss-crossing trenches connecting to each other throughout for irrigation purposes. How to represent those trenches could be a problem, as we shall later see.
The project looks simple enough– it only has a platform with a uniform level of 3.85m, and with a project area of around 217000 m^2. So what could have gone wrong?
The Result Comparison #
After running the project, Perunding CSS finds that MiTS gives consistent results across all 3 methods, DTM, Grid and End Area, which is about 307000 m^3. But the result from the contractor is quite different– about 325000 m^3, a difference of about 6%. No one expects such a difference for such a simple project. Shouldn’t they be exactly the same, especially for the End Area method?
So that’s where we are called to help.
Troubleshooting Process #
We published a guide on how to zero down the source and resolve the difference for precisely a case like this. But none of the points seem applicable. Since we are pretty sure that our results are correct ( running the same file in Civil 3D also yields similar results), we need further input from the contractor to perform further checking.
Step 1: Controlling for everything #
To ensure an apple to apple comparison, it’s vital to make sure that the contractor is using the same quantity method, with the same input parameter as us. Upon request the contractor sends us his keyplan drawing, the cut sections that define the end area method and also the complete result: section by section area and volume calculation. We are grateful to the contractors because without this information it won’t be possible to figure out the problem at all.
And upon comparing even the first few cutlines, it’s pretty clear that the results are already not the same. Take for example, the “cutline 1” results are already differing greatly (MiTS: 4384.436 m^3, contractor: 4578.175m^3 ). We need to drill into the individual section!
Step 2: Comparing for exactly the same thing #
We then compare the same cut section generated by MiTS and by contractor, and the difference is immediately apparent
The platform is all uniform level, so nothing to see. But the contractor cut section drawing contains “trenches” for the OGL, which MiTS doesn’t have. This could indicate that the surveyor point source is not correct because MiTS doesn’t capture the trenches.
Step 3: Digging through the source #
Where are the surveyor points coming from? We go through the original drawing, and find that they all come from the point_2b layer in the form of the Point objects. The immediate question is that are they adequately capturing the characteristics of the site?
We take a section of the keyplan, turn on “Show String lines” and zoom to one blue line.
We also use a mouse to hover along the line and get the OGL z value and compare them with the same polyline z values in the AutoCAD file .
Then we discover something important in the contractor drawing, we find that there are these “blue” lines crisscrossing the sites which seem important but somehow not featured in our MiTS project files. And then an epiphany hits us: the blue lines are the profiles of the trenches! The representation is like this: For the “main” trenches, the outer two blue lines are the slope of the drain that are going down ( about 1.3m wide), then the drain will have around 3.5m width ( which remains roughly flat), followed by another two blue lines with 1.3m width slope that are going up from the bottom.
The point_2b layer doesn’t even adequately capture this. This information is purely in another layer, the “cut” layer. Not a very intuitive name, and the contractor didn’t even mention this. So no wonder everyone misses it!
Step 4: Reimporting #
Armed with this insight, it’s easy to fix the project file.
All we have to do is to just reimport this extra “cut” layer by adding the extra surveyor points to existing surveyor point source. We also reduce the Polyline Import->Vertex Spacing at the import dialog, to 5 m so that we can adequately capture the trench profile better.
The number of surveyor points grows from 3000++ to 8000 +++. Now, from the keyplan, the trench lines are populated now with surveyor points. Turning on the string lines will show the mesh elements nicely constructed to represent the trenches. This gives us confidence that we are fixing the issue at the source.
Step 5: Mystery solved #
So when we rerun the cut and fill quantity analysis, and through enough, we get 323000 m^3 for the end area method ( about 324000 m^3 for DTM). Mystery solved!
We also examine the cut section and the 3D view, and now the trenches are visibly represented.
Conclusion #
The strategy as outlined above is always applicable when it comes to earthwork quantity dispute: request for the End Area Method comparison, and request for the cut section and the volume by chainage, and then you can do the same comparison in MiTS.
Resolving earthwork quantity difference can be a matter of detective work: you have to control for everything and ensure that you can do an apple-to-apple comparison; you have to ask the right thing from the other party so that you can narrow down the issue; you then have to find out the difference and convince yourself why one way ( and not the other ) is the right one.
But good software shall make the whole process easier. Perunding CSS is very grateful that the MiTS software contains all the necessary tools for him to carry out the investigation. The intuitive user interface, the comprehensive reports and outputs, along with no-nonsense tips from the support helps him tremendously in finding the root cause of the issue and explains the finding convincingly to the contractor.
About Perunding CSS #
Perunding CSS is a medium size consultant based in Pesiaran Prima Utama, Puchong. Their projects are mostly based in Klang and Hulu Langat. We would like to thank them for participating in this case study and providing us with feedbacks.
