Find Volume Between Surfaces Not Working Correctly

I'm trying to calculate a volume between two surfaces for a mining blast. One surface is the ground level, and the other is the digging grade, or bottom of the drill holes. The top holes are true elevation, so it varies, and the bottom is more or less theoretical bottom, so it's mostly flat. I create a density grid for surface from a point shapefile. (I have a blast perimeter that is extended 15 ft out on each side that i am not constraining (filling out) to on this step). 

So now I have two surfaces, my elevation legend shows the correct range of elevation. I double checked the attribute tables, there are no bad numbers, there are some spots on the blast grid that are missing, but the density grid interpolates between them anyways.

Now for the volume calculation.

I've tried calculating the surfaces with no other parameters, and also constraining it to the blast perimeter, neither of which yield reasonable results.

From ArcMap: (Area of Blast Perimeter) x ((Collar surface avg) - (Bottom of Hole avg)) = volume of 8,450,592.5 ft^3
This is just basic math, and a ballpark number that I should be getting near.

From Global Mapper: Analysis > Measure Volume Between Surfaces > choose each surface > bound the calculation to an area which is my blast pattern perimeter >  run tool = volume of 6,145,133.6 ft^3

If I don't bound it to the blast perimeter, it's the same thing, which I guess makes sense, seeing as there isn't any data in void space.

But my question is, why am I getting such a bizarre result? I've had coworkers run the same data on different software, and they get very near the 8,450,592.5 ft^3 number. (within 200,000 ft^3, not 2,000,000 ft^3)

I'll attach the files I'm using

c1350-199 = collar (ground surface)
s1350-199 = bottom of drill hole (subsurface)
bb1350-199 = blast perimeter

Best Answer

  • geomanniegeomannie Global Mapper User Posts: 152
    Answer ✓

    I have now used other software to extend the grid to the edge of blast polygon using Kriging and a 5ft cell size. I now get a volume of 8,393,066ft^3, in line with your coworkers.

    There is nothing wrong with GM. You are just asking a lot from the fairly simple gridding algorithms available in GM. The elongate shape defined by the blast pattern means that the area difference between the blast area and shot pattern is large at abut 25%. The difference in areas is the source of the differences in volume.



  • AustinGeoAustinGeo Posts: 6
    I would like to note that when i say density grid, i mean elevation grid. Also, there were no missing spots in the pattern.

    I've also copied the outter drill holes in arcmap, and pasted them along the blast perimeter, eliminating the need for it, as my pattern now reflects the whole area. my result for volume was 8,362,812 ft^3. I feel like I shouldn't have to manually extend my plane (can GM do that?) but it appears it is the best method for this.
  • geomanniegeomannie Global Mapper User Posts: 152Trusted User

    When I use your data and calculate the volume, simply using the GM defaults, I get a volume of 6,145,125.9ft^3, pretty much the same as you.

    If I use a Kriging on a more sophisticated gridding package I get a volume of 6,634,082 ft^3, not too different but 8% larger.

    My main concermn is what is the area of the volume are you trying to measure? The blast polygon bb1350-199 that you sent has an area of 0.174km^2, The polygon enclosing the points is about 01303km^2, about 25% smaller. This difference is pretty close to the difference you are puzzling about.

    If you want to get get the volume within the blast polygon, then I suggest that you will need to extend the grid to the perimeter and use a suitable grid cell size. GM is not necessarily the best tool for this. Maybe if you add a few dummy points just outside the blast polygon with values equal to the nearest points, and then crop the subsequent grids to blast polygon area, you will get a better answer.

    BB.jpg 24.1K
  • AustinGeoAustinGeo Posts: 6
    Hi Mannie,

    I'm glad you responded. And to cut to the chase, this is where I'm uncertain if GM is able to do the job I am asking of it, or if I'm underestimating an acceptable method of making these calcs work. The one thing I didn't want to have to do, was make these "dummy" points beyond my blast perimeter. I know I can do that, and crop down to the area I want, but I was hoping that GM had a tool for that. Workers in my field use micromine and minesite and other sophisticated software that can extended these planes with their own algorithms. It doesn't appear that GM has those capabilities. If it's an acceptable method to copy my outer points, extend them out, and crop down to my desired area, then I am ok with that. Afterall, it is only ~15 ft. 

    I just googled this kriging method. Very interesting, but don't know enough about it to apply it.

    Anyways, thanks again, I think you've solved my dilemma. 

  • geomanniegeomannie Global Mapper User Posts: 152Trusted User
    edited April 12
    Hi AustinGeo

    GM is a brilliant bit of cost-effective GIS software but as you are finding, does not have very sophisticated gridding tools or allow a lot of control on gridding parameters. For most grid volume applications it is fine but part of your problem is the very elongate geometry of the blast area. This means that having a 15ft difference between the shot hole area and the blast area makes a big (25%) difference.

    If it were me, I would copy the outer points to just outside the balst area, use a smaller grid cell size and clip to the blast polygon. Its not elegant but would work. No grid derived from a series of points is a true representation of reallity. All you can do is to get to an accepatbel level of accuracy.

Sign In or Register to comment.