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.
I agree. Python Add-Ins are great and not having to use Visual Studio and C# to create them is a very good deal!
One Esri client is extremely interested in this functionality. They will like to be able to have continued support for Phyton Add-ins for ArcGIS Pro.
Daniel, are you able to please provide details about what you're doing with your Python add-ins. What functionality are you providing through the add-in?
Eric, are you able to please provide details about what the customer is doing with their Python add-ins. What functionality are they providing through the add-in(s)?
Python is an important and necessary "easy" GIS automation language... much akin to AML and Avenue and how those languages kindled a strong, vibrant, and skilled "GIS Analyst" caste. Continued support of Python (and Python AddIns) in ArcGIS Pro is a confirmation by ESRI for the continued support for this vital "GIS Analyst" role. These are the people that wear many hats in an organization and do all the geoprocessing, cartography, analysis, and automation, but don't necessarily want to be a full blown .NET Programmer. Many of us got into GIS for the coolness aspect, but also many of us are not enamored with the idea of doing full time programming work. Prior to the active support of Python (ArcGIS v9.0), ESRI had, in my opinion, inadvertently divided the traditional "GIS Analyst" role two main groups:
1. Programmers (people that you had to go to in order to automate anything)
2. Cartographers and data editors (non-programmers)
I am pleading with ESRI to actively support the classic GIS Analysts in the world by continuing strong and active support Python - and specifically continue their support for Python AddIns in ArcGIS Pro.
FYI: Here is an ugly copy/paste of some documentation for a Python AddIn that we (WA State Dept. of Natural Resources, Forest Resources Division) developed internally for our Timber Sales Program staff (see below, pictures got lost, but you get the point). The Python AddIn basically assists in the automation of standard high quality map products that are used by our customer base (private companies that bid on the timber resources we put up for auction). Prior to the Python Addin: Because we lacked the .NET/ArcObjects skills internally in the business group (and our IT Division refused to assist us at the time), we had to contract this work to a rather expensive and difficult to work with private consulting firm to build an ArcObjects .NET toolbar that did basically the same thing. The old ArcObjects tool was extremely buggy and very difficult to maintain. Now, the new Python-Addin tool is easily maintained and upgraded by very competent internal GIS Analyst staff who are in direct communication with our timber sales business staff. Talk about streamlining and silo busting - the development of our "SUMA" Python AddIn tool was a smashing success and we couldn't have done it without ArcGIS support for Python AddIns.
Honestly, I (and many other users) find it maddening that ESRI regularly drops support for certain functionality on a seemingly regular basis without much care as to how it impacts their user base. I recognize that porting Python AddIn support to Pro is a bit of work, but really, it is entirely doable!
Cmon' ESRI, your customers need you!
|
State Uplands Mapping Application (SUMA) Toolbar 2.1.0 Quickstart Guide |
|
Forest Resources Forest Informatics 12/20/2016
|
Contents
General steps to create timber sale map documents with the new tool 2
Log in to the Citrix Environment. 2
The State Uplands Mapping Application (SUMA) Toolbar is an ArcGIS Desktop addin developed by the DNR Forest Resources Division, Forest Informatics Section. It provides tools, functions, and standardized map products to assist DNR staff in duties associated with creating Timber Sale map packets. This version of the addin was developed using the Python programming language, and the Python Addin functionality of ArcGIS 10.4.1. In this version of SUMA, our goal is to leverage out-of-the-box functionality of ArcMap, automate processes when possible, and to rely on users’ skills working with the base software to more efficiently create SUMA map products.
The new version of SUMA will create all map products in a directory that you specify. It copies data from sources on the network, and creates a local file geodatabase to hold user data. The local geodatabase also stores a grid feature that is used to hold map page definitions (page extents). At the time of project creation all map products are copied into the user-specified location.
Note: When the tool completes it will attempt to open the map document that you specified in your current ArcMap Session.
If you select ‘Cancel’, the tool will not open the new SUMA map product that you specified in the tool dialog.
SUMA 2.1 relies on the built-in functionality of ArcMap whenever possible. This is the case for editing where you will use Feature Templates that have been defined with existing symbology and default attribute values to add new features.
The new SUMA map products use a dynamic legend. Therefore, only features that are visible in the data frame are present in the legend. As you pan to new extents, the legend should update to reflect the symbology of the features that are in the new extent.
This may be undesirable if you do not want all of the symbolized values to be shown in the legend. You will notice that there are two Unit Tags layers and two Stream Labels layers in the Table of Contents of some of your map products. For example, there is a ‘Unit Tags Legend’ and ‘Unit Tags’ layer in the Timber Sale Map. The ‘Unit Tags Legend’ layer is the layer that determines which values are symbolized in the legend. You can remove symbols in this layer, which will remove them from the legend, without effecting the symbology in your dataframe.
Example 1: You edit your ‘Unit Tags’ layer by adding a record for ‘Right of Way Tags’ (single line) and ‘Right of Way Tags’ (double line). You only want one of these values to be visible, so you manually edit the ‘Unit Tags Legend’ layer to show the symbols visible in the map.
Example 2: You want all of the values from your ‘Unit Tags’ layer to show up in the legend, and you don’t want to update the ‘Unit Tags Legend’ layer for each new dataframe extent. You remove the ‘Unit Tags Legend’ from the legend, and add the ‘Unit Tags’ layer. If you select Items > Unit Tags > Only show classes that are visible in the current map extent, the software will update the legend dynamically. There are no ‘Unit Tags’ features visible in the dataframe, so no values are visible in the legend.
Note: if a record with a value previously absent in the legend is added via an edit session, that new symbol will not be visible in the legend until the edits are saved and the edit session is closed.
Navigation between map products is accomplished with the built-in ‘Open’ button. The default folder is the folder where the current map document is saved. You no longer open SUMA map products using a project file, you can open the .mxd just as you would any other.
This version of SUMA will use extent rectangles with attributes that identify the associated map product to generate pdf documents and define bookmarks. In general, when a user defines a map page, he or she is capturing the extent of the data frame, and a polygon is created using those coordinates and inserted into the Grid_Index feature class in the Source_Data.gdb.
There are two tools that can be used to generate these extent rectangles. The first is the ‘Page Selector’ tool. This button will capture the current extent of the dataframe, and create an extent polygon. The page number is incremented automatically. This tool is only available in the Page Layout View.
The second way to define map pages is to use the ‘Import Pages’ tool. This tool will copy the extent rectangles that have been defined for one map product, and apply them to another map product. It does not change any map product, or copy any data except the appropriate Grid_Index features.
The user will be able to view the extent rectangles that have been recorded for the current map product with the use of the ‘View Pages’ tool. The intent is to allow users to preview the extents that have been recorded to ensure that the entirety of the sale will be included in the production of final map documents. This is different than having the ability to preview the final output, but should approximate that functionality. The extents, and the associated page number, will be displayed in the dataframe. A dialog box will also be present.
By design, you will not be able to interact with the map document while viewing the pages that have been captured. Once you click ‘OK’, your map will be restored to the extent that it was zoomed to prior to using the ‘View Pages’ tool.
Another method to view the map page extents that have been recorded for the current map product is to use the ‘Zoom To’ drop down. The pages will be listed by page number (e.g. “page 1, page 2, etc.”), and the map will be zoomed to the extent associated with the page number after the user selects that page from the menu. You will only be able to view pages for the current map product, it will not allow you to navigate to other map products. This tool relies on the extent polygons that are stored in the Grid_Index feature class within the Source_Data.gdb.
This tool allows you to reorder and delete pages. Pages are grouped by map product, and the pages are numbered in the order they were added using the ‘Page Selector’ tool. You have the option to reorder/delete pages from all map products, or to reorder/delete pages from the current map product.
The page numbers are used to populate the ‘Bookmarks’ drop down menu to allow users to navigate to the page views he or she has recorded. Additionally, the ‘Create Final Output’ tool uses the page numbers to determine the order in which map pages are converted to pdf documents. The user can reorder map pages by moving the map page name up or down relative to other pages of the same product. The map pages for each product are determined by the position of each map page in relation to other pages of the same product. The tool automatically renumbers the map pages during execution.
This tool uses the grid index feature to export map documents to pdf format. A date-stamped folder is created in the folder the current map document was opened from, using the naming convention: ‘output_YYYYMMDD_HHMMSS’, and optionally, another folder named ‘pages’ will be created within the date-stamped folder. This is done every time the user uses this tool. Previous output is not overwritten.
By default, one pdf is created by map product. For example, if there are three pages defined for the Timber Sales Map and two pages defined for the Driving Map, then two pdf documents will be created: one Timber Sales pdf and one Driving Map pdf. Optionally, the user can check the box that asks, “Single Page Output (optional)”, and one pdf will be created for each page, regardless of the map product. These will be stored in the ‘pages’ subfolder. In the previous example, if the user had checked the optional box, then three Timber Sales Map pdf’s and two Driving Map pdf’s would be created in addition to the other pdf documents.
Upon completion, the output folder is opened and the user can open the pdf’s that were created.
Wow! Thank you for the detail, csny490. Very helpful.
Python add-ins can be easier for users to find/use than Python script tools. Is it possible to add a custom toolbox to the ribbon interface as a workaround?
Hello,
I have been building some Add-ins based on ArcGIS toolboxes for both the USFS and BLM. In addition I have migrated two large C# arc object programs and their corresponding Add-ins to python code and add-ins for much easier future maintenance. Now I can do the complete job with only ArcGIS, python, toolbox forms, and arcpy. It is nice to not have to pass the toolbox off to a .NET developer just to do the add-in. I hate the back and forth and problems that can cause (and cost to an agency). I really dislike the idea of purchasing Visual Studio just so I can distribute the python tools in the form of an add-in. On one of the C# conversions I was able to tweak the python version to get better performance than the compiled C# version which was a surprise to me.
A few of the more complex python programs used cx_Oracle to perform large queries of the agencies oracle database. The oracle passwords had to be protected. I found that password protecting a large program made it very slow to open off of the toolbar. However, the oracle query portion could be split off into a smaller tool in the toolbox that is called from the main program and password protected solving that problem. It seems that with some thought one can get around most development problems for ArcGIS using python. And, there are huge python resources on the internet. As an example, I struggled for a while figuring out how to put the oracle queried tuple into the arcpy "in_memory" but after looking around the internet I found the solution to that.
Python has finally replaced AML with as much and more functionality. Qualified GIS users in government agencies can now develop professional Add-Ins with only the software available to them that comes with ArcGIS. Not having the capability of a python Add-in could be a good reason for agencies to not move forward with ArcGIS Pro. Python should now be the language of choice for building most ArcGIS applications. Using .NET and VS should be reserved for applications needing complex custom forms. I have found that for most applications that the forms available with a standard toolbox are very adequate if used correctly. And, the program becomes much simpler if it does not have to include internal forms.
At least a toolbox works well with ArcGIS pro and it is easy to port a python 2.7 program that uses mostly arcpy toolbox commands over to 3.x. Of course, ArcGIS Pro does not recognize the location of MXDs but there are mostly minor problems such as wanting spaces and not tabs. The only major problem I see is if it does not support a python add-in. That would be greatly disappointing.
Come on ESRI - Please develop the necessary tools for a user to create a Python Add-in with ArcGIS Pro. If you don't, moving on to ArcGIS pro will seem like going backwards in functionality. I think that GIS users are just starting to catch on to the power of a Python Add-in. Don't give up on them.
Dan
Hi Kory,
I have not signed on to this site in quite a long time. However, I added a post below that should help answer your question. I have been building python tools for the BLM and FS. I think that python ADD-ins are just starting to catch on and once they do folks will demand that functionality with ArcGIS pro.
Dan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.