This week, I needed to convert a number of polygon feature classes to raster. Some of these feature classes included large numbers of features that were small relative to the cell size of the raster. Because of this, they wouldn’t get captured at all in the conversion to raster using ArcGIS’ Polygon to Raster tool, with any of the settings for conversion (CELL_CENTER, MAXIMUM_AREA, or MAXIMUM_COMBINED AREA).

So we went looking for alternatives. A coworker pointed me to GDAL’s “All Touching” flag when converting to raster, which does what it says – it returns all cells that a polygon touches. After some finagling, I incorporated this GDAL call into an otherwise ArcGIS oriented workflow, and we started testing performance of it with our Polygons relative to the Polygon to Raster in ArcGIS. It overpredicted area, as expected, but we didn’t get any null values. All polygons had a corresponding raster area.

But what if we wanted to keep this whole thing in ArcGIS? We accidentally discovered the solution while comparing the areas of our results. By default, if you use something like MAXIMUM_AREA, ArcGIS gives you a surprisingly good result area-wise, so long as your features are larger than half the cell size squared. But for the smaller ones, it appears that NULL values get a say in MAXIMUM_AREA calculations, and if they dominate a cell during conversion, it returns NULL. However, using the optional Priority field in the tool, you can force the NULL values to be excluded and just give your features priority – the equivalent of GDAL’s “All Touched” option. Set the priority field to a numerical value in your dataset (even the OBJECTID should do), and ArcGIS will use those as weights. Compared to the zero weight of NULL values, the polygons will always win out and return all cells they touch.

Snap Raster not snapping!

I had a separate issue that I still haven’t solved, but I have a theory about. When I created a ModelBuilder model (in ArcGIS 10.3), I was finding that results from tools with the Snap Raster environment set weren’t being correctly snapped to the Snap Raster. After playing with it for a while, I have a theory that when you also have an Extent environment set, it may ignore the snap raster in favor of keeping the extent.

The tricky thing here is that this is the opposite of what the documentation says should occur. In the documentation, the extent is kept for the lower lefthand corner, where it’s snapped to the raster, and the top right corner of the extent is expanded as needed to account for cell size and snapping.

So, either I found a bug, or I’m still not understanding this correctly – likely the latter – but I do know that while correctly setting the snap raster environment setting, I was repeatedly not getting snapped results.

If anyone else has had similar experiences, I’d love to hear your thoughts