Esri Mid-Atlantic User Group Conference Recap: Part 1

This year’s Esri Mid-Atlantic User Group (MUG) Conference was located just north of Baltimore City in Hunt Valley, Maryland.  Having grown up in Northern Maryland and attended UMBC, this conference was a little bit like heading home for me.  I ran into a number of former classmates and colleagues from across the state of Maryland and really enjoyed “geeking out” about the innovative work we have been doing over the years.

If I could choose one buzz word to describe the future of GIS it would be Integration. With Esri’s upcoming 10.1 release and increasing push into cloud infrastructures, it is becoming easier to push data developed in ArcGIS Desktop to map services hosted by ArcGIS online, that feed applications hosted on a webserver to clients anywhere in the world.  It is a different concept than what I am used to.  I think Clint Brown said it best when he proclaimed ArcGIS Online the Flickr of GIS.

In addition to integrating a number of their software products, it sounds like Esri has invested a lot of time simplifying the everyday maintenance of their ArcGIS Server and ArcSDE products.  ArcGIS Server is getting a total make over, dropping support for DCOM connections and trimming down the number of installed users from three to one.  Also, I really like the incorporation of more Database Administration tools into ArcCatalog.  Hopefully gone are the days of cracking open SQL management studio to manage users.

I was left really inspired by this year’s MUG.  There were a bunch of presentations that showed the increasing role that GIS plays in disseminating information to typically non-GIS users.  The Flex Site the Baltimore City Fire Department set up for emergency responders working the Grand Prix showcased how GIS can be used to help dispatchers make decisions on the fly in a rapidly changing environment.   I also thought the model the National Capital Region Geospatial Data Exchange utilized to distribute data between local governments, private industry and non-profits was really innovative.  Silos of data are nice and all, but real information comes when multiple data is shared throughout the community.


Five Reasons You Should Be Excited About the 10.1 ArcGIS Runtime SDK

With ArcGIS version 10.1, Esri will introduce the ArcGIS Runtime and associated SDKs. There’s already a lot of buzz about the Runtime in the developer community, and for good reason. The runtime was been architected from the ground up with an eye on addressing some familiar challenges for GIS developers: exceedingly complex, fine-grained object models; complicated deployment; poor performance; large and memory intensive applications; lack of native 64-bit support … the list goes on. Esri hopes to eliminate many of these “pain points” with the new Runtime SDK, and I think most of us are also ready to let the healing begin. With its powerful yet coarse-grained architecture, it might be tempting to view the new ArcGIS Runtime as MapObjects and ArcGIS Engines love child, but there are (at least) five reasons why it’s more than that.

1)      Simplified deployment

You may have already seen the now almost legendary demo where an Esri dev drags his Runtime project on to a thumb drive, walks it to another machine and fires it up without an install. It never fails to gets gasps from the crowd, and for good reason. How many times have you had to sheepishly tell your client “hmm, it works on my machine”? The ArcGIS Runtime eliminates complicated deployments by packaging everything required by the application into a (relatively) small deployment package. A simple tracking application I built with a pre-beta version of the runtime weighed in at about 175 megs. Since the Runtime is split into several “functionality sets”, you can keep your deployment lean by eliminating functionality your application doesn’t require. As a bonus, a Runtime application doesn’t care about other versions of ArcGIS you might have installed, and will happily run side-by-side with its progenitors.

2)      Performance

The ArcGIS Runtime has been architected to take advantage of available CPU resources, including multiple processors and cores. It provides true multithreading and native 32 and 64-bit support. It also supports an asynchronous programming pattern (made possible by its multithreaded architecture) that contributes to an improved user experience. The ArcGIS Runtime display architecture has also been optimized for speed.

3)     Connected and disconnected modes

Both local and Web data sources for the Runtime use the same programming model, which means it’s easy to build connected and disconnected modes into your application. Since your application’s data source can be based on map (or tile, locator, geoprocessing, etc.) packages, these data can be downloaded from on the initial load and then used locally thereafter. A common and effective approach is to use online data for your base map, while deploying a map package with your application to contain operational data. Editing can also be performed in a disconnected manner, using the geodatabase check-in/check-out replication model.

4)     Intuitive object model

While functionally more powerful than MapObjects, the ArcGIS Runtime SDK is considerably more coarse grained than ArcGIS Engine. In other words, it delivers all the functionality that most GIS applications need without an overly complex object model. Under the hood, the Runtime uses REST for communication with both Web and local data sources. Developers who are familiar with any of the ArcGIS Web APIs should find the Runtime API very intuitive to work with right out of the gate.

5)     Multi-platform support

The ArcGIS Runtime supports applications for 32-bit Windows, 64-bit Windows, and for 64-bit Linux. Windows applications can be built using the WPF, Java, or QT SDKs. Linux applications can be built using Java or QT.

While your applications still won’t be writing themselves anytime soon, the ArcGIS Runtime SDK should make GIS development a little more enjoyable. The time you may have had to spend smoothing out your deployment or pouring over a couple dozen object model diagrams can now be spent doing something fun (or at least productive), like fine-tuning your cartography or making tweaks to your application’s UI.