Python Add-Ins for ArcGIS Pro

[BryanChastain]

We're just now getting the full functionality of Python in ArcMap via Python Add-Ins, but now everything is moving to ArcGIS Pro and I noticed that there are not any plans to include Python Add-Ins for Pro as well. I do like the new mapping module for Pro, but please also give us the ability to create Add-Ins with Python as well.

[Anonymous User]

We have a few Python Addins in ArcMap. Mostly they automated tasks for the end user. The one Addin from ArcMap that will be missed is our Google/Bing Streetview/BirdsEye Addin. It was built using Python and well used. 

@roemhildtg has a .Net version of a Streetview Addin posted on his Github page and also mentioned here https://community.esri.com/thread/190516-is-there-a-streetview-add-in-for-arcgis-pro 

I am not a .Net developer, I don't want to learn the overhead of a VS IDE and version management of developing with MS, but I do really enjoy the ease of developing with Python. Please Esri add support for Python Addins in ArcGIS Pro.

[JohnDye2]

+ 1 billion on this. 

[MikeLachance1]

Any movement or updates on this idea? The new 2.3 update included a bunch of basic functionality that we were looking for in Pro. The ability to write Add-Ins in Python and compile them using a Python-Add In utility would be something that would really drive our use of Pro.

Specifically, I am looking to be able to create a custom toolbar with 1 to 2 drop-downs that contain values from specified fields in a data layer. When the user selects a value from the drop-down, the add-in creates and applies a definition query filtering datasets in the map. We are using this to filter data sets in our maps by a specific species we want to look at.

I wrote a Python-Add in for Desktop that does this very well. I have a work-around using tasks in Pro, but it's clunky and takes up window space to open and run compared to a sleek custom toolbar that would be docked on the ribbon.

[KoryKramer]

For this specific use case, have you looked at the multiple definition query behavior that was added at Pro 2.3?  

What's new in ArcGIS Pro 2.3—ArcGIS Pro | ArcGIS Desktop 

https://community.esri.com/community/arcgis-ideas/blog/2019/01/17/ideas-in-arcgis-pro-23 see 7:56 for a quick demo on the drop-down behavior.  Also, as a tip, regardless of the underlying query, if the queries Share the same name, you can multi-select layers, and using the dropdown will toggle the queries across all layers selected in the Contents.

Again, not sure this would meet the specific need, but wanted to share the thought.

[DanGreene]

Hi Mike,

I agree with you.  Taking away the python add-on capability is a big deal.  I hope that no one I am working with switches to PRO before there is python add-in capability.  The existing python add-in setup for desktop works beautifully.  I too have zero desire to utilize visual studio for the sole purpose of creating an add-in.  I would guess that ADD-INs for desktop have taken a while for people to catch on to but once they do I'm sure they don't want to revert back to the old way.

Dan

[MikeLachance1]

I will check this out and report back, thanks Kory!

[WarrenDavison]

I'm going to echo what many have already stated above here. Being a GIS Analyst and wearing many hats within my organization, creating add-ins with Python allowed me to develop tools for our users that achieved significant efficiencies without having to learn an additional language or require additional software. It doesn't seem at all logical to have this capability in ArcMap but it be a glaring omission in ArcGIS Pro.

To provide some context, the types of tools we've deployed are lightweight tools that compliment and expedite the portions of data editing/creation that are repeatitive and manual in nature. These tools are integrated into our editing toolbars and are designed to be much less disruptive to the editing workflow than a geoprocessing tool. These add-ins also make use of dynamic/temporary geometry drawn in the map by the user in order to create/edit features, which isn't possible with geoprocessing tools.

For instance, we have a tool used to bulk re-align (or zip) misplaced/haphazardly digitzed addresses along a street segment. This add-in takes a selected set of address points and re-aligns them to the vertices in a line geometry captured by the user using the Tools.shape. This tool functions seamlessly within the users' editing task and doesn't interrupt them with a cumbersome dialog box etc. as would a geoprocessing tool. This specific add-in can be found here.

Similarly, we have other tools that assist with data editing and speed up the creation of common "feature assemblies". Our users have an add-in that creates common collections of features (aka feature assemblies) such as hydrant leads, valves, fittings, and hydrants all from the add-in tools.shape. Therefore, a user is able to generate all of these features in their correct orientation and with commonly populated attribute defaults from a single line geometry. This add-in significantly increases efficiency and reduces the manually intensive digitization of these very regular feature assemblies.

I'll also emphasize that these tools we've created were all constructed with very minimal lines of code, since the add-in creation was so easy, and that we didn't have to involve our developers and explain the specific geospatial requirements of the add-in etc. So in short since the Analysts are typically one tier closer to our end users we were able to develop an add-in that was very succesful very quickly for our end users without having to get bogged down explaining the need and the unique geospatial nature of the add-in requirements to our developers.

I think Python has to be added back into ArcGIS Pro as a language to create add-ins in order to support the diverse ecosystem of users and not create such a divide between users and developers. GIS Analysts fall within that gap and serve bridge that divide, but we can't work effectively if tools like Python add-ins are taken away and removed from our toolsets.

Warren Davison‌

[KoryKramer]

Thank you for the thoughtful input, Warren.

[DanGreene]

Warren - those are excellent reasons that we need to keep Python Add-In capability.  Thanks for sharing.

Dan

[MikeLachance1]

Kory,

While I like the ability to save a DQ by a user given name and easily apply it by selecting it from the Definition Query section of the Data tab, it doesn't quite replicate the function that we created with our Python Add-In filter tool.

In our case we are looking to be able to select a given species from a drop-down list of over 300 species and have a definition query be applied to certain layers. The DQ would be something like 'species' = <user-choice from list>. Ex. 'species' = 'Acer rubrum'.

Our Python Add-In generates a list of species for the drop-down based on a reference layer, so that when the reference layer is changed, so will their options in the drop-down list on the Python Add-In.

While I can see the DQ functionality in 2.3 being great for other situations, I don't think it's useful for us in this instance since we would have to create and name a new saved DQ for every species we might want to filter in order for them to show up in the DQ tab drop-down.

Any other ideas how we might be able to filter data in ArcPro like this?