[OpenLayers-Trac] [OpenLayers] #1409: Autodetect image format for a WMS server

OpenLayers trac at openlayers.org
Mon Mar 3 04:00:31 EST 2008


#1409: Autodetect image format for a WMS server
------------------------+---------------------------------------------------
  Reporter:  manifold   |       Owner:  euzuro             
      Type:  feature    |      Status:  new                
  Priority:  major      |   Milestone:  Future             
 Component:  Layer.WMS  |     Version:  2.5                
Resolution:             |    Keywords:  wms getcapabilities
     State:             |  
------------------------+---------------------------------------------------
Changes (by crschmidt):

  * milestone:  => Future

Comment:

 OpenLayers will never ask for getcapabilities by default -- the majority
 of WMS-based OpenLayers applications use remote WMS servers with no proxy
 available, and using GetCapabilities would require working around the Same
 origin policy in some way. However, making it easier to request this type
 of behavior is not beyond the scope of OpenLayers. I can think of two
 different implementations:

 1. option on the layer to ask for getcaps for image format determination
 before sending request. This would mean that the layer could not be loaded
 until after this request was complete: I think the way to solve this (at
 least for non-baselayers, I don't know if it would work for baselayers)
 would be to set the visibility to false before attempting to load the
 getcaps, then setting it to true again after the information is fetched
 and assigned.
 2. OpenLayers.Layer.WMS convenience function for passing an OnlineService
 and a layername, and getting back the constructed WMS layer. THis could
 include support for multiple URLs (which I'm told WMS can describe).

 However, I don't think that either of these is neccesarily the right way
 to go: instead, I think we just want to write a WMS capabilities document
 parser, and leave the loading of this document and the creation of the
 layers from it up to the application. These convenience methods are going
 to be silly: OpenLayers layers must be configured by an application
 developer, and the application developer has to pull the information about
 the layer configuration from a datasource which has to include at least
 two pieces of information: url, and layername. Storing the format that the
 layer prefers along with this datasource does not seem sufficiently
 arduous that complicating the process by which layers are constructed in
 any way makes sense.

 In addition to the fact that this isn't solving a technical problem, but a
 social one, there's also the fact that parsing getcaps means additional
 load on the server which is unnecessary: Due to OpenLayers not having the
 ability to serialize data for later use, there's no way to parse the
 document once and reuse it again later. Instead, the document would have
 to be parsed each time the map was accessed: this is only going to cause
 unnecessary and visible delay to the user who has to wait for the WMS
 request to return before the map can start displaying tiles. I can't think
 of an application where this makes more sense than simply configuring the
 layer correctly when it is created.

 I could be wrong on this: I'd like to understand what I'm missing about
 how additional requests to the server are designed to improve the behavior
 of OpenLayers, or how the solutions I've described above don't adequately
 solve the problem.

 Since WMS Capabilities format is already targeted for 2.7, I believe, and
 I don't believe that pursuing these additions to the WMS layer is likely
 to be actively developed in the near future, I'm putting this in the
 future milestone. If someone wants to implement this, I suggest taking it
 to the mailing list first, as it is likely that at least some discussion
 of a use case would need to be worked out before code was written.

-- 
Ticket URL: <http://trac.openlayers.org/ticket/1409#comment:1>
OpenLayers <http://openlayers.org/>
A free AJAX map viewer


More information about the Trac mailing list