Home › Operational Review #8
Printer-friendly version Add This

Operational Review #8

  1. Describe in a sentence or two your overall operational experience related to WMS. (e.g., scientific visualization; geospatial visualization, etc). What kinds of WMS servers and/or clients do you have experience with? (e.g., commercial products, open source, or independent implementations, please provide as much detail as possible).
    • We have been using WMS in a variety of contexts for the last four years. This use has been in a variety of internal applications where WMS services have been established as data resources that are used as contributing data for online mapping client applications. In this context, with the exception of one past project, and a very recent application, these services have not been directly exposed to users, but instead have been consumed by our server applications as data sources for layers included in mapping applications. One exception to this model is an application that we developed where WMS was used to request dynamically updated vector datasets as maps that were embedded in a client application developed and maintained by a client organization. A second, recent, exception is the use of WMS as a service architecture for the delivery of live preview images for a multi-terabyte imagery dataset that was recently acquired over the state of New Mexico which we are publishing for delivery, and visualization. In this instance the WMS requests are embedded into a preview page and a metadata viewer as html IMG tags that include the WMS request in the SRC parameter for those tags.
    • Our WMS work has primarily focused on MapServer (http://mapserver.gis.umn.edu/), though we have also worked with ESRI's ArcIMS. Our experience with MapServer has been quite positive, with the support of MapServer as both a client and server providing excellent support for the use and publication of WMS services. This cascading WMS capability has worked very well for data service reuse, both within and outside the services we have published. Our work with ArcIMS (a couple of versions ago) provided some problems, particularly in the area of non-dynamic generation of WMS capabilities responses - a shortcoming that increased the maintenance costs associated with the use of ArcIMS as a WMS server. On the client side, we have primarily use MapServer as a WMS client and also developed basic web interfaces that embed WMS service calls in the web page, using the basic URL-based WMS request as a means of embedding dynamic map content in otherwise static web pages.
  2. What types of applications do you use WMS servers/clients for? Are they suitable for your applications? (e.g., Do they work well with the data types and data manipulations in your application?)
    • Our primary applications make use of WMS as a provision system for background imagery for a variety of web mapping applications. It has worked very well in this context - particularly for the types of imagery we are using: a wide variety of raster and vector data products, and a limited number of remote sensing data products. Since our applications currently focus on online mapping, the ability to dynamically specify layers, extents, and most recently time, the capabilities of the WMS specification have met our needs quite well.
  3. Why do you choose to use WMS over other protocols for your applications?
    • 1) The support of the specification by a wide variety of server and client applications
    • 2) The ease with which requests can be generated and managed (URL-based : HTTP GET)
    • 3) Availability of high-quality open source server applications
  4. Are the WMS systems easy to use? (e.g., Is it hard to learn how to use WMS systems?)
    • We have found WMS as a conceptually easy specification (though the details of the specification can be complex) that we have had great success in describing to project partners as an applicable data delivery model for a variety of applications. We have had two instances where our work with clients has resulted in their adoption of the WMS specification as a data visualization system that they continue to use in their applications to this day.
  5. Does the performance of the WMS systems you have experienced meet your requirements? (e.g., Does it take a long time to access/view data in WMS systems?)
    • The MapServer-based WMS services that we are using in multiple applications have proven to be quite responsive - even when performing reprojection on-the-fly, as is the case in the recently developed DOQQ preview application (e.g. http://rgisedac.unm.edu/cgi-bin/previewer.py?file=05_33104e36&collection=doq q05_ecw q05_ecw).
    • The greatest difficulty we have run into has not been based upon performance as much as on availability - it is quite easy to connect to a remote WMS service, but since many of these services are not established as operational systems, they are occasionally unavailable for use (usually when doing a live demonstration of a client that makes use of them).
  6. What operational challenges do the WMS systems present? (e.g., Does it require advanced processing power, large amounts of memory, complex configuration, etc.? Are the systems easy to deploy and maintain?)
    • The most significant challenge we have encountered is building a robust collection of metadata for the hosted WMS services to be able to provide complete and well-formed capabilities documents. This has not been excessively difficult, but it has been the most difficult WMS-related problem. As far as processing power goes, we have successfully run MapServer on relatively low-powered (by current standards) machines while still providing quite acceptable performance. Once running, our MapServer-based WMS services have been extremely stable and relatively maintenance-free, more so than our database and mail servers.
  7. How well do the WMS systems scale to large numbers of simultaneous users, or to large datasets?
    • The applications that we have developed and deployed have not catered to large numbers of simultaneous users, but we have built WMS services upon large datasets in the 500GB-1TB range with excellent performance. The sample preview URL provided above is accessing a collection of over 2200 individual 1m resolution DOQQs, currently totaling 430GB of data. The responsiveness of the system (based primarily upon optimizations on the underlying raster data files) remains very high. We have also developed statewide DOQQ WMS data services based upon over 8800 1m resolution DOQQs with similar excellent performance.
  8. Can you provide information on user statistics of your WMS systems? How have the user statistics changed over time?
    • Since we have primarily used WMS as an internal data provider, we have not collected usage statistics on the services directly, but instead on the applications that are making use of them. Since most of these applications have been developed as prototypes, that in some cases have been deployed at customer locations, we do not have information on the operational statistics for the use of these services. Our newly developed DOQQ preview interface is the most directy deployment of WMS services to date, but has only been operational for one month, once again leading to an absence of good usage statistics. In spite of this, we are expecting fairly heavy use of the WMS service to which the DOQQ previewer application connects because the Resource Geographic Information System (http://rgis.unm.edu) currently delivers between 100 and 500 GB of data / month in response to over 3000 requests /day for data, metadata, or preview images.