I'm a geospatial engineer (or, if you read my last post, a Topographer) and a large part of my job these days deals with making geospatial data - mapping data - available to users in easy to use formats. In the past (like, waaaaay back in the 1990s) it was easy - paper maps were the pinnacle of content delivery for most organizations. Hit the 'Print' button, wait for the map to come off the plotter then sneakernet it to your customer.
Then this thing called the Internet came along, and folks started to think hard about ways to deliver maps and geospatial data across the web. Early efforts were crude by today's standards, little more than snapshots of maps posted on websites. But considering we were moving up from a plain paper map (itself a static representation of the earth's surface) the early web technology was pretty slick and drew lots of ooohs and aaaahs from users.
Things improved rapidly from there, but it was clear to early developers that creating worthwhile web maps was going to take some pretty heavy duty custom programming. The early web technologies - web servers, web mapping software and even the web browsers themselves were still rough around the edges and smoothing out those rough edges took lots of dedicated programming. This is where we started to see the rise of the IT-centric GIS professional, folks who focused heavily on web development to help other GIS professionals get their content out to users via the web.
It is the rise of the IT-centric GIS professional that gave me lots of heartburn. I watched as basic GIS skills and concepts - those skills and concepts that defined our profession - were de-emphasized in favor of IT skills. This rapidly increasing dependence on IT services for content delivery also triggered some nasty organizational battles. Suddenly IT managers and CIOs were able to leverage this emerging technology to their advantage. Their argument was simple - "If you want access to the heavy web and database server technology you say you need to do your job then you'll have to move your GIS organization into IT. We need keep a proper eye on you and make sure you don't put our precious network infrastructure at risk."
Just as I was nearing the brink of despair the lighbulb came on (and in my addled brain it's a very dim bulb). For the past few years ESRI, the Big Dog in GIS technology, has been pushing the concept of the "ArcGIS map service." An ArcGIS map service is simply a map definition file (map extents, content layers, coordinate system, text styles, etc.) similar to an XML file that sits on a GIS map server waiting to be 'consumed', or used, in another application. I'd attend ESRI seminars and conferences and listen to the ESRI Acolytes expound the virtues of ArcGIS map services; they were going to revolutionize geospatial content delivery, they were going to bring web mapping to the masses, they were going to cure world hunger, boils and wheat rust.
I have been beating ESRI up for years over the direction they are taking the GIS profession - we are in a situation where the software defines and drives the profession and not the other way around. The result is that now that when you say 'GIS professional' to someone they immediately think of the software, not the skillset; a GIS professional is now merely someone who operates GIS software, not someone who has the education, training and experience to solve complex spatial information issues.
But on the issue of web mapping it looks like ESRI is on track to redeem themselves. ESRI's goal is to make mapping ubiquitous - both the creation of maps and the access to maps via the web. They realize that if web maps were to become easy to make and easy to access they needed to find a way for the GIS professional to step right over all the complex IT technology and put their maps out on the web with just a few button clicks.
While ESRI is not quiet there yet, the concept of the ArcGIS map service takes them a far bit down the road towards realizing their goal. Just as important - by easing the technology burden ESRI is, perhaps intentionally, starting to ease the GIS professional's heavy dependency on IT. Creating ArcGIS map services is simple, and it all starts with the desktop mapping and geospatial data management software. Once the GIS professional creates a map he or she 'publishes' it to a GIS map server using simple functions built into the desktop software. Once that ArcGIS map service - that map definition file - is available on the map server a large and growing number of applications can use it. You can use a service or combination of services to make custom web maps that run inside your own website, you can display and use map services in applications like AutoCAD and Microsoft SharePoint.
In the arena of 'mapping for the masses' ESRI gives the average user a number of ways to create custom maps using map services. On ESRI's website www.arcgis.com you can create maps from ArcGIS Services available on ESRI's data servers (or your own GIS map server if you have one set up). You can search for available map services a number of ways - content, geographic extent, developer, etc., then add them to your map. Once added, you can stack the services for the best presentation of data (for example, if you were building a map that showed rivers in a particular region and you were using one map service that provided a map background and another service that showed rivers you probably want to make sure the services are stacked so the rivers layer is sitting on top of the map background layer). After you build your map and have it looking the way you want it you save it on the ArcGIS.com website and you can then view it either in the native ArcGIS.com map viewer, in the ArcGIS Explorer Online website (this site uses Microsoft Silverlight to add some unique functionality like the ability to do markups) or you can view it using ESRIs ArcGIS Explorer desktop application which you can download for free. Heck, ESRI even makes applications for the iPhone, iPad and Android devices that let you view your maps anywhere you have an Internet connection.
Last but not least, you can embed your ArcGIS.com map in your website or blog using code automatically generated for you. The map at the top of this blog entry is a perfect example. I created this map using three map services available at ArcGIS.com. It uses an imagery basemap (Microsoft's Bing Imagery) service, a digitzed USGS topographic quad sheet service and on top of it all a dynamic US National Grid overlay service. You can roam around and zoom in and out on this map from within the blog, or you can click the "View Fully Functioning Map on ArcGIS.com" link to open the map using the native ArcGIS.com map viewer.
From a GIS professional's perspective this is exciting technology. For the first time the average GIS professional has the power to create and launch robust GIS-based web maps and have them available across a number of platforms. Gone are the days when a GIS professional needed to also be a code jockey to get even the simplest representation of his or her data out on the web. The ArcGIS map service concept doesn't allow GIS personnel to completely ignore the IT burden (we have not even touched on the issue of RDBMS-based geodatabases), but it is clearly a move in the right direction. I like it, and for the first time in about five years I give ESRI an 'atta-boy'!