Flow Direction and Flow Accumulation seem erroneous.

920
9
08-17-2021 12:00 PM
MarkBoucher
Regular Contributor II

Arc Hydro v10.8.0.34, ArcGIS Desktop v10.8.1 (both 32 bit)

My flow accumulation grid (fac) is not being created correctly. For some reason, the flow direction grid (fdr) has the north east direction as -128 instead of +128 as I assume it should be.

The first image shows the fdr grid and some flow path tracing lines. These are correct event thought the value of the fdr grid is -128. This may not be an issue, but all the examples have 128 instead of -128. I have deleted and repeated the creation of the fdr grid using SA and Arc Hydro tools.

In the second image, I show the fdr with the 128 valued cells in yellow to highlight them. They are 128 in the table of contents, but using the i tool they show as -128.

In the third image, I show the flow accumulation grid (fac) turned on over the fdr grid. You see the yellow cells “showing through” b/c the fac grid shows NoData. When this happens the flow accumulation starts over. It should continue and the cells should get darker along the flow direction (having higher and higher accumulation).

The forth image is a portion of the third image  showing the identify tool results on the right and the yellow cell that was selected circled with a blue line as well as the results circled on the right.

My expectation was that the fdr value would be a positive 128, and the fac would be ever increasing. 

The resulting fdr grid is a "signed integer" which means it can have +/- values. A search confirms that in an 8 bit system 8-BIT UNSIGNED: 0 to 256  8-BIT SIGNED: -128 to 127. So, in an 8 bit signed integer raster, there can be no +128 which would make the "D8" flow direction type, it would make sense to use -128 for a signed integer grid (and the flow path tracing tool works with it). In an older "successful" hydrology effort the fdr grid was an unsigned grid. It is not being created as a signed grid.

Can anyone shed light on why this is happening?

Thanks,

Mark

 

First Image - fdr grid and some flow path tracing lines.

fdr1.jpg

Second Image - fdr with the 128 valued cells in yellow to highlight them.

fdr2.jpg

Third Image - fac turned on over the fdr grid. Yellow 128 direction grids from fdr show through where fac is NoData.

fdr3.jpg

Fourth Image - portion of third image showing results of the identify tool click on circled grid cell.

fdr4.jpg

9 Replies
MarkBoucher
Regular Contributor II

In a "last ditch" effort, I renamed my folder by adding "error" and started over. I moved any project based tool boxes to a new folder and started over. The process ran much faster and I didn't have the "errors" I was having in the post above. If the errors come back I'll reply again. May be a little premature, but for some mysterious reason starting from scratch fixed the issue.

curtvprice
MVP Esteemed Contributor

When things get this weird, often a restart of the software, or starting the process from scratch can fix the issue. It looks like some of your data (or the many xml pieces of ArcHydro that keep track of things) got corrupted along the way and starting from scratch "cleaned out" the issue.

tlopezcantu
Esri Contributor

Hi Mark,

Thank you for reaching out, and I will be happy to help in case the errors come back. 

When you renamed your folder, did you check the pixel type in your new flow direction raster? Was it  "unsigned integer" type (as it should)? In case the errors happen again, I will reach out to you so that I can test with your use case if possible.

Thank you,

Tania Lopez-Cantu
MarkBoucher
Regular Contributor II

Thanks for the response @curtvprice and @tlopezcantu.  Things seem to be working except that ArcMap crashes often while doing the geoprocessing. Seems random and is frustrating. It is hard to comprehend why the raster type would change simply due to changing a file name. One thing I have not tried is to delete the tables under the .gdb named after the .mxd (I name mine ArcHydro.mxd since I'm trying to create a process that I'll use in many watersheds in my county). 

MarkBoucher_0-1629298310333.png

I've always thought of these a "counters" that keep track of the hydroID and the drainID type of numbers. Does it help to delete this .gdb if "starting over"?

 

0 Kudos
curtvprice
MVP Esteemed Contributor
Since you are using ArcMap, I highly recommend disabling background processing if you have it on. Passing layers from ArcMap to the background geoprocessor can sometimes be not as robust.
0 Kudos
MarkBoucher
Regular Contributor II

Thanks for the reminder. I always recommend that too being the starter of the ArcHydro Problem Solvers thread. I have disabled it in the past, but for some reason it was enabled. So many buttons and options. Wouldn't it be nice to be able to make "profiles" where one could change settings all at once for different project circumstances.

MarkBoucher
Regular Contributor II

I ran into the same problem again. The process is iterative for me, so I go back and restart. This time I deleted the data in the project .gdb  (see below) and the problem went away. 

MarkBoucher_0-1629309239679.png

 For some reason the fdr grid is recreated as a signed integer grid even if I delete it and other previous grid (fil) and recreate it. The 128 direction shows as -128 in the fdr.  This time the fac grid was fine, but when I went to delineate subwatersheds, they results were a few patches localized to the batch point and did not go upstream very far.

 

0 Kudos
tlopezcantu
Esri Contributor

Hi Mark,

It surely is strange that changing the output folder makes the output raster pixel type change and that now the error is back. I was wondering if we could force the -128 cells to their correct 128 value using Con tool, and use this as a temporary solution while I investigate this issue. For this purpose, could you please let us know the steps in your analysis? I would like to reproduce this issue so that I can investigate the best solution for you. I will reach out shortly for more details.

Thank you,

Tania Lopez-Cantu
0 Kudos
MarkBoucher
Regular Contributor II

Tania,

I tried that, but the Con function wouldn't create an unsigned 8-bit integer raster. The signed 8-bit raster can't have 128 and so it for some reason defaults to -128.

When I started over this second time I didn't change the folder, I simply deleted the fil and fdr rasters as well as the project's .gdb. This seemed to fix the fdr issue without having to "really" start over.

Thanks,

Mark

0 Kudos