1

I frequently generate contours from lidar-derived elevation image tiles.
My workflow is:

  • Load the elevation image tiles into a mosaic dataset in a GDB
  • Run focal statistics on on the mosaic dataset
  • Contour the resulting focal stats raster so as to yield smoother contour lines rather than stairstep ones.

As a result, we have the elevation imagery twice and it takes extra steps.

Can we do Focal statistics on the mosaics dataset directly without generating a new intermediate image output?

  • I think so, the contour sa tool takes a raster which can be any raster, but you will need to use the python window as modelbuilder and the toolbox wont let you. You could try arcpy.sa.Contour(arcpy.sa.FocalStatistics(arcpy.Raster(r'c:\your\path\to\raster')... the temporary rasters will be generated in your arcpy.env.scratchWorkspace and removed on completion. Note this will not make the process any faster but will reduce the permanent space used by this process. – Michael Stimson Nov 29 '17 at 21:32
  • As per the Tour there should be only one question asked per question. – PolyGeo Nov 29 '17 at 22:10
2

As it turns out you can create a contour of a focal statistic without persisting to disc, consider this example:

arcpy.sa.Contour(arcpy.sa.FocalStatistics(arcpy.Raster(r'E:\path\to\Raster.img'),
                                                                                    arcpy.sa.NbrRectangle(3,3,"CELL"),"MEAN"),
                                                                                    r'E:\output\path\contours.shp',0.5)

This creates a Focal Mean of a 3 x 3 cell neighborhood on the fly and contours that to a 50cm interval.

You must do this in a script or in the python window of ArcCatalog/ArcMap, the objects don't exist in modelbuilder or the toolbox unless they're persisted (written permanently) to disc.

As I said in my comment, this will (may) not speed up the process but will reduce the disc footprint of the unwanted focal statistic rasters. The temporary rasters are stored in your arcpy.env.scratchWorkspace in GRID format, which may be quicker than compressed file GDB raster at processing but because the raster is removed as soon as the process completes you could set the scratch workspace to a local, small, fast drive like a RAM Drive if your rasters/tiles are generally small enough to fit into memory; in some cases the data drives of workstations are RAIDed and might be faster (and larger) than C:\users\your_name\AppData\Local\Temp which is the default Windows %Temp% drive setting your scratch workspace to a folder on the array will (could) result in a performance increase.

  • Excelent. I will try working this method into a script tool. Not sure why it never occurred to me to make it in memory! – Zipper1365 Nov 30 '17 at 0:37

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.