Split Raster function produces partial or no output

[JohnGaiot]

The behaviour of the Split Raster function is rather unpredictable and produces partial or no output depending on the output raster data format chosen. Some tiles would complete successfully while others tiles would either contain NODATA or be skipped altogether. This would happen when producing stand-alone GRID's, rasters within file geodatabases, and also TIFF's (curiously, the pattern of which tiles were successful and which weren't was not consistent between formats). The only format that was successful in my trials was IMAGINE IMAGE (.IMG) which produced data for all the tiles successfully. Further testing would be required to determine if this is always the case.

I searched all the forums and found one entry by a user experiencing similar problems, but the solution to the issue was never pursued as the user found a manual 'work around' which doesn't work for me as I have to do this repeatedly for large areas in Ontario. Forum reference: http://gis.stackexchange.com/questions/211630/missing-output-from-arcgis-split-raster-tool

Illustration below was the result using the stand-alone GRID format but there were also instances where no tiles were created at all in other tests.

The following are the DEM characteristics and the splitting criteria I used:

DEM Projection: NAD_1983_CSRS_UTM_Zone_17N

Data Type: Float 32-Bit

Unsplit DEM Width Size (columns) = 11163
Unsplit DEM Height Size (rows) = 11519
Cell Width Size ( x ) = 2
Cell Height Size ( y ) = 2
Linear Unit Name = Meter
Split DEM Width Size (columns) = 4000
Split DEM Height Size (rows) = 4000

1 PIXEL overlap between tiles.

NEAREST resampling option

SIZE_OF_TILE option

I also encountered this problem using a DEM with a 30m cell size, NAD_1983_Ontario_MNR_Lambert projection, and on the following platforms.

arcgis-10-3‌ and arcgis-10-1‌

I am wondering whether later versions of ArcGIS have fixed this problem?

Thanks in advance.

John

[JohnGaiot]

Hi Dan,

I managed to get back to this age old issue of Split Raster for another project. This time taking up your suggestion to test in Pro (2.6.1) and my old installation of Desktop (10.3.1 - will be going to a later version soon! Promise!) and came up with some new findings. Right now, I am aiming to create a contour layer for Ontario using Ontario's Provincial Digital Elevation Model (PDEM Source). This product is available as a seamless 30m raster (almost - it is split into a North and South portion - so 2 tiles for the entire province). I plan on performing the contour processing on a tiled version of the PDEM created from the Split Raster function using the default width / height of 2048 pixels for each tile with a 1 cell overlap between tiles. This would create a total of 410 tiles for the province if the process is completed properly.

I ran this in 3 scenarios:

1. In ArcGIS Desktop ArcMap

2. In ArcGIS Pro

3. In ArcGIS Desktop ArcCatalog

The results:

In ArcMap, it ran with no error but generate only 8 tiles using the TIFF option.

In ArcGIS Pro, it ran but generated only 2 tiles using the TIFF option.

In Catalog, using the IMG option, it completely generated all 410 tiles with no issue.

Pro, as we all know, is a memory hog and consumes A LOT of resources. So does ArcMap but not nearly as much as Pro. Catalog allows you to interactively run all toolbox commands without the GUI overhead and this is probably the reason why it ran fine. I jumped to the IMG option for Catalog based on my earlier stated findings that this seemed to be a more effective image format than TIFF. I could run further tests in the GUI's using IMG format if you want me to, but I doubt I will get better results because of the memory overhead.

So my question is..

Is there something similar in Pro which allows you to interactively run all commands without having to run the GUI interface and without having to code in Python? Something like a bare-bones Catalog for comparison?

This might alleviate A LOT of problems with our larger datasets in Ontario without having to beef up our RAM or graphics requirements in the short term.

Cheers,

John