Unit fix

[philipbaileynar]

Matt, please review this change. I will do the UI testing myself

[philipbaileynar]

do the fix

[philipbaileynar]

I just performed the following tests to prove that the fix has no effect on metric projects:

Test Metric 1

1. Reset the code to version 7.0.14 (dc77d3) and built in release build
2. Used GCD Standalone to create a new Sulphur Creek.
3. Added 2005 and 2006 DEMs and performed a DoD with MinLoD 0.2m.
4. View the DoD results.
5. Closed the DoD results.
6. Opened the DoD results, edit the name and then closed the DoD results.
7. Viewed the DoD results.

Test Metric 2

1. Checked out the head of getvolume branch (7fe491ae) and re-built in release build.
2. Open the existing Sulphur Creek project.
3. Viewed the DoD results.
4. Closed the DoD results.
5. Opened the DoD results, edit the name and then closed the DoD results.
6. Viewed the DoD results.

Test Metric 3

1. Created a second, new Sulphur Creek project and repeated test 1 on this new project.

Rationale

I wanted to execute all three of the following methods under both the old and the new code:

• GetVolume
• SetVolume
• AddToSumAndIncrementCounter

Findings

I got the same areal and volumetric results under every scenario.

Conclusions

1. Both the old and new code work on metric projects.
2. The new code has no negative effect on metric projects.

[philipbaileynar]

The following tests are a follow-on from my previous metric tests but instead use imperial units.

I took the original 2005 and 2006 Sulphur Creek rasters and ran them both through two GIS operations to convert them into imperial units:

1. Re-projected the rasters into NAD_1983_2011_StatePlane_California_VI_FIPS_0406_Ft_US
2. Used raster calculator to multiply the raster values by 3.28084 to convert the elevations into feet. (Technically these are international feet while the projection is US survey feet, but the differences should be negligible).

I then basically re-ran all the metric tests from my previous comment but this time using the imperial rasters. I was careful to use a MinLoD of 0.66ft which is equivalent to 0.2m used in the original tests.

Findings

1. I was able to reproduce the unit conversion problem with the old code (dc77d3e5811296568980b51e2bded35fc9cd5227).
2. The problem then did not occur with the fixed code (7fe491ae4b2f8268d7bc7e2b8724626019b2bf25).

Conclusions

The code fix has the desired affect when projects are in imperial units.

Other Comments

• Comparing the metric to imperial results was interesting. When I took the DoD results that were calculated in imperial units and viewed them in metric, then compared them to the results that were calculated in metric, there are substantial differences. These are attribubable to the nearest neighbour resampling associated with the re-projection and then the bilinear resampling during GCD import. It shows the importance of users creating rasters from point clouds correctly and avoiding resampling.
• I think I witnessed that the unit problem manifests itself earlier than we originally thought. Because of the differences of the IncrementSum method and GetVolume the very first time users get to view the DoD results they are already seeing erroneous values.