Note: This is the second entry in a series of posts titled "Web Mapping Offerings Compared". The first post, Introduction, is available for viewing here.

Introduction

As I mentioned in the first post of this series, many of the online mapping services offer developers application programming interface (API) hooks into their services. These entry points allow developers to build applications that utilize both the data and other bits of functionality that they offer. Over the last couple of months, in my search for web mapping solutions for the organization that I work for, I have experimented with many of these APIs, and, as I worked with each of them, I noticed that each seemed to have its own unique set of strengths and weaknesses. It seems that while each of the products are moving generally in the same direction, they are all trying desperately to separate themselves from the rest of the pack while also working hard to attract developers. This can only be good for us (as the consumer, of course, but also, more importantly for me, as the developer), so I'm certainly not complaining, and as more levels of functionality are opened up to developers, I imagine that we will begin to see more "GIS-centric" applications built on top of these APIs (in place of the all-too-common 'mash-up').

The *current bottomline, though, is that these APIs don't offer nearly as much built-in functionality as a full-featured GIS web map application. Out of the box, they don't support as many data types or allow you to directly query associated attributes, etc. So, the major question is "why would a GIS professional consider using an API when he/she has access to a full-featured GIS web map platform?" Well, the answer is simple - at least for me.

I've noticed that often, although we (as GIS developers) hate to admit it, users of web map applications really only need the most basic of functionality. Although we'd like to think that all of our users need the ability to perform complex queries and analyses on our datasets, this level of skill is the exception and certainly not the rule. Now, I'm obviously generalizing here, but I'm speaking from the experience that I have within my own organization. There are certainly times where a level of advanced functionality is needed, but I would say that in about 80% of our use cases the user just needs to be able to:

• View data laid over high-quality (and high-performing) base data
• Digitize and attribute simple geometries
• Perform some fairly basic attribute queries

If this is the level of functionality that you're looking to achieve for your web map application(s), an API may be the way for you to go. And even if you need more functionality you may want to check back as this series progresses, as somewhere in the series (I haven't decided where I'll fit it in yet) I'll talk about ways that you can integrate other technologies with some of the existing API features I'll discuss to build your own web map application that rivals the offerings and functionality of one of the more full-featured GIS web map platforms. And the cool thing is that you can build a very lightweight but powerful application using this type of model.

Following are the criteria that I'm going to use to evaluate each of the APIs:

Type, Breadth, and Quality of API(s)

All of the products that I'm going to review in this API section have at least a JavaScript API that allows developers to hook into their services. A few, however, have more API offerings. This was definitely a consideration for me when looking into each of them, as different APIs meet different needs. It's pretty easy for me: the more options, the better (assuming, of course, decent quality and stability).

Kind of along the same lines, if a product's API(s) don't include the functionality that I need in my application, I'm not going to use it. Some of the APIs are more mature than others, and it shows when you start getting your hands dirty.

Accessing Data/Services (Licensing)

One of the biggest concerns/questions that I had when I first started looking into the different data/service mapping APIs had to do with licensing. If the cost or terms of use were prohibitive up front, it wasn't worth my time to spend a lot of time researching (read: playing) with the technology. Luckily, I found that the aforementioned competition in the fight to win developers and users over didn't stop at innovation in the products themselves; it also trickled down to licensing models. To put it simply, not only are the different players trying to outpace their opponents in their pricing models, all are also making their services available for free - with some limitations, of course.

Now that I've gotten all of that out, I'm going to immediately renege on one of the statements (well, I'm not really backing away from what I said, but it may seem like it on first read): While the different vendors are trying to compete on pricing, when it comes down to the licensing model that they use, they are remarkably consistent. They all use the same type of model, based on transactions, to track and (if necessary) price usage of their services. Most say that a single transaction equals nine 256x256 pixel tiles (although there are exceptions to this), so, if you pan and only have to load three more tiles during the pan, this is considered 1/3 of a full transaction.

The good news is that most of the vendors allow developers to use their services for free - up to a certain transaction limit - as long as the application is public-facing. If the application is, however, on an internal network you must purchase the data from the vendor.

Quality of Base Data

As I mentioned in the first post in this series, Introduction, one of the things that drove me towards this search was the fact that we needed to be able to use high-performing, high-quality data in our applications.

While not all of the APIs that I'm going to discuss serve their own data, the data that they use have to be served from somewhere. So, if an API wasn't built on top of a particular data service (for instance, Open Layers), I had to know what data services it could connect to, out-of-the-box, and how good the data that it could access were. For those APIs that were built on top of a particular data service, it was important for me to know how good the default data were.

Built-In Features and Data Support

While all of the APIs support a "core" level of functionality, there are certain features that set some apart. Sure, they all allow you to view data and navigate around the map, but can you easily build digitizing functionality into the application with the API(s)? Can you access the product's geocode and routing services (and this question ties back to the licensing issue)? These are the types of features that I needed for my applications, and, therefore, the types of questions that I considered when researching the different options.

Another key metric that makes it easier to distinguish between the different APIs is their out-of-the-box support for data. All of the different products allow you to create and manage shapes within a user's session, but they don't all give developers the capability to import different types of data into an application. Now, to be fair most of the products only currently support a few different types of data out-of-the-box. I imagine, though, that this will change over the next six months or so, as many of the vendors seem to be focusing more of their efforts on this critical issue.

Ability to Integrate with a GIS

Unfortunately, I couldn't just throw out my organization's GIS needs when looking at the different APIs (and I say unfortunately because, if I could throw these needs out, it would make my life a whole lot easier). I had to consider GIS-type issues like projections, accuracy of base data, and resolution of imagery (and this was especially important in some rural areas, as many of my organization's units aren't anywhere close to an urban area).

Not all of the applications that I'm working on require true GIS functionality, but this was an important consideration, nonetheless.

And Moving On...

In the next post, I'll start reviewing the APIs using both the overarching criteria that I laid out in the Introduction post and the API-specific criteria that I laid out above.

Note: I've received several requests to look at products that I didn't explicitly mention in my first post. I will do my best to get to know all of them, as I'm curious to see what's out there. It will take some time, however, so please forgive me for any delays.

Online mapping is taking off in a big way. Just look at the number of online mapping sites now available (Ask.com, ESRI, Google, Mapquest, Microsoft, and Yahoo! are the ones I can think of off the top of my head) and, especially, at the work and money that's being put into enhancing these applications and the data that they serve, and you'll see that mapping - albeit in a simple form - has truly become an integral part of most people's everyday lives. These products all have their own way of doing things, although there are obvious similarities between them all. Now the rush is on to see who is going to provide the best - and most open - application programming interface (API) and licensing model.

Over the last couple of months, I have worked to develop prototype applications with several different web mapping APIs, including ESRI's, Google's, Microsoft's, and Open Layers'. My goal when initiating this development was to get a feel for the strengths and weaknesses of each of the offerings, and, in the end, to decide the best route for my organization. In addition to working  with each of the APIs alone, I also worked with (or at least discussed in length with the vendor(s)) some third-party products that allow you to tie into the data offerings of the large online mapping vendors while working directly with databases on the backend. Through the process of learning these new technologies, I discovered quite a bit about each of them, and feel like I now have a pretty good understanding of how they compare.

Before I delve into each of them, here's a bit of background to help frame this series of posts: My organization is pretty much a strictly ESRI shop. Our current architecture sits on a Microsoft/ESRI platform, so we really only use SQL Server, ArcSDE, and ArcGIS Server. When ArcGIS Server 9.2 came out, we decided that we were going to use it exclusively for our web map applications, as it tied seamlessly into our existing infrastructure and expertise. Well, we initially ran into the same problems that everyone who used the Web ADF ran into (some of which a lot of developers are still running into - see the ArcGIS Server Forums) and were a bit discouraged by the lack of quality, documentation, and - most importantly - response from ESRI. We weren't dissuaded, though; we kept at it, trying to build tile cache after tile cache after... Granted, we were trying to build massive tile caches, but we figured since ArcGIS Server was an enterprise product, it would be up for the task. From our experiences, I can now say that we were wrong. There was only minimal documentation available initially to help us in our massive cache builds, so we had to learn each lesson the hard way. In addition to this, the product simply didn't work as advertised. Even with quite a few fairly powerful servers dedicated to building cache for weeks at a time, a lot of times we couldn't get the processes to successfully complete, and had to either start over from scratch (as there is still not a good way, at least that we're aware of, of picking up a failed cache build where it left off) or give up all together.

In this context, with lots of frustration and a bit of regret, we made the decision to widen our vision to other web map products and/or data services, as we needed to find a way to include high-quality and high-performance nationwide base data for our applications. In doing our initial research, we considered a couple of important requirements:

1. Ability to Plug-in to our Existing Infrastructure
2. Performance
3. Cost
4. Quality of User Experience
5. Ability to Support Open Data Types
6. Scalability

After considering these requirements, we settled on a number of possibilities, including:

• ArcWeb Services
• Google Maps API
• GeoServer
• MapDotNet Server
• Microsoft Virtual Earth API
• Open Layers API
• Visual Fusion Server

Now, you've probably noticed a couple of similarities in these different products. First of all, many of them are free-to-use (unless you use their data internally, of course, or go over the usage limits that they have specified (that is, in the case of using data served by either Google or Microsoft)). ESRI ArcWeb Services, MapDotNet Server, and Visual Fusion Server are the exceptions to this first rule. Second, each of them have the ability to access high-performing data that are served from either Google or Microsoft. This was probably the most important requirement to us, as we realized while trying to build our tile caches for ArcGIS Server that there was no way our organization could sustain the practice of maintaining huge datasets and building massive tile caches, and that, even if we did get a cache successfully built, we would never be able to meet the performance expectations/needs of our users while serving the data from our infrastructure. The last common thread between the products is the fact that they all support open standards, albeit some more comprehensively than others. This was another absolute requirement, as, like many other organizations, we are trying to move in the direction of open standards.

In the series of posts that are soon to follow, I will discuss my experience with these different products, focusing on the requirements of my organization and how well each of the products meet these requirements. This may be helpful to others, as our requirements seem to be shared by many others out there.