[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Web Map Service



John Caron wrote:
 ----- Original Message -----From: "Jeff de La Beaujardiere" <address@hidden>To: <address@hidden>Sent: Thursday, May 16, 2002 10:52 AMSubject: Re: New Catalog XML Draft >
> # John Caron wrote:
> # > c.. add new service types: (DODS | ADDE | NetCDF | Catalog | FTP
> # >         | OpenGIS | WSDL | Other) .
>
> I agree that instead of OpenGIS you need explicit WMS, WFS, etc.
>
> Joe Wielgosz writes:
> # How much effort should THREDDS put into supporting particular data
> # provider site layouts?
> # [...]
> # If you look at different data providers websites, they all have their
> # own way of mapping datasets, collections and access methods to URLS, and
> # some are quite complex. They might use any combination of different base
> # URLs, subpaths or suffixes, CGI parameters, or who knows what else.
>
> The OpenGIS services (e.g., Web Map Service--WMS) list a URL prefix for
> each operation supported by a particular machine. The prefix includes
> hostname and, as needed, port number, path, and some CGI parameters.
> The entire prefix is just an opaque string. Then, the specification
> says what parameters are to be added to the prefix in order to
> construct a valid request for each operation.
>
> Examples for WMS:
>
> URL prefix:
> http://globe.digitalearth.gov/viz-bin/wmt.cgi
>
> Complete URL to request service metadata:
> http://globe.digitalearth.gov/viz-bin/wmt.cgi?request=GetCapabilities
>
> Complete URL to request a particular map:
> http://globe.digitalearth.gov/viz-bin/wmt.cgi?request=GetMap&layers=RTOPO&styles=REFPIXEL&srs=EPSG:4326&bbox=-180,-90,180,90&width=512&height=256&format=image/gif
>
> In the last example showing the GetMap request, most of the parameters
> are variable. I'm not sure whether in the THREDDS catalog it is best
> to include only the URL prefix and let the client form a valid GetMap
> request, or include one of the possible complete GetMap URLs so that
> all clients can at least retrieve something while WMS-aware clients
> can modify the URL. Probably the second, more helpful option is best
> in this context.
>
> -Jeff DLB, WMS 1.1 EditorThanks for the concrete example (nice picture, too!). A few questions: Can one figure out all the possible parameter values from the WMT_MS_Capabilities document?Does the WMS spec allow the client to specify the projection ?In the specific example above of the topo map, can the client specify/discover what the false color mapping is?


John,

  I'm not convinced providing a fully-qualified URL to any of the
services listed in a THREDDS catalog is a good idea, even as
an example.   It begins to expand the scope of what information
the catalog is meant to provide, and the types of client applications
using it.

Answering your questions, as I interpret the WMS spec.:

1: Can one figure out all the possible parameter values from the
    Capabilities XML ?

Yes, though clients are not required to be able to understand
a particular server's VSPs, in which case default values
must be provided by the server.   To the extent that the server
and client operate at a compatible revision level, all request
parameters should be discoverable by the client using the
capabilities XML.

2: Does the WMS spec allow clients to specify projections?

Yes, though the client can only request an SRS which has
been advertised for the requested layer.  The client is not
allowed to request an SRS which has not been advertised
for the layer.

3:  In the example can the client specify/discover the false
     color mapping.?

The server may provide through a legend element such
information, though it's not required to.  I'm not sure if
the styled layer descriptor (SLD) provides a similar
function.   There isn't a mechanism that I'm aware of
which would allow the client to specify the false color
LUT, though the server may provide multiple stylizations
for a particular layer, each of which is a similar visualization
using a different pseudo-color LUT.

    Dan


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.