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.

I've run into this problem several times before, but have always forgotten to document it. Because of this, every time that I get to work setting up a new development environment and then try to compile an ASP.NET 2.0 application that sits on a network share, I have to relearn my lesson. Well, this time I'm going to stick this tidbit of information here, in hopes that I'll remember it next time I go through this, and I hope that it helps someone else out there, as well.

Basically, the issue pops up when you try to compile an ASP.NET 2.0 application that lives on a network share in Visual Studio 2005. Here's the error: "ASP.NET runtime error: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."

The AspNetHostingPermission Class protects public types in the System.Web namespaces. If you're developing, you can set the trust level on your development machine and move on. If you need to access these public types during runtime, you'll need to change the trust level in your application's web.config. By default, the AspNetHostingPermission is only assigned to applications that are running under Full trust.

Luckily, the fix is simple (once you find it). On your development machine, open up the Microsoft .NET Framework 2.0 Configuration utility, either by getting to it through the "Administrative Tools" section of Control Panel or through the "Administrative Tools" link on your Start menu. Note that if you don't have "Administrative Tools" installed, you can download it from Microsoft. It's included with the Windows Server 2003 SP1 Admin Pack.

Once into the Microsoft .NET Framework 2.0 Configuration Utility, click the "+" next to "My Computer", click on "Runtime Security Policy", and then click on "Adjust Zone Security" underneath the "Tasks" section in the right-hand pane. In the "Security Adjustment Wizard" dialog, verify that the "Make changes to this computer" radio button is selected and click "Next>" to advance in the dialog. Select "Local Intranet" from the top pane and move the slider on the bottom up to the very top, or "Full Trust". Click "Next>" and then finish to verify and submit the change. If you still have Visual Studio 2005 open, you'll need to close it and reopen it. Recompile, and you should be good.

Thanks to Jason Gaylord's blog entry for pointing me (back) in the right direction.

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.

Tonight I was almost at a breaking point with my newest Windows Vista Ultimate home installation. I've had it installed on my main machine at home for about a month now, and everything has worked flawlessly. Vista Ultimate x64's performance has been more stable and better than XP x64 running on the same hardware. I never ran into any driver issues (which seems to be a common complaint for those who try to run any 64-bit operating system, and especially for those who try to run Vista x64), and never had any stability problems.

Then last night when I tried to boot it down, it hung. No biggie, right? Happens all the time (you can tell I'm a PC user). Well, when I booted back up today I noticed that one of my CPUs was constantly pegged even though there weren't any major processes running. Video performance was also choppy and I couldn't get any audio to play.

I tried everything that I could think of, including registry cleans, spyware scans, and antivirus scans (which forced me to install antivirus software on my machine, something I've been avoiding and will likely reverse here in the next few hours), but I couldn't find anything wrong with the machine.

Suddenly I remembered hearing about some upcoming batch fixes for Windows Vista. With the number of problems that these releases were claiming to solve, some pundits actually starting referring to them as "Service Pack 1" although Microsoft has publicly said that Service Pack 1 won't be released until the final release of Windows Server 2008, which is currently scheduled for February of 2008. After a little bit of searching, I read that these fixes had not yet been publicly released, but that they were available to private beta testers only. You'll understand, then, why I was pleasantly surprised to find links to them during a Google search. It looks like Microsoft just released them to the public today.

So I downloaded and installed them, and oh am I glad I did. After installing 938194 all of my problems disappeared. CPU activity was back to normal, the choppiness disappeared from video, and I got my sound back. I then installed 938979 and everything continued to work! Granted, it's sad that I have to be happy about fixes for problems that should've been fixed in one of the pre-releases, but my expectations at this point are fairly low when it comes to dealing with the behemoths of software. I'm just glad now when problems get acknowledged and fixed.

The point of this story? If you're working with Vista and experiencing video performance issues or really any other problems, I suggest downloading and installing the patches. They saved my night (although, luckily, I do have a recent image that I could've gone back to, if needed - something else that I highly suggest [see the Imaging section of my tools list]). Here are links to the fixes:

• Link to 938194
• Link to 938979

Happy patching!