Skip to main content

Alternate Layers as the web wobbles

Posted by jive on October 6, 2006 at 2:00 AM PDT

Alternate Layer data as the web wobbles

I enjoyed Matt Perry's post of href="">ten favorite
WMS services some months back, he is back today with a href="">nice
observation on (lack of) reliability. Many of the solutions
proposed in the comments focus on the service aspect of the problem ...

  • data replication
  • tacking status for a quality of service estimate
  • cache the results (ie tile schemes)
  • and the ever present request for metadata

Some of these are very attractive - a tile cache helps reliability and
performance for example. But something is askew with
these approaches ... the problem of service availability needs
be recognized and handled by those effected by it - the clients.

Client Solution One: Use more WMS Servers

One of the the things I noticed when meeting up with href="">GeoTango
(and most commercial offerings) is that they offer WMS support, but
never in isolation. When setting up their "basemap" layer they will
make use of several WMS services, often switching based on availability
and zoom level. This is not something I am doing currently - much to my
regret during a few demos.

This solution of ganging up on WMS Servers also provides a
solution to the Quality of Service "metadata" question. Rather then
track service performance brute force the problem. Make two requests of
different servers, the one that comes back first is the one you keep
(and obviously performing better that day). While such an approach
lacks finesse I can always appreciate the easy solution.

Client Solution Two: Sharing a Vision

As part of a recent project href="">uDig
was responsible for producing a common operational picture for disaster
relief. Mr Perry's original point is well taken that WMS services are
not reliably available for use this sort of situation.  But
is still an advantage to their use.  Because the various
involved are making use of standards to collect a shared vision, when a
service goes down one *can* make use of another.

In the OWS-3
project we automated the process of posting a "Open Web Service"
context document to a wiki page for use with other applications.
Needless to say that when most our services *did* go down (and they did
I was mortified) we were able to quickly build up and publish and
distribute a revised picture made up of working services.

href=""> style="border: 2px solid ; width: 266px; height: 200px;" alt=""

While this may be a case of fighting a standard with another standard
(almost the definition of an integration project), it was a great
example of being able to quickly respond to service availability and
demonstrate interoptibility under pressure and on the fly.

Building the a list of  "alternate" Open Web Services directly
into the OWSContext document would provide us the best of both worlds.

Client Solution Three: Get Tricky

Recently, under a bit of collaboration pressure, the uDig catalog has
started to get some attention.  We have finally defined an
extension point by which you can "associate" data sources together.
Being by definition a friendly application this extension points is href="">friendly.xsd
(yes I need to publish out the human readable version and write docs).

Implementations of this
net.refractions.udig.catalog.friendly will make use of a
couple kinds of "metadata":

  • prior knowledge: simple pattern matching can account for
    GeoServer and MapSever WMSLayer to FeatureType association
  • included metadta:  the description of a WMSLayer
    can point
    off to an external data URL, if we recognize that as a WFS link ...
  • external metadata :given an interesting CSW2
     profile to hit we can make use of associations tracked by a
    third party

At a implementation level this means that uDig now sees a small cluster
of data resources that refer to the same
content, allowing us to provide fail over as needed. While not as slick
as tracking data that is "good enough" or "similar" the first steps are
being taken.

What is Next?

So handling missing services is a well understood problem - that you
always need to take into account. For something really difficult we
need to look at the problem the other way around - how to handle a
missing client!

The difficulty with having your client lose the Internet is the aspect
of disaster relief that is most troubling for an open web
like WMS.  There are a couple of approaches to consider,
neither are available out of the box right now.

Stay tuned next time for the Low/No Bandwidth WFS story.