I have a puzzling problem using GeoTiff rasters which have been generated using Python + GDAL functions. When these grids are "Sampled" (ArcMap 10.4.1 Spatial Analyst Sample command), some rows of data contain either Nodata values, or in some cases very small or large negative values where there should be valid data values.

This occurs when sampling a grid, using the grid itself as the location of points to be sampled. There are no errors or warnings reported by Sample.

This image shows the X, Y values output for a grid (using Sample tool) which has been loaded into ArcMap with the values symbolised to show NoData (-9999) values in red. The output points all have the correct coordinates, and there are not gaps apparent. However, when symbolised to the value of the underlying raster, you can see the values in two lines across the grid either appear with NoData values, or in the case of the lower line, contain values which are not the same as the surrounding grid values that would be expected. Inspecting the individual values in those rows, none of the extracted values correspond to any of the grids being sampled at that point. The lines are 140 m apart (70 rows of 2m grid)

Screen shot showing lines of NoData values in sampled grid points

Initially I was sampling several grids at the same time, but I found that I could reproduce the problem using only one of those grids at a time. I have tried many things to find a cause/solution this including:

  • defining the projection (the same as the grid already has defined),
  • sample using a similar grid created in ArcMap with same grid size,
  • exporting a world file for the Geotiff.

but these do not work.

Two things that DO have an effect are

  • converting the grid to a point Shapefile, and using the point Shapefile to sample with, instead of the raster.
  • I also found that projecting the raster (from GDA_1994_MGA_Zone_55 to GDA_1994_MGA_Zone_55) changes the spacing of the invalid rows. In the case of the grid shown, the rows disappear, but with a larger grid, the spacing of invalid rows simply increased

This suggests there is something going on in ArcMap's interpretation of the grid projection, which was based on EPSG in the GDAL functions. I am wondering if anyone has seen this issue with ArcGIS 10.x, and would like to know if there is a way I can resolve this in the Python GDAL functions used to generate the grid (or perhaps is this an ArcMap bug?).


There is a documented bug corresponding to your issue:

Bug BUG-000093811 - The Sample tool produces an erroneous output when a raster is used for the sample locations and the processing extent is set to the display extent.

So try modifying the processing extent, and if it doesn't work then converting the raster to points as you've done is probably the only solution...

  • Thanks for your suggestion GISGe. This bug appears to relate specifically to setting the processing extent to the display extent, which is not something I commonly do. In my testing I tried changing a number of Environment settings (coordinate system, processing extent, raster cell size and mask) but these did not to resolve the problem. I have now performed additional tests with the processing extent with no success. – David Dec 1 '16 at 23:05
  • Might only apply 50% to you then (raster used for sample locations). I've seen a similar question with another raster processing tool but I can't find it back. There was a memory leak issue. But your raster doesn't seem to be that large, so I'm not sure it would apply here neither. – GISGe Dec 2 '16 at 10:50
  • This is an ANCIENT bug and it is shocking that ESRI haven't fixed it. These line-artefacts have been popping up in raster calculations for as long as I have used Arc (since ArcInfo 7.x back in the '90s). – MappaGnosis Dec 2 '16 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.