What is the difference between arcpy.gp.Visibility_sa and arcpy.sa.Visibility

[PeterLen]

Hello - We are using ArcGIS v10.2.  I have been playing with the spatial analyst Visibility tool.  I am writing my own Python script tool and so wanted to see how ArcGIS would list the Visibility tool call so I built a model where I dragged the Visibility (spatial analysis) tool to my model and then added all of the tool's parameters.  It all ran fine and si I exported it to a Python file.  The python file listed the tool as:

arcpy.gp.Visibility_sa()  which took 18 arguments.

When I looked at the help file for this tool, the python code example looked like:

ret = arcpy.sa.Visbility() which took 17 arguments.  The definition above included an output raster as the 3rd argument and is why it took 1 more argument than this version.  This version, does not take a raster output option, but instead returns a raster type.

Both seem to create the same output but I am confused as to why there are two different versions.  I could not find anything on an arcpy.gp module so am unsure of where the arcpy.gp is being read from.

The odd thing is that in my ArcMap's Search window, when I find my Visibility (spatial analysis) entry, the help link shows an example of the second type (arcpy.sa.Visibility) but the link that points me to the tool int he toolbox, which I dragged to my model, and which I exported as a Python script, lists the first type (arcpy.gp.Visibility_sa).

Any thoughts?

Thanks - Peter

[GabrielUpchurch1 · Accepted solution]

Hi Peter,

When running a geoprocessing tool directly, you save the output to disk, hence the additional parameter with the arcpy.gp syntax.  On the other hand, arcpy.sa is optimized for scripting since it allows you to create a temporary raster file that does not have to be written to disk after the specific process is run, yet you can still use it in its temporary form for future steps in the script.  This speed things up when your script is producing intermediate datasets that you don't need to keep and also helps with the management of intermediate data.

[PeterLen]

Gabriel - Thanks for the update.  You seem to be everywhere   So based on your response it sounds like the arcpy.gp syntax is needed for tools running in a Model because it requires the location for the output.  Otherwise, the end result of the Model would be nothing since it wasn't saved.  The arcpy.sa syntax, on the otherhand, is mroe flexible and allows you to work with the result without having to find a permanent home for it until you need to have a home.  Since it is optimized, that would be the one to use even though both versions appear to run just fine in my Python script.  I hope my description is a fair assessment of your reply.  Thanks again - Peter

[GabrielUpchurch1]

Yup, your assessment sounds fair to me.  I have encountered one scenario where the arcpy.sa syntax was failing for a specific tool but the arcpy.gp syntax was successful.  In that case, we used arcpy.gp in place of arcpy.sa in the script to work around the issue.  Another way to think about it is that arcpy.gp is the older approach upon which the ArcToolbox tools were built and arcpy.sa is the newer python focused approach that much of Desktop seems to be trending towards due to everyone's love of automation.

My leadership recently introduced the option to contribute on GeoNet as part of my job responsibilities so I thought I would give it a shot.  The knowledge I have obtained from my current position lends itself very nicely to working the Discussions and lending assistance where I can.  In that regard, if you find any of the info I provide useful, then I would encourage you to mark it as helpful or the correct answer.  That way I can provide evidence that unleashing us on GeoNet is beneficial to ArcGIS users

[DanPatterson_Retired]

some insight

>>> arcpy.gp.Visibility_sa.func_name
'<lambda>'
>>> arcpy.sa.Visibility.func_name
'Visibility'
>>>

and

>>> arcpy.sa.Visibility.__esri_toolname__
'Visibility_sa'
>>> arcpy.gp.Visibility_sa.__doc__
.....
.....

Try the following in your Python IDE...I have left out the outputs so you can examine on your own

>>> help(arcpy.gp.Visibility_sa)
...
...
>>> help(arcpy.sa.Visibility)
...
...

which just goes to show you that once you import arcpy you can explore all the elements contained therein...or at least what Esri want you to see about what is contained there

And I forgot to add..

>>> arcpy.gp.Visibility_sa.func_dict
{}
>>> arcpy.sa.Visibility.func_dict
{'__esri_toolinfo__': ['::::1', '::::2', '::::4', '::::5', '::::6', '::::7', '::::8', '::::9', '::::10', '::::11', '::::12', '::::13', '::::14', '::::15', '::::16', '::::17', '::::18'], '__esri_toolname__': 'Visibility_sa'}
>>> arcpy.gp.Visibility_sa.func_code
<code object <lambda> at 024A6380, file "C:\Program Files (x86)\ArcGIS\Desktop10.2\arcpy\arcpy\geoprocessing\_base.py", line 498>
>>> arcpy.sa.Visibility.func_code
<code object Visibility at 0D05B650, file "C:\Program Files (x86)\ArcGIS\Desktop10.2\arcpy\arcpy\sa\Functions.py", line 7170>
>>>

[lukekaim]

Hi Gabriel Upchurch,

But when Esri says they store the information in a temporary file it is still written to disk. If you use save, then it is written to disk twice which is slower then the arcpy.gp function. From testing arcpy.gp.EucDistance_sa is faster then running the tool and then save. So why would one ever use save instead of the arcpy.gp function?

My code is below:

You will have to select a workspace and an input raster.

import arcpy
import os
import time
arcpy.env.workspace = r"......."
arcpy.env.overwriteOutput = True
arcpy.CheckOutExtension("Spatial")


raster = "...."
starttime = time.time()
euc = arcpy.sa.EucDistance(raster, "#", 30)
euc.save("temp2")
endtime = "save", time.time() - starttime


start2 = time.time()
arcpy.gp.EucDistance_sa(raster, "temp3", "#", 30, "#")
end2 =  time.time() - start2


print endtime
print end2
print "the end"

I would like a technical answer to this question.

[curtvprice]

The intermediate result is not necessarily written to disk when using the arcpy Spatial Analyst module arcpy.sa. Local (cell by cell) operators can be stacked up for deferred execution so nothing is executed until it is needed, and writing intermediate rasters is avoided when possible.

For example, this set of commands will only run at the end when saved, with no intermediate datasets saved to disk:

raster1 = Con(IsNull(mask+raster), 2)
raster2 = raster1 * 5
raster3 = raster2 / 2.0
raster3.save() # nested operation runs now

Note some local tools (notably, and unfortunately, Lookup) and all zonal and global tools always have to write a dataset to disk, to the current scratch folder. But even then, the arcpy.sa syntax allows you to succinctly do complex things with map algebra (in python, or using the raster calculator).  In the following example, the SetNull and GreaterThan (>) local tools are run deferred, then a temp raster is written by EucDistance, then Pow and Divide will be run after that, without an intermediate raster needed (in theory of course):

raster1 = 1.0 / Pow(EucDistance(SetNull(landraster > 0, 1), 2)

(Note the clever way the Esri's Spatial Analyst team has figured out how make Python smart enough to realize that "/" means run the Divide tool  if one or both operands are of type arcpy.Raster. Very cool.)

One trick you can use to speed things up is to set the current workspace and scratch workspace to the same folder (not gdb). Then a .save() operation only has to rename. This can make a difference with large raster datasets.

Another huge advantage (that Gabriel mentioned) is that temporary rasters are automatically deleted for you, making handling of temp rasters much easier in your code. Read up on the docs for the Raster object for more details on that.

Working with Raster objects—ArcGIS Help | ArcGIS for Desktop