I am working on creating a python toolbox that uses a combine and then uses the combine VAT to join fields from other grid data. The scripting was built upon a previously existing tool that used the legacy coding for combine, arcpy.gp.Combine_sa.
If using the legacy coding, the tool operates correctly, the combine is performed, and then several join fields are run, the joined raster is saved, and then new fields are added and calculated based on the join fields.
However, if I replace the legacy combine coding with the current combine code and then save with combine.save(save_location) like this:
I get the vexing error that the VAT_combine is not available. If I then build the attribute table, the combine field is there but the original value fields are not there (those fields are needed for the join field operation)
The python toolbox is attached. The Combine coding begins at line 318. Thank you in advance for any suggestions or comments.
Solved! Go to Solution.
Do you have a reason not to do it the "old way", directly writing to Esri grid format? From 10.5 and later, python map algebra expressions may write intermediate output to .tif format, copying the data out to a new raster with the .save() operation. (See: https://community.esri.com/people/curtvprice/blog/2017/03/03/temporary-rasters-in-arcpy?sr=search&se....) Calling raster tools directly with arcpy.gp avoids any temporary rasters to be written to disk, which is sometimes desirable for performance reasons, or in your case where the intermediate raster implementation is breaking your workflow!
I recommend submitting this to Esri support so they can investigate this issue. I suspect there may be an issue with the path names of the input rasters that is resolved by avoiding the intermediate raster by using arcpy.gp.
For now seems like the best approach is to keep doing it "the old way." Which is really just an alternate method of calling the Combine tool, not deprecated. All the raster tools (including ones usually accessed with math operators like + for Plus, or within a complex map algebra expression with tools like Int) may be called using this alternate implementation with the code pattern arcpy.gp.Rastertool_sa().
Hope this helps!
Do you have a reason not to do it the "old way", directly writing to Esri grid format? From 10.5 and later, python map algebra expressions may write intermediate output to .tif format, copying the data out to a new raster with the .save() operation. (See: https://community.esri.com/people/curtvprice/blog/2017/03/03/temporary-rasters-in-arcpy?sr=search&se....) Calling raster tools directly with arcpy.gp avoids any temporary rasters to be written to disk, which is sometimes desirable for performance reasons, or in your case where the intermediate raster implementation is breaking your workflow!
I recommend submitting this to Esri support so they can investigate this issue. I suspect there may be an issue with the path names of the input rasters that is resolved by avoiding the intermediate raster by using arcpy.gp.
For now seems like the best approach is to keep doing it "the old way." Which is really just an alternate method of calling the Combine tool, not deprecated. All the raster tools (including ones usually accessed with math operators like + for Plus, or within a complex map algebra expression with tools like Int) may be called using this alternate implementation with the code pattern arcpy.gp.Rastertool_sa().
Hope this helps!