WMS GetMap GetCapabilities 参数详解
http://oceanesip.jpl.nasa.gov/esipde/guide.html
Online Viewer:
http://its.demo.galdosinc.com/wms/viewer/#
WMS source:
http://labs.metacarta.com/wms/vmap0
http://www2.demis.nl/mapserver/request.asp
Online sample:
http://openlayers.org/dev/examples/lite.html
http://trial.parcelstream.com/client/ver0_75/Samples/GoogleExternalWMSSample.html
http://wms-sites.com/catalog/Intergraph-US-sample-WMS/counties/
WMS 1.1.1
A Tutorial for Data Providers
By Rob Raskin, Ocean ESIP, Jet Propulsion Lab
http://oceanesip.jpl.nasa.gov/esipde/guide.html
(Last updated Jan 2004)
If you are already providing spatial/temporal subsets from a web server, then WMS-compliance is relatively simple. Compliance involves a minimum of absolute requirements, plus several optional services. To be compliant, you must be able to deliver the following products via HTTP upon request:
2) Metadata in an XML file (the GetCapabilities request).
You also must be able to deliver any error messages to the client in an XML file, in the event that either of the above requests are not satisfiable.
The first sections of this Guide detail the minimum requirements of WMS compliance. Later sections describe optional services that you may choose to provide beyond the minimum requirements.
A WMS server must be able to deliver a map via http upon receiving a client request such as the following:
http://www.airesip.org/wms/process.cgi?REQUEST=GetMap&FORMAT=image/gif&WIDTH=640&HEIGHT=480&
LAYERS=temperature&SRS=EPSG:4326&BBOX=-110.,40.,-80.,30.&VERSION=1.1.1
In this hypothetical example, www.airesip.org is the server hostname, wms/ is its directory path, and process.cgi is the name of the CGI script processing the client requests. You can choose the directory path and file names. A question mark is appended after the script name to separate it from the parameter list. The parameter list consists of parameter name=value assignments separated by a an ampersand (&).
Parameters may appear in any order. Parameter names are not case-sensitive; therefore, height=480 and HEIGHT=480 are identical requests. However, you may choose to interpret parameter values as case-sensitive. No spaces appear anywhere in the request string. A description of each parameter is given below:
REQUEST
The parameter REQUEST=GetMap indicates that this request is for a map.
FORMAT
You choose which output formats to support. Permissible image formats include: image/gif, image/jpeg, image/tiff, image/geotiff, image/png, image/ppm, and image/wbmp. Several public domain and commercial software packages for creating images from numerical data will be listed in a future version of this Guide. (Note that TIFF and GeoTIFF support floating point data types as well as 16-bit integers, although not all TIFF/GeoTIFF readers support these features.)
WIDTHand HEIGHT
You must be able to provide images in any requested size. These values will be requested as positive integers.
LAYERS
You choose which layers (variables) to provide and how they are named. You must be able to receive a request for multiple layers (e.g. LAYERS=temperature,coastline,cities). In this example, temperature is drawn first, coastline is drawn on top of temperature, followed by cities.
SRS
You choose the map projection (or spatial reference system) (SRS) in which to deliver your data products. The SRS is commonly expressed in terms of its European Petroleum Survey Group (EPSG) numeric code. The standard latitude-longitude grid (with equal-angle increments and degrees as units) has a code of 4326, and would be sent as SRS=EPSG:4326. Other EPSG codes are listed in http://www.epsg.org . Alternatively, the SRS can be expressed as a projection with user-defined parameters and units, known as an AUTO projection. AUTO projections are described in http://www.digitalearth.gov/wmt/auto.html .
BBOX
The bounding box request is sent by the client as integers or floating point numbers (in units of the specified SRS). These values correspond to the outer edges of the boundary pixels (not the center of the boundary pixels). The aspect ratio inherent in this request need not match the aspect ratio of the width/height request, so you must be able to "stretch" the image to satisfy both requirements.
TRANSPARENT
You must be able to provide a transparent background image if the user requests it (using TRANSPARENT=TRUE) and the format is one that supports transparency. GIF and PNG support transparency, but JPEG does not. Note that GIF89 (rather than GIF87) is required to implement this feature for GIFs. Transparency enables other maps to be overlaid. If this parameter is not present in client requests, its value must be set to false.
BGCOLOR
You must be able to set the background (or missing value) color to the specified hex string (e.g. BGCOLOR=0xFF0000) if a user requests it. If this parameter is not present in client requests, its value must be set to white (0xFFFFFF) .
VERSION
The current version is 1.1.1.Your server will need to either support all official versions or support a "client-server negotiation" to meet a client request. All versions are listed at http://www.digitalearth.gov/wmt/xml .
The purpose of the GetCapabilities request is to declare the GetMap services that you provide. You must be able to deliver an XML metadata file via http upon receiving a request such as:
http://www.airesip.org/wms/process.cgi?REQUEST=GetCapabilities&VERSION=1.1.1&SERVICE=WMS
The URL need not be the same as that for GetMap. Therefore, you could arrange for another server to provide this functionality. You must be able to provide any GetMap service that you declare in the XML file. This file is to be returned with mime type set to "text/xml".
REQUEST
The parameter REQUEST=GetCapabilities indicates that this request is for metadata (rather than a map).
SERVICE
The parameter SERVICE=GetMap indicates that capabilities are being sought for a GetMap request.
A sample XML metadata file is shown below:
Lets look at some of the key parts of this file. The first three lines are header lines:
The first line identifies the code as XML. The second line gives the URL for the Document Type Definition (DTD) file. The DTD file is used to validate that your XML code has the correct structure. The third line provides version information, including an "updateSequence" number that is normally incremented every time a change has been made to the Capabilities file. This enables cataloging systems to determine quickly if an update to a server's holdings has occurred.
Next are
The
The
The Layer tag may include several parameters.
opaque=1 denotes that the map is mostly space-filling (generally the case with raster data) and should probably appear at the bottom of a stack of images.
queryable=1 denotes that GetFeatureInfo can be invoked on it.
fixedWidth=xxx denotes that the map width is fixed to the specified value
fixedHeight=xxx denotes that the map height is fixed to the specified value
nosubsets= 1 denotes that only the entire bounding box is accessible
In most cases, your server will be providing more than a single layer (variable). Each layer is listed within its own
It is a requirement to enclose multiple layers in a single outer
If you offer the same dataset at multiple time instances, you will want users to include a "time" parameter in their call. This parameter can be specified in many posible ways; some common examples are:
TIME=1999-12-23
TIME=1999-12-23T20:15
TIME=1999-12
TIME=1999-01-01,1999-04-01,1999-07-01,1999-10-01
TIME=1995-04-22T12:00/2000-06-21T12:00/P1D
The first example is for data on a particular day (December 23, 1999). The second form is more specific, as it references a particular time (20:15 on December 23, 1999). The third form is less specific, as it references a particular month. The fourth form is a request for four specific days of data. The fifth form is a request for daily data (P1D refers to a period of one day) during the specifed time interval. See http://www.digitalearth.gov/wmt/time.html for further time options.
To use Time for your datasets, you must declare Time to be a "Dimension" in the Capabilitites file and then specify the time "extent" of the dataset. The following pair of lines are an example of what would be placed within a layer tag group in the Capabilitites file:
In this example, the data are provided every 5 days between 11/02/92 and 12/24/00. A default date is provided for those who do not specify a date.
If you offer the same dataset at multiple elevations, you will want users to include an "elevation" parameter in their getMap call. This parameter can be specified in many posible ways; the most common examples are:
ELEVATION=1000
ELEVATION=1000, 2000, 3000
ELEVATION=1000/5000/P1000
The first example is at an elevation of 1000 units. The second form is a request for three specific elevations. The third form is a request for every 1000 units between 1000 and 5000.
To use Elevation for your datasets, you must declare Elevation to be a "Dimension" in the Capabilitites file and then specify the elevation "extent" of the dataset. The following pair of lines are an example of what would be placed within a layer tag group in the Capabilitites file:
In this example, the data are provided every 2000 m between 0 and 8000. EPSG:5030 represents meters above the WGS84 ellipsoid. A default elevation is provided for those clients who do not specify it.
In addition to 3-D space and time, your dataset may have other inherent "dimensions" such as spectral bands. In such cases you can create and declare dimensions of your own. For example, spectral band might be requested using calls such as:
BAND=0.8
BAND=0.6,0.8,1.8
BAND=0.8/1.8/P0.1
The first example is a request for a spectral band of 0.8 units. The second form is a request for three specific bands. The third form is a request for every 0.1 units between 0.8 and 1.8.
To use this (or any other dimension) in for your datasets, you must declare each to be a "Dimension" in the Capabilitites file and then specify the "extent" of the dimension. The following pair of lines are an example of what would be placed within a layer tag group in the Capabilitites file:
In this example, the data are provided every 0.1 micron between 0.6 and 2.4 microns. Its default value is 0.8.
You may choose to allow additional parameters in a GetMap request that are specific to your server, such as the minimum and maximum values on the color bar associated with a plot. These parameters must be declared in the Capabilities XML file, inside the
Clients are never required to include such a vendor specific parameter value in their requests. Therefore, your server must have default value set for each of these parameters.
If your server is unable to satisfy the client request, it must be able to provide some response to the client, preferably with an explanation of the inaction. At a minimum, you must be able to return this error message in the form of an XML file. You also may choose to provide two other methods to convey this message. The three options are:
- (required) in an XML file (EXCEPTIONS=application/vnd.ogc.se_xml)
- as a message "painted" onto the returned image (EXCEPTIONS=application/vnd.ogc.se_inimage)
- as a last resort by returning a blank image (EXCEPTIONS=application/vnd.ogc.se_blank).
An XML response must have its mime type set to: application/vnd.ogc.se_xml . The response XML file would appear in the following form:
Text of error message
This option enables you to provide further information about a specific pixel in a previous GetMap request. You may choose to implement this service for any or all layers. The URL request resembles the GetMap request, but the user will also specify a single pixel. A typical request might be:
http://yourserver.ext/script.cgi?REQUEST=GetFeatureInfo &WIDTH=640&HEIGHT=480&BBOX=-110.,40.,-80.,30.
&VERSION=1.1.1 &SRS=EPSG:4326&QUERY_LAYERS=temperature&X=321&Y=165
Any layer that implements GetFeatureInfo should have its
REQUEST
The parameter REQUEST=GetFeatureInfo indicates that this request is for feature information (rather than metadata or a map).
WIDTH, HEIGHT, SRS, BBOX, VERSION, PARAMETERS
These are the same as in the GetMap request.
QUERY_LAYERS
Note the difference in the name of this parameter from the GetMap request. If multiple layers are being queried, they will be separated by commas.
X
The column number in the image where x= 0 is the leftmost column
Y
The row number in the image where y= 0 is the top row
INFO_FORMAT
You may choose the format in which to return the feature information, and this parameter can then be ignored.
FEATURE_COUNT
The user may choose to specify a maximum amount of information.
Your WMS server may provide maps in more than a single map style. The style names are of your choosing. Clients will send one map style for each layer requested in the GetMap request. Therefore if three layers were requested, this parameter might appear as STYLES=contour,contour,bold. If only a default style is provided, clients will send a null string (STYLES=) for this value. Styles should be declared within the
Additional tags can optionally be added for
The
The
There are several changes in WMS 1.1.1 relative to 1.1.0. Some of the important changes are listed below:
Name Changes
The "WMTVER" keyword changes to "VERSION", the service "capabilities" becomes "GetCapabilities", the service "map" becomes "GetMap", and the service "feature_info" becomes "GetFeatureInfo". Image formats are now recognized with a "image/" preceding the image name (e.g. FORMAT="image/gif").
SERVICE=WMS
This statement is now required in the parameter list of getCapabilitites calls.
Dimensions
WMS now formally recognizes "dimensions", with the dimensions "Time" and "Elevation" having special qualitites.
Exceptions
Exception names and defaults have been changed.
Formats
Formats are now listed indivudiually, each within its own
Acknowledgements: Helpful comments have been provided by Jeff de la Beaujardiere, Tim Rhyne, and Matt Lynch.
Send comments to mailto:[email protected] .