Johannes Kebeck has an interesting post showing how to get the benefits of the MapPoint Web Service method, FindNearRoute, through the use of SQL Server 2008. He uses a newly-added feature of the Virtual Earth API that allows developers to gain access to a complete returned route-geometry when performing a route. This new feature, however, does require that the mapping application use customer identification (which, in turn, requires that you sign up for a Virtual Earth platform developer account).

If you haven't checked out Johannes' blog lately, you might want to give it a go now. He has written a whole slew of Virtual Earth and SQL Server 2008 posts lately, and there's a wealth of good information there.

We've already started using SQL Server 2008 in some of our development applications, and are planning on taking advantage of ArcSDE 9.3's ability to utilize SQL Server 2008's spatial data types. We're hoping that by doing this, we'll be able to offer access to our geometries through both traditional GIS tools (ArcGIS Desktop for our shop) and web services (ADO.Net Data Services returning JSON and XML and other services built on top of WCF). As we're already using ArcGIS Server 9.3's REST capabilities from within our JavaScript/Virtual Earth applications, if we can "close the circle" by tying SQL Server 2008 and Virtual Earth together in a robust and meaningful way, we may just be able to hit the proverbial bulls-eye. We've already written quite a bit of code that brings these technologies together, but are still deciding on the best overall approach.

One thing that is still unclear to me is if we're going to utilize ESRI's tools heavily or try to avoid them as much as possible and stick with all of the non-ESRI .NET technologies. In a lot of ways, we're already going the latter route (saying ArcGIS Server 9.2 still leaves a bad taste in my mouth), but I've been impressed with ArcGIS Server 9.3 so far, so I'm withholding judgement until we see how the new set of technologies perform in a couple of months.

And from the Microsoft camp, I expect that more direct integration with SQL Server 2008 will be coming soon to the Virtual Earth API. I haven't, however, heard of any solid dates yet. Any integration will be much-welcomed, as it will save us precious development time.

Whichever route we decide to take, it's pretty obvious that now is a great time to be working in web mapping. Especially if you're able to take advantage of all the integration points available through .NET.

Firebug is a web developer's best friend. Without it, there are times when we'd be absolutely lost. Luckily it is actively developed and well-supported.

The 1.1 beta version was released in the middle of February, but I'm just getting around to upgrading to it. Until I started to actively use Firefox 3, I didn't see much of a need to upgrade (Firebug 1.1 can be installed on Firefox 3), but boy was I wrong. There are a couple of big additions that make this a must-have upgrade for me:

• eval() debugging - this is the big one. I can't tell you how many times I've run into cryptic issues using the eval() statement. Firebug 1.1 handles this by displaying code sent to eval() in the Script panel as a new source file. This code can then be debugged just like any other JavaScript in Firebug. If you don't want to debug eval() code, you can always turn this option off. You'll get better performance with it turned off.
• Aptana IDE editor integration - I use Aptana's Eclipse plugin for all of my CSS, HTML, and JavaScript coding, and integration between Aptana and Firebug only makes my life that much easier.
• Cache tab for Net panel - this should make it easy to verify if a resource is cached or not.
• Supports Firefox 3 - already mentioned this one above, but thought it should be mentioned again.

If you haven't heard of Adobe AIR yet, you will soon. It is a runtime that allows developers to deploy web applications to the desktop, cross platform (well, I say that, but Air is currently only supported on Windows and Mac OS X, but Adobe says that the "Linux release of Adobe Air is under development" and will be released to "public alpha on our [Adobe's] Labs website in early 2008 in order to collect feedback from Linux developers").

After a fairly long incubation period in Adobe Labs, AIR 1.0 was released today. That said, AIR is already somewhat proven, as developers have been working with it for quite some time now and several large companies are already taking advantage of the technology.

What are the benefits of Adobe AIR? Well, other than the obvious (write once for the web and desktop, utilize your web development skills, etc.), AIR provides a number of benefits that you only get with a traditional desktop application, including:

• the ability for an application to run in the background.
• the ability to run while disconnected from the internet.
• full desktop integration, including access to the clipboard and system tray.
• access to a local database.
• increased application response time.

If you don't buy into the hype, I understand, but I encourage you to at least check it out. Here are some good links to check out:

• Dav Glass has packaged a sample AIR application built on the latest YUI release.
• Jack Slocum, author of my favorite JavaScript library, Ext, recently converted the Simple Tasks sample application to run on AIR 1.0.

And in closing, if you want to work with Adobe AIR (or you do a lot of front-end development with JavaScript), you should check out the outstanding Aptana IDE. It is the best IDE for doing AJAX development that I've found, and has support for Adobe AIR development. I discovered it several months ago while looking for a Ruby on Rails IDE, and haven't looked back since.

I expect that I'll be playing with AIR sometime soon, although most of the development that I'm currently doing (web map development) doesn't really fit into AIR. If I do play around, I'll post here.

Jason Levitt recently announced in a Yahoo! Developer Network blog entry (dated December 21, 2007) that Yahoo! Maps is now pure JavaScript. In the past it was a hybrid Flash/JavaScript application. The new port brings, according to Levitt, "at least double the performance of the previous Flash-based version". And of note to developers, the enhanced version of the Yahoo! Maps AJAX API which is being used in the newest version of Yahoo! Maps will be made available to developers sometime in 2008.

To be honest, I haven't paid all that much attention to Yahoo! Maps over the last couple of years, as both their "flagship" application (maps.yahoo.com) and their API have, to be quite honest, failed to impress. And (staying honest here), after using the application and perusing the API again tonight, I'll have to say that I'm still not all that impressed:

• The application's responsiveness just doesn't seem to be up to par when compared to Google and Microsoft's mapping applications (maps.google.com and maps.live.com, respectively). Please note that at this point, this is just an observation; I haven't conducted - or even looked for - any performance tests, but I definitely think that Yahoo! has a long way to go before they'll be able to start seriously competing against Google and Microsoft.
• On top of this, the look and feel of the application just doesn't do it for me. In my opinion, Microsoft - with its latest release - has the best looking and most usable interface out there. Google still has more "Wow!" features ("Wow! I can drag a route to change it!" ), but I don't think that I've ever actually used any of them.

To close, I'm disappointed that Yahoo! - one of the companies that really led the way in the early (2005) web map API days - has fallen so far behind. I hope that this coming version of their Maps AJAX API will bring them back into the competition.

Over the last year or so I've turned into more of a "client-side" developer than I would have thought possible a couple of years ago and, therefore, write quite a bit of JavaScript every day. That said, I haven't really contributed to the development of JavaScript, JSON, or AJAX (but have greatly benefited from each of them), and you should certainly listen to anything everything that Douglas Crockford says about JavaScript and technology in general over everything anything (about JavaScript or technology in general) that I say. But... I'll have to say that I disagree with a recent entry that Douglas published on the security of JavaScript and how it relates to people's everyday browsing habits.

In a recent post, titled No Script, Douglas wrote about a Firefox Extension (named, of course, "No Script") that turns off, by default, most of the executable content in Firefox and only "allows JavaScript, Java and other executable content to run from trusted domains of your choice, e.g. your home-banking web site, and guards the "trust boundaries" against cross-site scripting attacks (XSS)". In the entry, Douglas goes on to recommend that we should "be using Firefox with No Script". On the official Firefox Add-ons page, the description of this NoScript extension goes on to claim that "Firefox is really safer with NoScript ;-)".

While I would never argue with Douglas' or the extension development team's assertion that Firefox (or any browser) is more secure with executable content turned off, I did ask myself a couple of questions the first time I read Douglas' recommendation:

• How much of a threat is JavaScript (or other executable content like Flash and Silverlight) to the majority of everyday users on the internet?
• Is the threat great enough to ask these everyday users to make snap judgements as to what executable(s) are allowed to run when they visit a website?
• Can an everyday user really be expected to make a sound judgement as to what executable(s) should be allowed to run when they visit a website?

And, by the way, it looks like Jon Udell asked himself a similar question when he read Douglas' entry.

I'm going to go on a bit of a tangent here, but if you stick with me I think you'll see where I'm going when I'm done: In my 9 to 5 job, I work closely with the federal government on a number of projects, and I'll have to say that Douglas' recommendation reminds me a bit of the IT policies that have recently been working there way down in the federal government from on high. In short, a lot (most) of these policies seem to be pushed down with little or no consideration of the amount of impact that they will have on the productivity of the overall workforce. While I understand that this is a difficult metric to quantify, it seems to me that it is an important factor that should always be considered.

While security - especially in an enterprise - should always be a chief consideration when formulating IT policy, it seems like organizations sometimes take it a bit too far. I'm probably misrepresenting utilitarianism when I say this, but doesn't it make sense to consider the greater good when developing IT policy? Shouldn't the impact of a policy always be quantified (on both sides) before implementation?

Here are a few greatly-simplified examples that demonstrate the effects of (what I see as) rash IT policy formulation, and realize that I worked in IT support before my current job, so I can see this issue from a couple of different viewpoints:

1. Sure, it's a pain to rebuild a workstation after it has been infected by a virus (most of the time this costs somewhere between 1.5 to 5 hours of IT support time), but how much more of a pain is it for users (over ten thousand in some enterprises) when you have antivirus software running real-time scans on their workstation and consuming a third - or more - of the workstation's resources? If quantified, the impact of installing bulky antivirus software on workstations could cost an organization thousands, if not hundreds of thousands, of hours of productivity over the course of a year. Even if some data are lost because of an outbreak (and if proper pro-active backup policies are in place, data should never be lost), the cost of productivity lost would likely greatly outweigh the benefits of having antivirus software installed. I'm assuming, of course, that every user needs every bit of their computer's computing resources to perform their job. This may be a false assumption, but it helps to clarify my argument and lets you know where I'm coming from.
2. It's, of course, no fun for an organization to have to run recovery on hundreds (possibly thousands?) of workstations a year because of user error, but how much productivity is lost - on both the user's end and the IT support staff's end - when local admin access is taken away and users have to either make due with an uncomfortable limited set of tools that are pushed down on them or wait for IT staff to approve and install software for them on their computer?

The connection between Douglas' recommendation and the argument about the cost of some IT policies that I just made may not be obvious. To me, however, there is a direct correlation between the two in the form of the thought process that brings each (Douglas and those who make IT policy decisions) to the conclusion that security trumps all. Where's the connection? Well, Douglas is assuming - much like the federal government in the examples given above - that security trumps productivity, and, because of this, it seems like he is willing to limit a user's productivity and/or freedom to protect a very small amount of users that might someday become a victim because of vulnerabilities caused by JavaScript/Flash/Silverlight. [Note: I say "seems like" because I am making an assumption, based on Douglas' blog entry, that this is how he feels. This is an assumption because he doesn't flat-out say that he feels this way, though I think that this can be inferred].

I truly believe that the effect of a lot of these policies - which are certainly valid, especially if the policy makers are looking at the formulation of their policy solely through a "security lens" - if weighed against the quantified loss of productivity in the workplace, would be thrown out in a heart beat. The question is, how much of a threat really exists from allowing JavaScript and other executables to "run free" in a browser? And, if quantified and compared with the loss of productivity that would come from everyday users having to deal with the complexity of allowing or not allowing JavaScript to run in their browser, would a "No Script" policy still be as attractive (or even a viable suggestion)?

In short, let's be realistic here. JavaScript and Flash are an integral part of today's web. Turning them off by default on every browser will never happen and would be a bad thing for developers and users alike. That said, Douglas is right, though, in saying that there has to be a plan: "In the long term, I want to replace JavaScript and the DOM with a smarter, safer design. In the medium term, I want to use something like Google Gears to give us vats with which we can have safe mashups". I certainly agree, but I disagree about the short-term. JavaScript is here to stay (at least until something like it, but better, comes along), and, although it may not be the safest option, user's aren't going to rush out and turn off JavaScript in their browser.

This news comes from Hannes's Virtual Earth Blog.

Microsoft has just released several new features into the Virtual Earth API, allowing developers to further enhance their Virtual Earth map control v6 applications:

1. It is now possible to import 3D collections into VEDataType.VECollection.
2. It is now possible to import KML and GPX data into VEDataType.ImportXML. This is obviously great news. We can now consider using KML as a data standard for our organization.
3. Localized driving directions can now be accessed through the API by adding the market you're interested in (en-us for the United States) to the end of the map control URL (e.g. http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6&mkt=en-us).
4. SSL support has been added for the Virtual Earth map control (https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6). This may not sound like a huge enhancement, but support for SSL is a huge need for enterprise customers. It is a major pain when developers have an SSL-secured application but their users get security warnings when browsing to a page that has an embedded map. I have heard much grumbling among users of the Google Maps API that including SSL support doesn't seem to be a priority for Google. Maybe this is just another demonstration that Virtual Earth is becoming the standard for mapping in the enterprise?

As I'm sure most of you already know, Microsoft's recent (October 15th) release of their new version of Live Maps is getting a lot of attention. While I'm as excited as everyone else about the new features, I'm much more interested in getting at these features through Virtual Earth's JavaScript map control. Well, I decided to take some time today to update one of my web map applications to the new version of the map control. Here's a rundown of my experience, including what I'm most excited about:

After switching to the v6 map control (http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6), the first thing I noticed was the new control. It's the same one that Live Maps uses. I must say that I really like it; It takes up less space, has nice transparency, and the ability to contract and expand it adds a lot to the overall experience.

However, immediately after noticing this I noticed a couple of problems with my application that required my attention:

• None of my GeoRSS data were showing up. After looking into this, though, I realized that my JavaScript was incorrect (due to a hack), and - after a few simple changes - everything was back up and running. It's strange that the v5 map control let my errors slide, but I'm assuming that there must have been a fix in the underlying JavaScript that invalidated my code.
• My custom icons were not displaying. This was, again, because of a workaround that I implemented in v5 of the map control. After going back and correcting a couple of things (read: making them conform to standards), this problem was taken care of.

And that's it! Those were the only problems that I ran into with the switch to the new map control, and both were necessary because of workarounds that I had to implement in v5 of the map control. I must say that I'm impressed with how easy it was. The upgrade from v4 to v5 was much more painful, but it looks like those painful changes are starting to pay off in time and effort saved now.

Some fixes that I've already noticed:

• The SetCenterAndZoom method seems to be working correctly now. In v5 of the map control, it was inconsistent and I had to revert back to setting the center and then zooming to a point with two different methods.
• Like in Live Maps, the 3D map control works *much better than it did in the v5 release. The overall experience is much smoother (especially in Firefox), and the data are looking better than ever.
• It looks like the CSS has been touched up a bit, as well. With the v5 map control (and a couple of map control releases before it) the info boxes often showed up unattached to a particular point when hovering over the point in Internet Explorer. My workaround required creating my own custom info boxes and turning off Virtual Earth's. Hopefully I'll be able to abandon this workaround now.

Some enhancements to the SDK that I'm excited about (for a complete list, see the version changelist):

• VEAltitude Enumeration - Gives developers the ability to find the altitude of any point on the globe.
• VEMap.GetDirections Method - Allows for multi-point routing. This is a great addition.
• VEMapStyle Enumeration - Added the "Shaded" value. It was possible to get to this in v5 of the map control, but it is now accessible through the LoadMap and SetMapStyle methods.
• VEMatchConfidence Enumeration - Gives developers access to the accuracy of a returned geocode. This is an extremely useful feature that Google's geocode service has had since its 2.59 release. Microsoft still isn't as far along as Google on this one though; they only return three possible values (High, Medium, and Low), whereas Google returns nine values (0 being the least accurate (unknown) and 8 being the most accurate(address level)) and even gives developers access to "failure reasons", making it possible to let the user know why his/her geocode failed. That said, with this VEMatchConfidence Enumeration and the VEMatchCode Enumeration, Microsoft is moving in the right direction.
• VERouteOptimize Enumeration - Allows developers to specify how a route is optimized. The options include Default (no route optimization is done), MinimizeTime, and MinimizeDistance.
• There are also a handful of new 3D methods. It makes a lot of sense for Microsoft to continue to focus its resources on furthering Virtual Earth's 3D capabilities, as these capabilities are what really set it apart from the rest of the pack.

A random observation:

• It looks like disambiguation is now turned off by default for the geocode service. When I searched for "Denver", I was taken straight to Denver with no other options presented to me. With v5 of the map control, I was always asked if I meant "Denver" the city or "Denver" the county.

All in all, I'm very impressed with this release. There are enough new features to get me excited, but I'm just as excited about some of the fixes. As I continue to work with this new version of the map control, I'll post about my experiences here.

Note: This is the third entry in a series of posts titled "Web Mapping Offerings Compared". Here's the table of contents for this series, up to (but not including) this post:

• Introduction
• What I'm Looking For in an API

I will update this table of contents as the series of posts progresses.

The following "Section Introduction" blurb will remain the same for all of the web map APIs that I'll be reviewing. I was initially going to combine all of the API reviews into a single post, but the amount of information was overwhelming for me, and would have been even more overwhelming for you (as there's no way that I could present it all as a single post in any sort of cohesive or digestible way). At the end of this "APIs Reviewed" section, I'll provide a summary of all the APIs that I've reviewed. I'll also provide an overall summary at the end of this series. Once I move on to the next phase in the series, you'll know, as the post number will change from 3a, 3b, 3c, etc. to 4.

I've chosen to use a grading scale for each of the APIs and products, as this will help me quantify and display all of the information when I close out this series. Do note, however, that I'm using a pretty generic scale (A, B, C, D, and F), and that the point of this series is not necessarily to choose the best product, as different products meet different needs. My goal, rather, is to present a review of each of the options and hope that someone can garner enough useful information from the series to make an educated decision to support whatever project they're working on.

Section Introduction

Now that we've established some ground rules and laid out exactly what I'm looking for in both a web mapping product in general, and an API specifically, we can move on to looking at the individual products themselves. Like I mentioned and outlined in post number 2 of this series, What I'm Looking For in an API, I'm going to evaluate each of the APIs based on a set of predefined criteria. Just in case you missed it (or don't want to go back and read it, although I do suggest that you start at the first post, Introduction, if you're just joining the discussion), here are the criteria:

• Type, Breadth, and Quality of API(s)
• Accessing Data/Services (Licensing)
• Quality of Base Data
• Built-In Features and Data Support
• Ability to Integrate with a GIS

ArcWeb Services

If you read my write-up on this year's ESRI User Conference, you'll know that I wasn't paying all that much attention to ArcWeb Services before I attended one of the development team's technical sessions at the conference. It's not that I'm biased against ESRI; I work with their products every day. I just wasn't aware of the breadth of the APIs that they offer to help developers hook into their services. [Aside: Maybe this lack of clarity about ESRI's product line is an indicator that they [ESRI] need to work harder on educating their users on their different products (sounds a lot like Microsoft, eh?). I do understand that ESRI is currently in a transition phase, moving more towards services on the, well, server side, but I'll tell you now that there quite a few ESRI users out there who are totally confused about the difference between ArcGIS Online, ArcGIS Explorer, ArcWeb Services, and ArcWeb Explorer. And I'll be honest, it's still a bit confusing for me. Just a little bit of education, in this case, could go a long way.] That said, after I attended the technical session at the User Conference I was excited to start experimenting with ArcWeb Services. The enthusiasm of the development team was contagious; you could tell that they both believe in and enjoy working with the technologies that they are developing.

As for researching/experimenting with ArcWeb Services, you'll find all the information you need on the website, located at www2.arcwebservices.com/v2006. Browsing through the content made me stop and think to myself, "Why can't all the ESRI websites look this good and work this well," and I'm not exaggerating. The site is easy to navigate and full of helpful and informative resources, especially for developers. ESRI should take their example and implement a number of much-needed changes on the overarching ESRI Developer Network website. The developer section of the site contains an interactive SDK, much like the one that Microsoft maintains for the Virtual Earth JavaScript API. These interactive SDKs are remarkably helpful, as they put real-world working examples in the hands of developers and allow those who are just getting into working with the product to view the capabilities before they get in too deep.

Unfortunately, though, the site does have one major weakness: Most of the "Showcase Applications" that are up on the site don't impress. Some of them don't work (example: WebFOCUS demo), while others work, but not well. Take a peek at the "Routing Application" showcase demo, http://mapapps.esri.com/aws_routing/index.cfm?ffa=showRoute. How does that help ESRI's ArcWeb Services cause? If I were ESRI I would have some killer applications that demonstrate the full capabilities of ArcWeb Services up on the site. If they want to compete in the battle that's ongoing *today, they need to demonstrate that their product(s) can provide the capabilities that their customers are looking for. There are a couple of demos that do have some potential, though, including the ArcWeb Explorer 2.0 beta demo (if you want to take a look at it, you need to first logon with your ESRI Global Account - http://www1.arcwebservices.com/v2006/labs/awx2_lab.do) and the very-promising SVG Viewer (http://apps.arcwebservices.com/svgviewer/map.html).

It isn't all bad for ESRI, though. Actually it's far from it. In addition to the well laid out website, ArcWeb Services provides quite a few capabilities that the other vendor's APIs don't. And for many organizations that are already standardized on the ESRI platform, one or more of the APIs might fill a critical niche in their existing architecture. As the ESRI folks have stated over and over, the product certainly looks to do something different than ArcGIS Server. For purposes of licensing and cost for organizations, though, it would be nice if all of the functionality were blended into a single product. I'm getting *way ahead of myself, though...

Type, Breadth, and Quality of API(s)

Grade: A

ESRI, through ArcWeb Services, gives developers multiple options for connecting to their services. The available APIs include JavaScript, J2ME (mobile), OpenLS (wireless web services), REST, and SOAP, covering the whole array of needs and beating most of the other service providers in amount of options. All of these APIs allow developers, and organizations, to move towards a service-oriented architecture that is focused on a number of different platforms, which, as we all know, is all the rage these days.

Not all of the APIs that are available contain the same level of functionality, however. ESRI has published a matrix that shows the different services that are provided for each of them. To summarize, the SOAP API has the most functionality, followed by the JavaScript API and then the other three (J2ME, OpenLS, and REST). Here's a brief description of each of the APIs, in order of most functionality provided to least functionality provided:

• The SOAP API allows developers to build applications using their language of choice and interact with advanced geocoding, mapping, reporting, and routing services. If you need a full-featured mapping application, you'll probably want to use the SOAP API.
• The JavaScript API is designed for developers who want to customize ArcWeb Explorer, ESRI's Flash-based mapping application. If you're looking to quickly build and deploy a fairly-powerful mapping application, this may be the way for you to go, although you won't get access to nearly as much advanced functionality as you would if using the SOAP API and building your own app from scratch. Through the JavaScript API, however, you can access some of the more advanced built-in geocoding and mapping functionality that is exposed through ArcWeb Explorer.
• The REST API is another way to quickly and easily build and deploy an ArcWeb Services-based mapping application. This API is designed, however, only for use in mapping applications where only fairly simple tools and features are needed. The REST API does not support geocoding, routing, or querying, and only has limited mapping capabilities.
• J2ME (mobile) and OpenLS (wireless web services) are both designed for specialized-use cases, and contain some decent mapping, geocoding, and routing capabilities. These APIs really fall outside of the purview of this review, but are definitely worth mentioning, as they fit a niche that few other vendors are currently targeting. As mobile technologies become even more prevalent than they are today (and they are already a huge piece of the geospatial field), we'll likely see more of the online mapping vendors releasing APIs that specifically target mobile/wireless devices.

As for the specific services that are provided through these APIs, ArcWeb Services really rises to the top when compared to the other vendors. The services that they provide include "Create a map", "Locate addresses", "Locate a number", "Upload & manage data", "Generate a report", "Find features", and "Create a route". A basic authentication service is provided for all of the APIs except the JavaScript API (although this can always be built into the web server). The inclusion of this *very important service also sets ArcWeb Services apart from the rest of the pack.

Accessing Data/Services (Licensing)

Grade: D

Licensing is actually ArcWeb Services' weakest point when compared to the other APIs. Unlike most of the other large online map vendors (which I'll, of course, discuss in detail in the upcoming posts), ESRI does not allow their services to be accessed for free up to a certain threshold in pubic-facing applications. Basically, unless you're building an application for a non-commercial and non-governmental cause (which would allow you to use ArcWeb Services - Public Services), if you're using their services, you're paying. And on top of this, ESRI seems to charge more in 'credit' than the other vendors for some of the services that they offer, including some of their non-US geocoding and routing services. Note that I say "seems to charge more in 'credit'". This is because it's a bit unclear as to how much requests to some of their services cost. They suggest using their "Credit Calculator" to find out how much a specific transaction costs. After doing so, however, there is still some uncertainty.

For example, telling the "Credit Calculator" that I want to call one of their standard imagery map services tells me that 1 transaction gets me up to 40,000 pixels, 6 transactions gets me up to 360,000 pixels, and 16 transactions gets me up to 1,000,000 pixels. While having these numbers certainly allows me to roughly calculate the amount of transactions an average user will consume in any given application (although GIS users, as we all know, often have ridiculously large monitor(s)), using a flat transaction rate for all non-mapping services (e.g. geocoding, routing) would make it much easier to estimate. It would really make a lot of sense for ESRI to look into implementing a flat transaction model like most of the other major service providers, as this would take the burden off of the developer. In short, in my opinion this licensing scheme is *way too complicated. While it may be the most efficient way for ESRI to track and charge for use of its services, it makes it difficult for developers to plan for cost which, in turn, makes it difficult for organizations that don't have unlimited resources to commit precious resources to the platform.

Speaking of developers, you'd think that this "stinginess" wouldn't apply to them, as well, right? I mean, it makes a lot of sense to try and get developers onboard, as they can then present their findings and recommendations to their organization's decision-makers. Unfortunately though, ESRI doesn't offer a lot to developers in the form of credits to use when working on an application. They do offer a free 90-day or 5,000 credit (whichever runs out first) evaluation. After that, however, any development that is done has to use a live account, which means that you have to purchase at least 100,000 credits to develop with. In my opinion, you should be allowed unlimited transactions for an application that is under development, then, when it goes live, you start paying per transaction. This is another major weakness in the licensing scheme for ArcWeb Services. [Aside: The "Understanding credits and costs" section of the ArcWeb online help throws another complication into this licensing mix, a complication that I can't, for the life of me, understand: "You purchase credits, valid for one year, in blocks of 100,000." Why ESRI has decided to allow credits to expire after a year, I don't understand. If I purchase credits from them, shouldn't I be able to use them all, even if it means that I don't use them until two years after they were purchased?]

While all of this "stinginess" may, logically speaking, make sense - as ESRI doesn't have the infrastructure of the larger online vendors like Google, Microsoft, and Yahoo! and they are offering more in the services that they provide than their competition - it hurts them tremendously when compared to the other available offerings. I'm afraid that their current pricing and licensing model is going to restrict use of ArcWeb Services to large organizations that have a large amount of resources dedicated to building and supporting their mapping projects. ESRI is going to have to overcome this major shortfall if they want to remain a viable choice in today's increasingly-competitive market.

Quality of Base Data

Grade: C

Here are the sites that I'm going to use to check the quality of the base data. Note that I'm putting more of an emphasis on rural areas, as 1) almost all of the vendors have high-resolution imagery for the major metropolitan areas, and 2) a large part of the lands and resources that my organization manages falls outside of the major metropolitan areas. Also note that this is *obviously not a definitive or even methodical comparison; I'm just zooming into the same sites as far as the vendor's interface will allow (usually restricted by the level of the tiles that have been cached on their tile servers) and comparing what I see. I am, though, consistently using the same computer and monitor to view each of the images, so the screen resolution and color (of the captures) should stay relatively consistent. I am also not taking into account when the photos were taken, as it is difficult, if not impossible, to get this information most of the time. The captures should, for the most part, speak for themselves:

1. Sloan Lake - Denver, Colorado
2. Fontana Dam - Tennessee
3. Grand Canyon Village - Arizona
4. Appomattox Manor - Hopewell, Virginia
5. Wright Brothers National Memorial - North Carolina 

1.  2.  3.  4. 5.

I do want to explicitly mention one thing that I noticed when checking out ArcWeb Services' data: The "hybrid" and "street tiles" layers don't have very helpful labeling. Sure, they have the roads labeled, but they don't have many places labeled. Just something to keep in mind as we walk through the rest of the data services that are available.

The title of this section, "Quality of Base Data", really kind of implies, indirectly (if you're looking hard enough) an assumption: That all of the APIs I'm going to be reviewing allow access to only "base" raster data (aerial imagery, a road network base layer, and maybe a hybrid layer that combines the aerial imagery with the road network base layer). Well, this assumption holds true for the overwhelming majority of the data services that are currently out there; while all of them have some support for user-generated vector layers, for the most part they limit the data services that they provide as part of their product to pre-tiled raster data, which is why their layers can perform so well when compared to a dynamic mapping application that often grabs data from a database. ArcWeb Services does things a bit differently. See the next section, "Built-In Features and Data Support", for more information about the data that can be used in ArcWeb Services.

Built-In Features and Data Support

Grade: A

ArcWeb Services has some great built-in features, such as the ability to get granular with your queries (spatial and tabular), map widgets to help with navigation, print support, reporting functionality, and the ability to automatically switch to a better data service if you navigate outside of the boundary of your current data service. This plethora of available features undoubtedly comes from the abundance of APIs that ArcWeb Services offers. If you just look at the JavaScript API (the API that all of the different vendors seem to offer), however, you'll see that ArcWeb Services compares *very favorably to its competition. Just the fact that the ArcWeb Services JavaScript API supports working with group layers and toggling layers on and off sets it apart from the rest. Sure, it is possible to do these types of operations with most of the other APIs, as well, but ArcWeb Services makes these kinds of features available with little or no custom programming needed. Users who don't have a background in JavaScript can still have an application up and running in no time.

As for data support, first of all, ESRI provides, as part of their ArcWeb Services package, one capability that none of the other vendors currently offers: They allow users to upload their data (at this time just shapefiles and DBFs) directly to ESRI servers and then access them through the APIs mentioned above. This capability, coined "ArcWeb Content", is one that has been needed for quite some time. It gives developers the opportunity to piggyback on the hardware/network infrastructure of ESRI and get (theoretically) the same level of performance from their own data as they get from the data served by the larger vendors. It also allows for data to be easily enabled as a service and accessed through ArcWeb Services' APIs. This is obviously an intriguing prospect, and it will be interesting to see what kind of buy-in ESRI gets from large organizations that have historically built and administered their own infrastructure.

On top of this ability for users to upload their own data, ArcWeb Services also includes data services from a large number of "publishers", including ESRI, GlobeXplorer, the National Geographic Society, TeleAtlas, and the USGS. For a list of all the publishers, and more information on the services that each publisher provides, you can go to the publishers section on the ArcWeb Services support site. These services can be consumed through the APIs, and are doled out on the transaction model mentioned in the "Accessing Data/Services (Licensing)" section above. And perhaps most importantly, the attributes of these services can also be accessed via the APIs, making it easy to perform advanced attribute and spatial queries and symbolize based on attribute values.

Ability to Integrate with a GIS

Grade: A

As I mentioned in the What I'm Looking For in an API post, the ability to integrate with an established GIS is an absolute necessity for any API that the organization I work for considers using. We, like most other organizations that have been using GIS for a long time, have invested a lot in our current infrastructure and data, and need to know that moving in another direction isn't going to break our existing investment(s). Now I'll take one step back, though, and say that if investing in a new technology or set of technologies can dramatically improve the services that we provide, we will always consider it, weighing the cost(s) of adoption against the benefit(s) of adoption.

In the case of ArcWeb Services, however, this issue is really a no-brainer. We are already standardized on the ESRI platform, and ArcWeb Services certainly fills a niche that is currently missing in our enterprise architecture. The promise of integration of ArcWeb Services' APIs into the ArcGIS Server product (maybe starting with the 9.3 release and its JavaScript and REST APIs?) also bodes well for its ability to plug into some of our current production applications in the near future.

There's more to being able to integrate into a GIS, however, than just fitting into the current architecture of an organization. As hard as we might try, fitting some technologies that were never intended to be used as a part of a true GIS into a GIS may never be possible. ArcWeb Services, however, again fits the bill rather well. As mentioned above, true GIS data can be used in applications built with ArcWeb Services' APIs. There is no need for my organization to migrate our data out of its current format and into a more generic (and likely more simplistic) format; we can use it as is. This is a huge benefit for our organization, as I'm sure it will be for others that have invested lots of time and money into building an ESRI-centric GIS, and the ability to access these data through advanced attribute and spatial queries and symbolize them based on their attributes is something that most of the other vendors just don't offer.

In addition to this, ArcWeb Services is a true GIS implementation of web mapping. It isn't simply focused on the "wow" factor, but, rather, works hard to support important GIS functions. For example, the SOAP and REST APIs allow developers to deal with projections. If you didn't follow my link the first time I mentioned the SVG viewer, you might want to now. Once there, if you click on the "Projection" button, you'll see this projection support. Another "GIS-centric" feature that most of the other APIs are missing is the ability to create high-quality thematic maps based on associated attributes. With ArcWeb Services this is fairly trivial.

Conclusion

Overall Grade: B

All in all, ArcWeb Services - as a whole - is a great product. While it may seem to be competing with the other larger online mapping vendors, in reality ESRI (with ArcWeb Services) is striving to meet the needs of its GIS community first and foremost. This becomes clear when you start to look at the number of advanced services available and the quality of each of the APIs. The downside to having so many features integrated into the technology, however, is that organizations are going to have to pay more for the services than they would if they were using services from another vendor. This may be difficult for some to swallow, especially if they've already invested in a full-featured web map product.

Bottomline: ArcWeb Services is an ideal solution for:

1. an organization that has not already invested in a mapping platform and is looking for an easy way to build high-quality and high-performing, yet still fairly simplistic, web map applications; or
2. an organization that is looking to consume more data services than just high-resolution imagery and streetmap; or
3. an organization that is heavily invested in ESRI and is looking to fill the niche in their web map infrastructure that ArcGIS Server doesn't fill.

A quick followup to a post I made a couple of weeks ago about "Improving a Web Application's Page Load Time and Responsiveness": Thanks to Omar Shahine, I just discovered Yahoo!'s "Thirteen Simples Rules for Speeding Up Your Web Site". I linked to the Yahoo! User Interface Blog in my performance blog post, but failed to mention the Yahoo! Developer Network (YDN).

The YDN is another great resource for web developers. It provides tons of helpful tips and real-world examples to help developers build better web applications. The Yahoo! User Interface (YUI) library is probably my favorite resource that the YDN provides.

The YUI is a set of CSS libraries and  elegant JavaScript controls that are made available under the BSD license for all to use. The JavaScript outperforms the controls delivered with Microsoft's ASP.NET AJAX control toolkit (I know, in a way it's kind of like comparing apples and oranges, but I'm talking about quality here), and the documentation and community that support the controls are both organized and helpful. Over the last couple of months, I have made it a practice to include the YUI "core CSS foundation" in all of my web applications, as they make developing standards-compliant and consistent websites *much easier. If you didn't know, all browsers have their own built-in CSS quirks that, if not neutralized, can make web design a very frustrating process. If you include YUI's "core CSS foundation" in your application, these quirks are neutralized from the beginning, meaning that you can truly start developing (building) on level ground.

Another cool YDN resource that I just discovered is the "YSlow" Plugin for Firefox. It integrates directly with my favorite Firefox web development add-on, Firebug, and is an extremely helpful way to judge how your website lives up to the "Thirteen Simple Rules" mentioned above. After using it to analyze this site (nateirwin.net), I know that I definitely need to spend more time optimizing it (as I've known for quite some time), and I'll try to make this a higher priority. The site is scheduled for a complete overhaul here in the near future anyways, so maybe I'll wait until then.

Well, I could sing YDN's praises all night, but I'll save that for a dedicated post later on.

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.