Python API vs Python based GP Tools for Analysis?

[ZacharyHart]

Many of the solutions we have created for our organization have been released as Python based Geoprocessing Tools (sometimes rolled-up into widgets, other times simply a GP Service).

Since we've implemented a (federated) Enterprise system, we've been exploring leveraging the Python API much more.

As I see it, the primary difference here is that the GP services can access the underlying geodatabase infrastructure directly. Conversely, the Python API is designed to be web-based and would therefore access the data via feature services.

I realize this is the Python API forum/group so this may need to be posted elsewhere to get a good discussion going.

That said, what do you see as the advantages to using the Python API vs 'conventional' geoprocessing tools? Are there performance considerations? Ease of deployment?

[Arne_Gelfert]

Zachary,

as usual, I've struggled a bit with digesting the ESRI jargon. I believe the Python API is really a label for the arcgis module, right? That's a powerful toolkit for web GIS stuff, even creating little interactive maps inside Jupyter notebook, etc. But as far as geoprocessing is concerned, it's still largely arcpy, installed alongside arcgis. Granted, one will still land in the Pleistocene world of Python 2.7 by default. But you can install arcpy in 3.6 with conda.

Long story short, I still use both and will continue to do so. They're different animals that complement each other. Just be mindful of slight some differences in the way arcpy is structured in 10.x and for Pro.

Cheers

[ZacharyHart]

Thanks for replying...this is the kind of discussion I was hoping people would have!

I believe the Python API is really a label for the arcgis module, right?

That's more or less how I see it too.

 Granted, one will still land in the Pleistocene world of Python 2.7 by default. But you can install arcpy in 3.6 with conda.

That's a really great point since in terms of server-side processing all of Enterprise/Server still leverages python 2.7

I mean, in large part i'm using 3.x for any of the heavy-lifting type analysis I need to do to churn out things. But in terms of extending pre-canned tools to non-GIS users, I'm still sorta struggling to understand how the Python API fits in. Unless I stand up a Notebook server, I'll be more or less rolling up python scripts into GP Tools/services and Widgets. Within those, I would have the choice to use the API to have the analysis run on web services, but why bother when arcpy can access the enterprise GDB directly? Are there performance advantages to running analysis against map & feature services vs directly against the feature classes they represent?

For now, it seems to me that i'll be using the python API to help manage our Enterprise site.

Anyone else have thoughts to share?

[KimOllivier]

I have a lot of Python workflows in 'legacy 2.7' that will have to move to 3.6 and ArcGISPro or Server. My solution so far is to simply upgrade each 2.7 script to be cross compatible to 2/3 so it does not matter which interpreter is being used.

There are only a few trivial syntax changes and a few other changes that can be handled with a test for the python version. I have not found any benefit to moving to 64 bit for the vector and database work that I do. Maybe for raster processing where more is done in memory, but even then, do some partitioning to reduce the requirement.

[Luke_Pinner]

Zachary Hart wrote:

...

That's a really great point since in terms of server-side processing all of Enterprise/Server still leverages python 2.7

Not quite. From the Help:

ArcGIS Server includes Python 2.7 for Windows 64 bit.  At ArcGIS Enterprise 10.5 and later, the conda environment is included with ArcGIS Server. The conda environment is based on Python 3.

...
Similar to ArcGIS Pro, ArcGIS Server uses conda to manage Python environments.

[ZacharyHart]

Thanks for the clarification and that makes sense given that you can publish a script tool created in Pro so there would have to be 3.x compatibility.

What do you see as the advantages to using the Python API vs 'conventional' geoprocessing tools? Are there performance considerations? Ease of deployment?

[KimOllivier]

But the Anaconda version of Python is slightly different for some libraries. The sqlite3 implementation has been compiled to disallow extensions and has not included Rtrees, This makes it impossible to use sqlite3 for geometry tables. Great. Now I have to hack the installation to replace the sqlite3.dll with the standard build and the mod_spatialite extension. Note that the geopackage is only designed for data exchange, not faster efficient geoprocessing...