To be compliant with the WMS protocol, you must be able to deliver the following products via HTTP upon request:

1) User-selected spatial subsets (the GetMap request);
2) Metadata in an XML file (the GetCapabilities request).

The next two sections detail the specific requirements of these two requests.  Subsequent sections describe additional optional services that you may choose to provide.

Your server must be able to deliver a map via http upon receiving a client request such as the following:

http://www.airesip.org/process.cgi?REQUEST=map&FORMAT=GIF&WIDTH=640&HEIGHT=480
&LAYERS=temperature&SRS=EPSG:4326&BBOX=-110.,40.,-80.,30.&WMTVER=1.0.0

This example request obeys the usual HTTP CGI rules: parameter names are assigned parameter values, an ampersand (&) separates parameters from one another, and the question mark (?) separates the web address from the parameter list.

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=map indicates that this request is for a map (rather than for metadata or some other request).

FORMAT
You choose which output formats to support.  Permissible image formats are: GIF, JPEG, TIFF, GeoTIFF, PNG, PPM, and WBMP.  Several public domain and commercial software packages for creating images from numerical data will be listed in a future version of this Guide.  The map you return to the client must have its mime type set appropriate to the requested format (e.g image/gif).  Note that TIFF and GeoTIFF support floating point data types (single and double-precision), although not all TIFF/GeoTIFF readers support the feature. Instead of "images", you can alternatively support graphic element formats (WebCGM, SVG) or feature formats (GML.1, GML.2, GML.3).  Additional formats will be added in WMS 1.1 (including HDF-EOS, raw binary, etc.).   For now, you can add additional formats to this list (see the OpenGIS specifications for details).

WIDTH and HEIGHT
You must be able to provide images in any requested size.  These values will be requested as positive integers.  If your server provides graphic elements or features (rather than images), the width and height are ignored.

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.petroconsultants.com/products/geodetic.html .  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) .

WMTVER
Currently there is only one version of WMS available, which can be listed as 1.0.0, 1.0, or 1.  As future versions are developed, 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/process.cgi?REQUEST=capabilities&WMTVER=1.0.0

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=capabilities indicates that this request is for metadata (rather than a map).

A sample XML metadata file is shown below:

<?xml version='1.0' encoding="UTF-8" standalone="no" ?>
<!DOCTYPE WMT_MS_Capabilities SYSTEM "http://www.digitalearth.gov/wmt/xml/capabilities_1_0_0.dtd">
<WMT_MS_Capabilities version="1.0.0" updateSequence="0">
     <Service>
          <Name>Air ESIP</Name>
          <Title>Air ESIP Map Server</Title>
          <OnlineResource>http://www.airesip.org</OnlineResource>
     </Service>
     <Capability>
          <Request>
               <Map>
                    <Format><GIF /><JPEG /></Format>
                    <DCPType><HTTP><Get  onlineResource="http://www.airesip.org/cgi-bin/de.pl" /></HTTP></DCPType>
              </Map>
              <Capabilities>
                   <Format><WMS_XML /></Format>
                   <DCPType><HTTP><Get onlineResource="http://www.airesip.org/cgi-bin/de.xml" /></HTTP></DCPType>
               </Capabilities>
          </Request>
          <Layer>
               <SRS>EPSG:4326</SRS>
               <Title>SeeAll Radiometer</Title>
               <LatLonBoundingBox minx="-180" miny="-82" maxx="180" maxy="82" />
               <Name>temperature</Name>
           </Layer>
     </Capability>
</WMT_MS_Capabilities>

The first line in the XML code is a standard header and the second line gives the URL for the DTD (or validation file) for the XML code.  The following line is the main tag and gives the latest XML version supported by the server and an "updateSequence" number.  The latter is normally incremented every time a change has been made to the Capabilities file, so that cataloging systems can determine quickly if an update to a server's holdings has occurred.  Within the tag are <Service> and <Capability> tags.  The <Service> must include at a minimum: <Name>, <Title>, and <OnlineResource> (a web page providing further description of the site).  The <Capability> tag includes <Request> and <Layer> tags.  <Request> consists of <Map> and <Capabilities> tags to describe the formats and request types available from each.   The <Name> tag gives the actual name that appears in the LAYER= parameter.  If a SRS other than latitude-longitude is used, the <LatLonBoundingBox> boundary can be approximate, and a <Bounding Box> tag must be added to give the exact bounding box in that coordinate system.

In most cases, your server will be providing more than a single layer (variable).  Each layer is listed within its own <Layer> tag in the Capabilities file.  The <Layer> tags can be nested when common properties apply to multiple layers.  In the nested case, it is permissible for a nested layer to override the parent description.

It is a requirement to enclose multiple layers in a single outer <Layer> element. Properties common to all layers may be listed there, for convenience. In particular, any SRSs common to all layers should be listed there.

You may choose to allow additional parameters in a GetMap request that are specific to your server (e.g. SPECTRAL_BAND).  This feature of your server is declared in the Capabilities XML file, inside the <Capability> tag as in the following example.

  <VendorSpecificCapabilities>
         <SPECTRAL_BAND>
             <Title>Spectral Band</Title>
             <Abstract>Spectral Band, expressed as a number between 1 and 7.</Abstract>
         </SPECTRAL_BAND>
  </VendorSpecificCapabilities>

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.

It is recommended that error messages be reported to the client.  The message can be reported in one of three ways: BLANK, INIMAGE, or WMS_XML.  A BLANK response is a return of the requested size and format with all pixels set to the background color.  INIMAGE is the same with a text description of the problem displayed within the image.  WMS_XML is an XML file in the form:

  <WMTException version="1.0.0">
        Text of error message
  </WMTException>

Clients may specify the exception method from the list of exception methods that you support by setting EXCEPTIONS to BLANK, INIMAGE, or WMS_XML.  The exception methods that you support are added to the Capabilities file in the following form:

  <Exception>
       <Format>
             <INIMAGE />
       </Format>
  </Exception>

and placed within the <Capability> tag.

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=feature_info &WIDTH=640&HEIGHT=480&BBOX=-110.,40.,-80.,30.
&WMTVER=1.0.0 &SRS=EPSG:4326&QUERY_LAYERS=temperature&X=321&Y=165

Any layer that implements GetFeatureInfo should have its <Layer> tag in the Capabilities file replaced with  <Layer queryable="1">.

REQUEST
The parameter REQUEST=feature_info indicates that this request is for features (rather than metadata or a map).

WIDTH, HEIGHT, SRS, BBOX, WMTVER, 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
For images, you may choose the format in which to return the feature information, and this parameter can then be ignored.  For non-image "feature" data, the user may set INFO_FORMAT=GML.1 or GML.2 or GML.3.

FEATURE_COUNT
The user may choose to specify a maximum amount of information.

<STYLE>
    <Name>Contour</Name>
    <Title>Contour Map</Title>
</STYLE>

Additional tags can optionally be added for <Abstract> and <StyleURL>. The StyleURL is commonly used by viewers as a legend or color scale. Note that such a legend is static, in that it must be the same for all requests for that layer. Future versions of WMS will enable rendering of dynamically determined color scales.

The <Service> tag of the Capabilities file may contain additional metadata describing the data product. The following tags have been defined and can be added to the Capabilities file: <Abstract>, <Keywords>, <Fees>, and <Access Constraint>.

The <Layer> tag of the Capabilities file may contain additional metadata describing a layer. The following tags have been defined for this purpose: <Abstract>, <Keywords>, <DataURL>, and <ScaleHint>. DataURL provides a way for viewers to provide additional information about particular layers via a link. ScaleHint gives the user some idea of the resolution of the data. This tag must include the two attributes min and max, representing the minimum and maximum scales that make sense for viewing that layer. These numbers are the corner-to-corner ground distance for a pixel near the center of the image.

Although date and time were not included in the WMT 1.0.0 standard, subsequent unofficial versions of WMT have been developed to handle multitemporal data. It is very likely that these conventions for time will be adopted when 1.1 is accepted (in Spring 2001), as they comply with ISO-8601 standards.  See http://www.digitalearth.gov/wmt/time.html for further information. Some examples from this new proposed standard are shown below. We strongly suggest adhering to this standard for your time-dependent data. Until its formal acceptance, TIME is considered a vendor-specific parameter that must be declared in the Capabilities file.

TIME=2000-06-23T20:07 (June 23,2000 at 20:07)
TIME=1999-01-01,1999-04-01,1999-07-01,1999-10-01 (The 4 dates 1/1, 4/1, 7/1, and 10/1 in 1999)
TIME=1995-04-22T12:00/2000-06-21T12:00/P1D (Daily values between 4/22/1995 and 6/21/2000 - P1D refers to a period of 1 day)