Using for pond volumes

[gotjoshua]

I cloned this repo and tried the examples which worked perfectly.

Then i tried with some of my drone data and shapes, with the above and below settings, but always got 0, 0.

Should the plugin work to calculate the volume below a shape?

I want to use/adapt the code to calculate the volume of a pond/lake to be...

[AlisterH]

I am not the maintainer, but I'd suggest providing a copy of your data which doesn't work.

[gotjoshua]

Thanks, I'm not even sure if it doesn't work... That's why I am asking if it is meant to calculate this kind of volumes or only piles...

Perhaps the issue is that the negative volume is not fully contained... I can of course provide images and data if someone wants to have a look

[AlisterH]

Yes, it works and it is simpler than that - at least if you are using "accurate approximation" it doesn't matter whether the base level is entirely above the DEM, below it, or intersecting it.

Here is a wetland I designed: If I calculate volumes to the level of the crest using the red polygon I get 270.9 m³. The spillway which does not reach the crest level does not magically break the calculation. You can also see the DEM doesn't fully cover the polygon extent and even that didn't cause a problem. If I use a polygon that includes the whole DEM I get 275.5m³, obviously this includes volumes outside the crest, along the south/eastern side of the wetland.

[AlisterH]

We use 12D for earthworks design, and comparing its volume reporting functions with this plugin:

• in 12D there is nothing like the X/Y sampling step size. Maybe these make sense for something like this that works with rasters (12D works with TINs), although I would have thought you'd just use the native resolution of the raster.

• the 12D storage volumes calculator allows to specify a (vertical) increment, so you get a stage-elevation table. The default output format is quite unwieldy, but you can use an .xsl template to get something like this in either plain text or html format:

  
  PANEL SETTINGS
  Tin wetland
  Minimum height  1.650
  Maximum height  3.250
  Height increment    0.050
  Fence name  FEAT-P-RAIN GARDEN
  Fence model 0 dwg in FEAT P RAIN GARDEN

Height (m) Volume to height (1000 m³) 1.650 0.000 1.650 0.000 1.700 0.000 1.750 0.000 1.800 0.000 1.850 0.000 1.900 0.001 1.950 0.001 2.000 0.002 2.050 0.002 2.100 0.003 2.150 0.004 2.200 0.007 2.250 0.009 2.300 0.012 2.350 0.015 2.400 0.019 2.450 0.024 2.500 0.034 2.550 0.045 2.600 0.056 2.650 0.068 2.700 0.081 2.750 0.095 2.800 0.109 2.850 0.124 2.900 0.140 2.950 0.156 3.000 0.173 3.050 0.191 3.100 0.210 3.150 0.229 3.200 0.250 3.250 0.271

Summary Polygon plan area: 426.018

As well as the volume, 12D outputs a plan area at each elevation, but when writing my .xsl template I chose not to report that.

- Rather than allowing you to specify a vertical increment, 12D's "Volume between tins" calculators (which are used to calculate earthworks cut/fill volumes), allow you to specify a "depth range" file, which looks like this:

-2.5 -0.5 "vis stone2"
-0.5 -0.4 "rgb(183,141,73)"
-0.40 -0.3 "rgb(199,161,105)" -0.30 -0.2 "rgb(215,181,137)" -0.20 -0.1 "rgb(231,201,169)" -0.10 0 "rgb(247,221,201)" 0 0.1 "rgb(226,253,227)" // Fill 0.10 0.2 "rgb(202,253,203)" 0.20 0.3 "rgb(178,253,179)" 0.30 0.4 "rgb(154,253,155)" 0.40 0.5 "rgb(130,253,131)" 0.50 0.6 "rgb(106,253,107)" 0.6 2.5 "rgb(73,244,74)"

As you can see, the increment can vary.  I'm not sure why they use two columns to define it or what happens if you specify increments that overlap!
The third column is because the tool also colours the plan.

It would be very useful especially to hydraulic modellers if this plugin could report volumes using a user-specified vertical increment.  It might be nice if it could also use something like a "depth range" file too, but that would obviously be more work and I don't think anywhere near as valuable :)

[distbug]

We use 12D for earthworks design, and comparing its volume reporting functions with this plugin:

* in 12D there is nothing like the X/Y sampling step size.  Maybe these make sense for something like this that works with rasters (12D works with TINs), although I would have thought you'd just use the native resolution of the raster.

* the 12D storage volumes calculator allows to specify a (vertical) increment, so you get a stage-elevation table.  The default output format is quite unwieldy, but you can use an .xsl template to get something like this in either plain text or html format:

As well as the volume, 12D outputs a plan area at each elevation, but when writing my .xsl template I chosen not to report that.

* Rather than allowing you to specify a vertical increment, 12D's "Volume between tins" calculators (which are used to calculate earthworks cut/fill volumes), allow you to specify a "depth range" file, which looks like this:

As you can see, the increment can vary. I'm not sure why they use two columns to define it or what happens if you specify increments that overlap! The third column is because the tool also colours the plan.

Very interesting stuff, I'm not at all familiar with 12D. Thank you for sharing.

It would be very useful especially to hydraulic modellers if this plugin could report volumes using a user-specified vertical increment. It might be nice if it could also use something like a "depth range" file too, but that would obviously be more work and I don't think anywhere near as valuable :)

As far as I understood what you described I also do not think a depth-range file would be useful. As far as using the native raster resoultion size, I tend to agree that it should probably be set to that by default without user intervention. If I remember correctly the reason it is adjustable was that during testing sometimes the qgis bounding-box would cut down precision by being badly placed e.g. right on top of the centroid of the native raster resolution, in such cases reducing the step size helps with precision.

As for the vertical increment feature, I think that should be doable, though one would have to change a few things for the approximation. But more importantly I'm not sure it is immediately obvious (to an average user) what this value would do. I'll open up an issue for it as I think it might be interesting.

[AlisterH]

As for the vertical increment feature, I think that should be doable, though one would have to change a few things for the approximation. But more importantly I'm not sure it is immediately obvious (to an average user) what this value would do. I'll open up an issue for it as I think it might be interesting.

A label can make it clear what the option does. Add a checkbox option called something like "calculate a volume-elevation table", as well as a spinbox to specify the elevation increment.
Expand the wording if you don't think that is clear enough, e.g. "output a table of volumes at different depths".