Latest Contributions by ShaunWalbridge

This area is for the Python API rather than ArcPy, but will try to address your question. I would start by adding some debugging information to your script, and checking what `m.listLayers()` shows when running in standalone Python. It is possible that the aprx hasn't been saved at the point in execution?  If the aprx exposes the right information, it may be that the GDB model is different in this case, but that seems less likely.  Cheers, Shaun ... View more

Glad you got something working. It looks like its a specific design choice of the gssapi package to not include Linux wheels: https://github.com/pythongssapi/python-gssapi/issues/200 I've created an internal issue for the Python API team to track this as a design issue with the addition of GSS as a dependency. ... View more

The model of automation employed by our desktop applications provides a number of avenues for automation. Some of the methods we provide:   A collection of tools can be visually diagrammed into a ModelBuilder model, which can in turn be exported to a Python script Any Geoprocessing tool, once executed, can be exported as a Python script or command from the Geoprocessing history. Geoprocessing tools authored in the default ATBX format will generate code representations of themselves automatically, and can be managed in source control like any other source code. Both the ATBX format and Python toolboxes provide a mechanism to create custom Python code from existing tools. ArcGIS Pro supports Python Notebooks as a top-level content type, they can be included in projects and authored alongside any other project components and shared directly with the project or as standalone artifacts. Tasks can be used to automate multi-step processes which require guided input along with the task.   We continue to add to Geoprocessing and Python to further enhance the experience of automating the application and both sharing and reproducing your work. Not all aspects of all workflows are possible to automate through these means, but they do serve the vast majority of use cases. Depending on your background, the Python API and the Pro .NET SDK can further extend the ability to automate. Thank you for your input to the Esri ideas site, we appreciate your time and input. Cheers, Shaun ... View more

Can you provide details about the exact libraries that you'd like to work with? There is, unfortunately, currently a broad set of Python APIs for accessing a variety of cloud services which makes their inclusion less simple. We do provide `azure-core` and `azure-storage-blob`, and if there are specific demands for others, can assess their inclusion. Thanks! Shaun ... View more

The header of the Python file only affects the encoding of the text within the script, so probably is unrelated. Opening the input with 'utf-8' looks correct, I would check that the database is correctly storing the information as UTF-8 (e.g. it wasn't reencoded into something else during storage), and you can stop your script at the point of execution to check what Python thinks its seeing. If you add `breakpoint()` to your code, you'll get the PDB debugger which will allow you to inspect the state. ... View more

Given where ArcMap is in its product life cycle it wouldn't make sense for us to update this setting and potentially break muscle memory for so many. Python is the default in ArcGIS Pro. Thanks for your contribution to the ideas site! ... View more

For earlier Pro releases, we had made a custom build of cartopy and put that up into our Esri channel, but hadn't done that work for Pro 3.0. Because of its use of a number of packages which overlap with the core distribution of Pro, it may be challenging to get a solid build without some work on our end, but I would start with this: Run a clone from the UI or with `conda create --clone arcgispro-py3 --name cartopy --pinned`. The `--pinned` here is important because that will constrain the package set for things like Notebooks to the versions we use in Pro. In this created environment after activating, try just running `conda install cartopy`. If that doesn't solve, it means that some of the packages Pro requires aren't compatible with the build up on Anaconda. As a short-term fix you may want to make a separate environment without ArcPy and install cartopy into that, but obviously that's not ideal. Cheers, Shaun ... View more

Great, glad you figured this out! As Luke suggested, conda-forge should work for most cases where you are adding specific packages. The two steps I'd recommend are: 1. Start with the Pro default cloned environment (as you did) either from the UI or the command line with:   conda create --clone arcgispro-py3 --name spy --pinned   The --pinned flag is helpful here because it requests that the packages we ship won't be removed from the environment and the versions will match what Pro includes. 2.  When installing the package from conda-forge, use the conda-forge::package syntax or specify -c conda-forge just for the command being used as Luke mentions. For example:   (spy) C:\envs\spy> conda install conda-forge::spyder   Adding broader compatibility for conda-forge is a longer term goal, but it does become tricky at the binary level for shared C libraries which sit underneath the Python dependencies. Cheers, Shaun ... View more

OK, thanks appreciate it. Somehow this environment has almost all conda-forge packages, which I would expect to fail because of library ABI compatibility issues. If you could, I'd like to see the history file located at: C:\Users\phwh9568\AppData\Local\ESRI\conda\envs\arcgispro-spy5\conda-meta\history   That should make more clear how the environment was set up to get into this state. From my end, I tried installing Spyder into a default clone and that worked, and it also seemed to work with `conda install conda-forge::spyder` so I'm guessing there is something happening with the channel priorities which is impacting how this is getting configured. It is also possible that `conda-forge` is the top priority channel in your `.condarc` file and will force packages to that channel by default. ... View more

Python support for NetCDF is available via the included GDAL package, the Unidata supported netCDF4 package, xarray for higher level access of multidimensional arrays,  and h5py for HDF files. We also have dramatically improved the integration with NetCDF and other multidimensional formats in the software since this request was made. ... View more

Thanks for your idea! Based on the comments in this thread, it looks like this issue is addressable with a moderate amount of Python code directly using ArcPy, and is also possible using mechanisms like SeDF or plain pandas for performing the summarization. Based on that, will close this issue because the specific need can be addressed without a new specialized tool to solve it. Let us know if see any other areas that Python in ArcGIS can use enhancement. ... View more

Can you share the output of  `conda list` on the environment? This is the kind of error that is typical when the installed ArcPy build differs from what is present in the environment, but other things can also cause it depending on the contents of the environment. As Dan mentions, conda-forge packages can be an issue as they do not share a common ABI with the defaults and Esri packages, and for example the Python interpreter used is from conda-forge. ... View more