Whenever GIS developers discuss technology choices for a given project, a broad range comes to mind. In this article, I will cover the most popular technology choices a GIS developer makes in the Esri GIS world. Variations may look confusing for the GIS beginner, but that is compensated by flexibility within development. That flexibility is sometimes more important for deployment, whether it is a one-time-run script, a useful tool for GIS engineers, or a data processing batch.

Geodatabase Editing

Development in the GIS world is a process of building tools that work with data. The obvious choice at a first glance would be to work with data on a database level. Esri geodatabases support data editing via SQL scripts. The challenging part here will be the editing of versioned data. The geodatabase maintains versioned views that allow the editing of versioned data; however, you will need to switch to a version with help of a stored procedure. For editing geometry via SQL scripts, the ST_geometry library is used. The database server requires an installation of this library in order to use ST_geometry functions. Some data processing algorithms can be built completely with SQL scripts, but the complexity of SQL scripts may grow exponentially when the project requires advanced logic. If so, then you know it’s time to think about another layer on top of the database – programming or script languages.

Python

Scripting with Python is perfect for working with the data schema. Many functions of the ArcPy module make a developer’s life easier. Personally, when it comes to any data model change, I prefer to write a Python script, as it always helps to introduce changes to a new environment. The most used ArcPy functions, in my experience, are the functions that allow you to create tables, create fields, change user privileges on tables, and manage domains. Besides these, we often use ArcPy to build data export/import tools, maintain geodatabases, and update ArcGIS Server services.

VBA

VBA is an old technology, but there are still cases in which GIS developers can find VBA useful. This is mostly because VBA is good enough to write logic. VBA has access to ArcObjects and object extensions. With that said, so does C# .NET (the native programming language for many developers), but the difference is that VBA code can be run as a script from ArcCatalog or ArcMap at any point. There is no need to deal with licensing, database access parameters, and executable body or extension for your code. If you are familiar with VBA and need some scripting – go for it, but I believe everyone would give a “no-go” to VBA for anything more than a script, and that’s when .NET comes into play.

.NET

It’s hard to beat highly extendable .NET code when it comes to the development of GIS tools with the use of ArcObjects. ArcMap tools, GIS integrations, customizations, geodatabase maintenance tools, custom applications – all that is possible with the ArcObjects SDK and the capabilities of .NET. SSP has implemented hundreds of these, utilizing .NET with ArcObjects. However, due to their nature, some projects may not need ArcObjects, or developers may have specific reasons why they should not utilize ArcObjects. This can be due to several factors, such as limitations of ArcObjects performance, licensing, or if a project does not share a platform with ArcObjects.

ArcGIS Server Services

ArcGIS Server Services provide access to versioned GIS data via REST API, so any application or web client can retrieve data with no hassle. As an alternative to ArcObjects, I find the ArcGIS Server REST API just perfect for integrations when you need to spin up web services which talk to the geodatabase. As well, it wouldn’t be fair if I didn’t mention the ArcGIS API for JavaScript. That, along with the ArcGIS Server API, allows you to build web mapping applications. Also, if you had a chance to take a glance at ArcGIS Pro SDK, you probably noticed that ArcGIS web services can now be used as a geodatabase source option. ArcGIS Pro already wraps REST API calls – the only database access type supported by the Utility Network – into .NET objects .

ArcGIS Pro SDK

The ArcGIS Pro SDK has advantages over ArcObjects:

• Supported .NET framework version: Pro – 4.6.1; ArcObjects (pre-10.4) – 3.5
• Pro – 64-bit architecture; ArcObjects – 32-bit. More power.
• Pro needs no .NET-COM interop middleman services; ArcObjects are COM objects. Again, this gives a performance benefit.

I was curious about the performance of Pro SDK, so I built two identical console applications. Applications opened a feature class in the SQL Server GIS database and made a spatial search against another feature class. I ran this test multiple times on the same machine and the results were quite impressive to me – 00:00:46:71 for ArcObjects, and 00:00:26.97 for the ArcGIS Pro SDK. The Pro SDK is not an obvious choice for developers yet, but code migration is more than just rewriting existing code. The ArGIS Pro platform differs from ArcObjects in that it does not support the geometric network and other extensions. Licensing is also implemented differently. It’s not a completely new world from the programming perspective, but it will need you to rethink even some basics.

Finally, there’s also the matter of experience and tricks a developer has in their pocket to build a good GIS solution. Any GIS project, or even just one tool, often requires a combination of technologies for implementation, which is sometimes not that obvious on the surface. Like you would in a good garage, it’s nice to have all kind of tools and know how to use them properly.