Surveying, Mapping and GIS

Haven't posted in a while - have had a number of projects keeping me busy. First and foremost is working on getting ready to move to our other house... some painting, carpeting, and other work going on... Add to this several other things that have been consuming bandwidth, such as some reorganizing at our office, a new computer (that still needs many things set up on it) and the upcoming elections...

But now the fun stuff - getting ready to embark on some upcoming web mapping projects.

Here, the dilemma was in how much of our project dollars we wanted to burn on mapping infrastructure. Customers were having a difficult time swallowing the 5-digit price tags and other baggage associated with ESRI products. As an alternative, a friend suggested ASPMap - which is a web mapping component that supports ASP and ASP.NET developed by VDS Technology.

I have been playing with the demo version, and am quite thrilled. At $449, it does quite a bit of what I want - multiple map layers, supporting ESRI Shapefiles, GeoTIFF, ECW; adjustable transparency of layers, scale-dependent renderers, thematic mapping, and ROUTING capability. My concern was in how robust the product is... I currently have a test application which has 6 layers and an ECW image, and the largest of the layers is 22MB, with a 19MB database file attached to it. Prior to loading, I generated a spatial index for the layer out of concern for speed, and after noting in the ASPMap documentation that it would use the indexes - the map images load up in milliseconds.

Great stuff... Now to see if I can also get some AJAX functionality working with the product. I am currently looking at msCross, which seeks to add Google-style AJAX functionality, along with WMS and WFS support to UMN Mapserver - can the same be done with ASPMap and other products?

In a recent blog post, Matthew Perry (PerryGeo) lashed out, reaffirming his reluctance to rely on spatial web services such as WMS. Given that the NASA JPL WMS server was evidently down, many users and applications which consume the JPL WMS services also had issues and outages.

Yes, certainly any distributed system can face issues with downtime, or worse yet, with services going away altogether. How to remedy this?

As a service provider, one of the things that providers can work toward is providing the users with some information with which the users can make informed decisions. Essentially, manage their expectations. In some arenas, particularly where commercial services are offered, this should be in the form of a formalized Service Level Agreement (SLA), as part of the contract.

Here, the provider can outline the parameters of the content itself (such as FGDC-compliant metadata, including accuracy, source, et cetera), and beyond each iterative data snapshot, provide information on data latency (how current is the data?) and how often will it be refreshed? From an infrastructure standpoint, some hosting parameters should also be set forth, such as availability and reliability - to set the ground rules on what kind of downtime is acceptable or unacceptable, what kind of data throughput can be expected, and so on.

This becomes a bit more of a challenge in other arenas, such as agencies where external budgetary, legislative and other pressures may impact how well an organization can support published services.

But nonetheless, if an agency is forthcoming and up-front with these constraints at the outset, it can allow its' users and stakeholders to plan and prepare accordingly - by writing their code to handle outages appropriately, by utilizing alternative services, and so on. It also can lead toward consolidation, augmentation, replication of valued services as external users and stakeholders lobby for support (via legislative initiative and budget) for these services. An agency might not be able to provide formalized parameters as a commercial service would be expected to, however providing users with some basic insight will go a long way.

As organizations gradually move more and more toward Service Oriented Architecture, and as variegated Web Services appear right and left, and increasingly become available lights-out, via a simple URL, it becomes increasingly easy to connect to and consume these services - however that ease of access and use is ultimately bound to cause some disappointment, when things change down the road. I suggest and recommend SLAs and service metadata toward managing expectations.