Most of you may have heard by now, there is new desktop GIS product from Esri in our midst – ArcGIS Professional, or “ArcGIS Pro”, being the generally accepted nick-name. Targeting the desktop GIS professional, this new 64-bit product is fast, responsive, and positioned to please. Based on a modern, multi-threaded architecture, “Pro” is truly able to leverage the processing power of a capable host machine, giving new life to high intensity GIS operations. ArcGIS Professional is included as part of the recent 10.3 release of ArcGIS Desktop.
ArcGIS Professional is not an ArcMap replacement, rather an ArcMap alternative, containing a subset of present ArcMap functionality, plus a range of new capabilities. It has its own new look and feel, and may be installed alongside existing Desktop applications, ArcMap, ArcCatalog, ArcScene, and/or ArcGlobe. – Notable here, is that your existing Desktop install can remain at an earlier version, 10.1 for example, and ArcGIS Pro, fresh out of the box at 10.3, can happily co-exist installed on the same machine.
Hence a potentially “awkward” migration experience can be avoided, as the user can maintain their existing workflows with ArcMap, ArcCatalog, etc. on an earlier version, whilst at the same time they may experiment with the additionally installed ArcGIS Pro, in respect of future project requirements.
You may have come across a number of posts and documentation links detailing the further notable aspects of ArcGIS Pro, these are therefore not the focus of this blog post. Instead, the intent of this post is to elaborate on the customisation options that are available to ArcGIS Pro.
What developer environments are supported?
To what extent will the ArcGIS Professional user interface be customizable?
Will there be an SDK available for Pro, and what are some of its characteristics?
Where does Python sit within the new Pro framework ?
Essentially there are three ways that you can customise the look, feel and/or behaviour of ArcGIS Professional. – For the non-developer, the content of the ArcGIS Pro interface may be interactively modified. For the developer, Python and .Net are the available development environments. Python developers are able to use the familiar and powerful ArcPy module, to automate workflows, whilst for .NET developers, a new ArcGIS Professional .NET SDK will be available, post the initial release of Pro.
1. Modify the ArcGIS Pro User Interface Interactively
The look and feel of ArcGIS Pro resembles that of other modern desktop applications. – Available controls are grouped together into tabs of related functionality along the top of the ArcGIS Pro interface; These tabs use a modern ribbon based approach for controlling the visibility of available controls . Tabs contains groups, and groups contain commands. For example, the “MAP” tab, contains the groups : “Clipboard”, “Navigate”, “Layer”, “Selection”, “Inquiry” and “Labelling”; whilst the “Navigate” group contains the controls : “Explore”, “Bookmarks”, plus various zooming controls, as highlighted in the below screen shot.
Depending on the type of data that you have active in Pro (eg. a map or an attribute table), the tabs, groups and controls displayed in the ribbon will vary. The content of the ribbon is able to be interactively modified via the project’s “Options” pane, and selection of “Customize the Ribbon”, as shown below.
Existing tabs, groups or commands (eg. the above displayed “MAP” tab, “Navigate” group, and “Zoom Full Extent” command) may be renamed or removed, whilst new custom tabs or groups may be created.
Changes made with the “Customize the Ribbon” pane will apply to the ArcGIS Pro application, hence will be evident across multiple projects.
2. Create Custom Components Using the New ArcGIS Pro .Net SDK
.NET Developers are treated with a new SDK : ArcGIS Pro .Net SDK. The purpose of this SDK is to allow for the ArcGIS Pro interface to be extended. – That is, any of the UI component types that are contained within Pro’s interface may be re-created using the SDK. These component types include galleries, pallettes, dockable panes, buttons, tools, and menus, which may be generated using the SDK’s Add-In item templates. Pictured below are the available add-in templates that may be nominated for creation in Visual Studio (2013).
In parallel with Desktop’s pre-10.3 Add-In deployment model, an ArcGIS Pro Add-In is packaged within a single distributable *.esriAddInX file, which is discovered at ArcGIS Pro application start-up, via its presence at a well known folder location.
Together with the project and item templates, the ArcGIS Pro .Net SDK will also include documentation that details the API, and has sections covering “Concepts”, “Tutorials” and “Walkthroughs”. There will also be a set of ArcGIS Pro Add-In samples, that represent a further useful resource for new users.
Simpler, Modern Coding Constructs
Of interest to .Net developers coming from the Desktop ArcObjects .Net space, will be the point that developed code no longer adheres to the COM model. This is because ArcGIS Pro is built using an entirely new API, native to the .Net environment, and having no association with COM . Hence, Desktop ArcGIS development suddenly becomes a whole lot simpler, as it does not have to accommodate COM Interoperability, (ie. generation of .Net runtime callable wrappers , marshalling between .Net and COM, and COM registration). Additionally, being a native API, code developed with the Pro API will execute with improved performance, as translation from Microsoft Intermediate code is not required at runtime.
Built on the .Net 4.5 Framework, the Pro API incorporates the simplified asynchronous programming pattern that became available with the .Net 4.5 release. Thus, the ArcGIS Pro .Net API incorporates many asynchronous functions, identifiable with the Async suffix, eg. theProject.LoadBookmarksAsync, MapView.ZoomToAsync). Calls to asynchronous functions using the .Net async/await approach, return flow of control to the initiating function, until such time as the subject async function completes. Consequently, ArcGIS Pro workflows and customisations are able to execute efficiently in the background, whilst a responsive user interface is able to be maintained.
For example, a custom control may include an asynchronous call to zoom the active map by a fixed extent. Re-drawing of the new extent imposes a delay, however, because an asynchronous call has been made to change the map extent, the user may continue to use other controls (eg. show map tips, open Layer Properties pane) whilst the display extent is updated.
This behaviour is termed “asynchronous” because other operations were able to take place whilst the zoom extent operation was executing; You may also hear it described as “non-blocking”, meaning that further interaction with the application was possible, as the delay imposed by the zoom operation did not result in a freeze of the application.
The Model-View-ViewModel (MVVM) approach to structuring code will not be new to the experienced WPF or Silverlight programmers, additionally ArcGIS Runtime for .Net and ArcGIS Runtime for WPF developers will have come across this coding pattern. Put simply, MVVM allows the business logic of a customisation to be separated from the xaml and code-behind. Instead, business logic for a subject control is contained within a ViewModel class file, and data binding may be used to populate UI controls, rather than this being controlled by the close coupling between xaml and code behind.
ArcGIS Pro .Net developers too, are able to utilise this more modern coding pattern within their custom Pro Add-In code. Pane and DockPane Add-In templates contained within the Pro .Net SDK utilise the MVVM pattern, and there are further examples contained within the Pro Add-In sample code.
Thus, familiarity with the MVVM approach will benefit ArcGIS Pro .Net Add-In developers, a more in depth discussion of which could form the basis of a future blog post all of its own….
3. ArcPy and Python
Python and ArcPy are utilised in much the same way as we have become familiar with in former releases. Firstly, ArcGIS Pro ships with Python, albeit a more current version, version 3.4; Secondly, the familiar Desktop ArcPy utilisation options : Python command line, script tools, and python toolboxes, are all available from the ArcGIS Pro interface; Whilst the Python IDE may also be used to access and process ArcGIS Pro generated projects and contained data; Thirdly, ArcGIS Pro incorporates the ability to publish ArcPy scripts as geoprocessing services.
In terms of making the shift from pre-10.3 scripts and tools to 10.3 ArcGIS Pro ArcPy and Python, the stand out aspects that need to be accommodated are 1) the fact that Pro and ArcPy at 10.3, utilise Python 3.4, therefore Python 3.x coding constructs need to used over Python 2.x approaches; and 2) the framework differences between ArcMap/ArcCatalog, as compared with ArcGIS Pro (eg. multiple layouts in a ArcGIS Pro project file, as compared with one layout in an ArcMap document file.)
To assist with migrating pre-10.3 ArcPy scripts to ArcGIS Pro ArcPy scripts, there is a Python command line utility available (found beneath the Python 3.4 install directory) named 2to3.py. This Python supplied utility is said to perform the majority of syntax translation. Further to this, there is an ArcGIS Pro geoprocessing tool, the “Analyse Tool For Pro” tool , which will examine pre-10.3 ArcPy python scripts or geoprocessing tools, and report identified migration issues for translation to Pro at 10.3.
The complexity of the pre-10.3 script will determine the level of translation required. Simpler scripts will require minimal modification.
The point to remember too, is that pre-10.3 scripts and tools will still work within their originally intended framework, be it ArcMap, ArcCatalog, Server or Engine, as they will utilise Python 2.7.8, whilst ArcGIS Pro utilises Python 3.4. Hence, script migration to Pro may not be deemed necessary, depending on intended ArcGIS Pro future workflows.
Further to the above, and for clarification, note that the Desktop 10.3 (ie. ArcMap/ArcCatalog/ArcScene/ArcGlobe) install files include a separate installation executable for Python 2.7.8, whilst the ArcGIS Pro install file set includes a separate Python 3.4.1 executable. Thus, where a user has, for example, all of the following installed on the same machine : ArcMap and ArcCatalog 10.3, and ArcGIS Pro, and they wish to run ArcPy scripts from either ArcMap, ArcCatalog or Pro, they will have two versions of Python installed on that machine, versions 2.7.8 and 3.4, which can happily co-exist.
For readers seeking more on the subject of Python, ArcPy and ArcGIS Pro and 10.3 , there is considerable documentation available http://pro.arcgis.com/en/pro-app/arcpy/get-started/python-migration-for-arcgis-pro.htm). Further to this, Python 3 is an established Python release, having been available to Python developers for a number of years, therefore considerable resource detailing the intricacies of Python 2 to 3 migration is available at http://python3porting.com/.
In contrast to ArcPy documentation, the ArcGIS Pro .Net SDK is not yet released, hence extensive API documentation is not yet available. Stay tuned though, as the release is expected in the coming months, when we’ll all be able to see what it has to offer…….