aread8 nodata value in version 5.3.8

[theobarnhart-USGS]

First of all, this is really useful software.

We've been using this for many parameter accumulations following the flow direction grid. Recently, we've had some odd behavior with version 5.3.8. Regions of the weighting grid with values of -1 are returned in the output accumulated grid as areas of nodata. I think this is because -1 is hard coded into aread8 as the nodata value. I'll paste some screen shots and descriptions below. Perhaps this is related to #203 or has been fixed in v5.3.9? I've only had success getting v5.3.8 to compile on linux/HPC.

Accumulated parameter grid with -1 areas shown as nodata:

When I convert -1 to float, -0.01, the issue goes away.

Here is a snippet of what may be the offending code. I don't know c++ so I may be way off here.

It would be great to have the output nodata value not be hard-coded and instead have that value be the same as the nodata value be set as the nodata value of the input weighting grid (if properly defined).

Again, this is really great software and has saved us a ton of time.

Thanks,

Theo

[dtarb]

This is a relic of not anticipating contributing area results being negative when originally coded, so I thought -1 would be a convenient no data value.

It should be possible to change to another value, and a good value may be MISSINGFLOAT defined at line 80 of https://github.com/dtarb/TauDEM/blob/Develop/src/commonLib.h.

Then in aread8 https://github.com/dtarb/TauDEM/blob/Develop/src/aread8.cpp it looks like lines 152 would need changing to
aread8 = CreateNewPartition(FLOAT_TYPE, totalX, totalY, dxA, dyA, MISSINGFLOAT);
and in the snippet you found line 269 change to
float aNodata = MISSINGFLOAT;

I find myself a bit unsure whether the constant MISSINGFLOAT will pass correctly into CreateNewPartition so you might need a code construct similar to that around line 269 where a variable is declared and passed in.

If you are able to make these changes and recompile/try it out, it may solve your problem.

It would also be good to scrutinize the code to see if there are any places it relies on the -1 assumption and address these.

This could be changed/fixed in a future release, but I do not have time for this right now.

[theobarnhart-USGS]

Thank you, I'll fork the repo and give this a try. Do you think forking from v5.3.8 or master would be best?

[dtarb]

I suggest forking from the most recent develop. This will catch more recent fixes and refinements (and I do not think any are breaking or incomplete)

[theobarnhart-USGS]

Will do, thanks!