Total Rainfal in Waterbalance

Comments

• RudolfNL

  April 2021

  Hi Thies,

  
  

  looking at your report, it's clear you're taking a very analytical route through the functioning of the platform. A few details may help to clarify some of the results you are seeing. What you are doing boils down to checking rainfall in the water balance, and checking rainfall with a query at various grid sizes.

  
  

  For technical reasons, the "edge" of the water model is not one but two cells wide. This means that on a model of 500m x 500m, with cells of 1m in size, rather than 1996 cells being inactive, in fact 3982 cells are inactive. This was also noted in the link you indicated in your report, but I believe its good to emphasize this. This causes the differences in the TPG results, which other than that difference are entirely as you would expect.

  
  

  
  

  
  

  The other results are due to the difference between vectors (polygons/shapes) and grids (cells and rasterization). Taking a look at the query you are using you obtain the result, which is :

  SELECT-GRIDVOLUME-WHERE-AREA-IS- idarea-AND-GRID-IS- idoverlayNeerslag-AND-TIMEFRAME-IS-i

  While the GRIDVOLUME clause retrieves data from a grid, the AREA clause acts as a cookiecutter over it. If there is a grid cell of 1m by 1m, with 1m of water on it, that cell contains 1m3 of water. But the relevant Area may only cover, say, 40% of that cell, meaning only 0.4m3 of that water is actually made part of your results. And the more the cells extend beyond the polygon of the Area (both in quantity and in size), the more water is left out.

  
  

  You can verify this behavior by using a very large grid size, placing a small Area within a single cell and reading its gridvolume result, then expanding that Area's polygon without it exceeding the boundries of the cell and querying again. You will see that the result has increased.

  
  

  
  

  
  

  The reason the built-in water balance does report all the water, is because the water balance is constructed by counting the amount of water in each (calculating) cell, multiplying it by the relevant grid size, and the result is returned. I.e. no cookiecutter.

  You will probably find that if you remove the AREA clause from your query, that the results match up exactly, because in that case the GRIDVOLUME of all cells is counted, and cells which are not part of the calculation (or experience no rain for other reasons such as defined rain areas) would contribute 1m2 * 0mm = 0m3 of water to your total.

  
  

  As a final detail to point out, there is a point in the report where it is stated that a polygon has been drawn perfectly aligned to the grid, to avoid cutting through cells. For technical reasons that behavior cannot be guaranteed. When a polygon is "perfectly aligned" with a grid, the is some uncertainty about whether the polygon data is "in" the adjacent cell or not. However, this is not an issue as in practical situations, and even based on the exact mm-level positioning of the project area, the real-life data is effectively always out-of-line with the grid. The reduction of the grid cell size for greater accuracy is how precisely the data is assigned to the underlying grid.

  
  

  
  

  
  

  Be sure to leave a reply about how this corresponds with your findings so far!

  
  

  Kind regards,

  
  

  Rudolf
• thies

  April 2021

  Dear Rudolf,

  
  

  Thanks a lot for your reply! It is really helpful and I think it explains already quite a lot of my findings.  I think I get the point you address about the cookie cutter. This would explains situation IGD and IGP.

  I tried the suggestion of removing the AREA clause from the query, this resulted indeed in the same values as shown in the water balance.

  My query now is:

  SELECT_GRIDVOLUME_WHERE_GRID_IS_ idoverlayNeerslag_AND_TIMEFRAME_IS_i

   

  Now I am only left with the last situation, IGH (Interesse Gebied in de Hoek van het project). In the picture below, I put the results of this situation. (Note that I used the “new” query for Method 2.)

  So now the query equals the water balance, But in the 3D situation, the grid size does not have an influence on the precipitation amount, where in the empty project it do play a role. Is looks a bit strange. Or could this be because in the left situation, my area of interest exactly cuts over the edges of the project raster cells, where in the right situation my interest area cuts through raster cells.? 

  

  
  

  Kind regards,

  
  

  Thies
• RudolfNL

  April 2021

  Hey Thies,

  glad to hear the big ones are resolved.

  The last numbers are actually much simpler to explain: The water balance shows its results in round numbers. Each of the query results, rounded properly, matches the water balance.

  As an important extra note here: this is also where the level of significance such rounding errors may crop up, but are not practically worrysome. As a trick: if we take the largest deviation, which also happens to apply to the smaller of the two surfaces, you can compute the difference for any given location as: ( 475.4 - 475 ) / 24053.664 = 0.00001662948. That mean that for any spot in your area, the water level you are calculating bay differ by just 0.017 mm! Be sure to keep this in mind while narrowing your calculated results to numerical expectations ;)

  Kind regards,

  Rudolf
• thies

  April 2021

  Hello Rudolf,

  Thanks a lot for your reply. I know that the little diffenrces between the query and the water balance has to do wit rounding/significance. These difernces are indeed not importand.

  I was left with the situation that it seems like the grid size had influence on the precipitation amount in the empty project, but not in the real project. In my previous reaction I sugested that this could be becaus the left situation my interest area exactly cuts over the edges of the project raster cells, where in the right situation my interest area cuts through raster cells. I chaked this by taking other intest areas, and his was indeed the case.

  So for now, all my questions are solved.

  However, I am interested, why is the "coockie cutter" not used in the waterballens? I think it would give a more precise value, since it exactly uses the shape/surface of the area of interest. I understand that for larger projects the difernces between the 2 methods are rather small/ignorable, but are are there thechnical reasons why you would not use it?

  
  

  Thanks a lot for the insights you gave me.

  
  

  Regards,

  Thies
• thies

  May 2021

  Dear Rudolf,

   

  So as I understand correctly, when I use the clause “AREA_IS_idarea”, I kind of use an cookie cutter to determine the surface area of the “area of interest” (AOI). By the use of this clause, I approach the AOI as an polygon. But within Tygron most of the calculations are done using the vectors/rasterization of the AOI, in which all raster cells that are (partly) covered by the AOI are taken into consideration.

  Bothe approaches thus result in a different surface area for the AOI.

  This difference in surface area could lead to differences in the calculation outcomes, as I experienced in the above situation regarding the total amount of rainfall.

  I would like to be able to quantify the difference between the surface area for both approaches. For this I want to know the surface area of my “area of interest”.

   

  I know that I can obtain the surface area of the AOI considered as a polygon by use of the following query:

  SELECT_LANDSIZE_WHERE_AREA_IS_idarea

   

  But how can I obtain the rasterized surface area of the AOI. Is there a query that I can use to obtain this?

   

  I hope you, or someone else on this forum, can help me with this question.

   

  Kind regards,

  Thies
• RudolfNL

  May 2021

  Hey Thies,

  A conventional method for achieving a rasterized view of your arbitrary polygon is to use your polygon in another form of rasterization of which the result are more predictable. Concretely: you can use the Average Overlay for this.

  Ensure your AOI-Area has some recognizable attribute. For example, the attribute AOI with a value of 1.

  Add an Average overlay, and use it's wizard to configure it to only show a certain attribute (rather than smear its average out), and to use the attribute AOI of the Areas data layer.

  You now have a rasterized overlay in which cells where your polygon can be found have some positive value (I believe even exactly matching the AOI attribute's value, i.e. 1), and all other cells have a value of 0. You can thus retrieve the total surface of the rasterized polygon using a GRIDVOLUME query, or otherwise a LANDSIZE query with a MINGRIDVALUE or MAXGRIDVALUE clause.

  
  

  As an aside in regards to an earlier question: the reason the waterbalance does not account for a cookiecutter model is because the waterbalance shows a complete total of the entire project area, not just of any specified area of interest. Applying such a selection would cause the accounting of water (which the water balance is intended to fulfill) to lose or gain water in places where water is initialized or ends up but is cut through by an area of interest. To be able to verify that the computation's results can be accounted for, all water must be included. And because the water exists in a rasterized form, it must be counted in a rasterized form.

  
  

  Kind regards,

  Rudolf
• thies

  May 2021

  Hello @RudolfNL and other forum users,

   

  Thanks a lot for your reaction! Using the average overlay and the grid volume query, I can obtain the “rasterized” surface area of an polygon. I use the following query for this: [SELECT_GRIDVOLUME_WHERE_GRID_IS_id overlay average value].

  With this, I am able to calculate the percentage difference between the rasterized surface area of an polygon and the area calculated by means of the earlier called cooky cutter approach (Query: SELECT_LANDSIZE_WHERE_AREA_IS_idarea).

  So for calculating the surface area of a polygon and the precipitation amount within the polygon, there are 2 approaches; Rasterized and cookie cutter/vecor.

  If I understand it correctly, you suggest to use the raster approach since the precipitation is calculated per cell. When using the cooky cutter, parts of a cell, and thus parts of the precipitation amount, is cut off.

  I then would expect that the percentage difference in area is equal to the percentage difference in precipitation amount. This because the difference in precipitation amount is caused by cutting off parts of the cells by the vector/cookie cutter approach.

  However, if I look into this, I observed that the percentage defence in precipitation amount is exactly 2times as high as the difference in surface area. In the table below, I show the four situations to which I looked. I know that the differences are rather small, but I am really interested in the process/method that is behind the rasterization and the impact on calculations.

  
  

  So my question is, why are the differences in precipitation amount exactly 2 times as high as the difference in surface area. am I taking a certain value double into account? 

  
  

  

  
  

  

  
  

  I hope you or someone else can help me out with this.

  
  

  Kind regards,

  Thies
• Hansje

  July 2021

  I would like to share this video with all of you.

  In this video Maxim Knepflé explains how the Tygron Platform handles edge effects of water level areas.

  

  
  

  Kind regards,
  Hansje
  Tygron support team