.. _rfc30:

==============================================
MS RFC 30: Support for WMS 1.3.0
==============================================

:Date: 2007/06/15
:Author: Daniel Morissette
:Contact: dmorissette at mapgears.com
:Author: Yewondwossen Assefa
:Contact: yassefa at dmsolutions.ca
:Last Edited: 2009/02/11
:Status: Adopted
:Version: MapServer 5.4

Overview
--------

This RFC documents the changes required in order to upgrade MapServer's OGC
WMS support to version 1.3.0 of the specification.

MapServer already includes mechanisms to support multiple WMS versions (and
already supports WMS versions 1.0.0, 1.1.0 and 1.1.1) so in theory this upgrade 
should be straightforward and shouldn't require a RFC. Unfortunately, WMS 1.3.0
contains some tricky changes that while they are not exactly backwards 
incompatible are likely to make the life of users of WMS miserable.

This RFC is mostly to document those changes and the way MapServer deals 
with them.

Coordinate Systems and Axis Orientation
---------------------------------------

The main issue introduced by WMS 1.3.0 is the change in the way it handles
axis order for several SRS. This has an impact on the way the
BBOX is specified in WMS requests and in Capabilities documents and in
how the CONNECTIONTYPE WMS code interacts with remote servers.

In previous versions of WMS, for any SRS the first axis
was the easting (x or lon) and the second axis was the northing (y or lat). 
Starting with WMS 1.3.0, some SRS such as the very popular
EPSG:4326 have their axis reversed and the axis order becomes lon, lat 
instead of lat, lon. This change in WMS 1.3.0 was done in order to align 
with the definitions from the EPSG database (a requirement to make WMS
an ISO specification).

This change is sure to confuse simple clients that used to treat all 
SRS the same way. MapServer and PROJ will need to be extended to carry
information about the axis order of all EPSG SRS codes and treat them
using the correct axis order.

New CRS codes such as CRS:xxxx and AUTO2:xxxx have also been added by WMS 1.3.0
that will need to be supported by MapServer. Note the wo types of Layer CRS 
identifiers are supported by the specification: “label” and “URL” identifiers.
The intention is to support at this point the label types CRS. 

List of CRS planned to be supported are:

- CRS:84 (WGS 84 longitude-latitude) 
- CRS:83 (NAD83 longitude-latitude) 
- CRS:27 (NAD27 longitude-latitude).  
- AUTO2:42001 AUTO2:42002 AUTO2:42003 AUTO2:42004 AUTO2:42005

CRS:1 (pixel coordinates) would not be supported at this point (there is a ticket 
discussing this issue https://github.com/mapserver/mapserver/issues/485)

EPSG codes: when advertising (such as BoundingBox for a layer elemnt) or using 
a CRS element in a request such as GetMap/GetFeatureInfo, elements using epsg code >=4000 
and <5000 will be assumed to have a reverse axes.  


All the above need to be done in a way that allows continued support for
older versions of the WMS specification (1.0.0 to 1.1.1) and will have 
the least impact on existing WMS services.

Implementation for the reverse axis will follow closely to what was already
done for WCS1.1 support (http://mapserver.org/development/rfc/ms-rfc-41.html)


WMS and SLD
-----------

All references to SLD support has been removed from the WMS 1.3.0 specifications.
It has been replaced by two specifications:

- Styled Layer Descriptor profile of the Web Map Service
- Symbology Encoding Implementation Specification

The Styled Layer Descriptor profile allows:

- to extend the WMS to support additional operations (DescribeLayer, GetLegendGraphic)
- additional parameters related to the SLD for the GetMap support
- advertise SLD support.

This specification will be supported in the current implementation. 
Note that the GetStyles operation (available in WMS 1.1.1) might not be supported
in the first phase

The Symbology Encoding Implementation represent basically the definitions for the 
different symbolizers. We need to upgrade the current SLD support to support this
specification.


HTTP Post support
-----------------

HTTP Post support is optional and currently supported by MapServer  WMS 1.1.1.
WMS 1.3.0 defines that if POST is supported, the the request message is formulated 
as an XML document.
Although this is highly deirable, the first implementation of the WMS 1.3.0 might
not support the XML Post requests.
   

OCG compliance tests
--------------------

The OGC Compliance and Interoperability Testing Initiative (CITE) 
http://cite.opengeospatial.org/test_engine/wms/1.3.0/ provides automatic tests to 
validate the implementation. The short term intention is to use this service as a 
first validation tool. The longer term goal is to have MapServer  WMS 1.3.0 fully compliant.  


Other Notes
-----------

- GetCapabilities advertises only the text/xml format. During a request we do not parse 
  the optional Format parameter. It is always set to text/xml


MapScript Implications
----------------------

None. This affects only the WMS server interface and WMS CONNECTION type.

Files affected
--------------

::

 mapwms.c
 mapwmslayer.c
 mapfile.c
 mapows.c/h
 mapogcsld.c

Backwards compatibility issues
------------------------------

* The change in the way the axis order is handled is likely to cause lots
  of confusion.

Bug ID
------

* 473: https://github.com/mapserver/mapserver/issues/473


Voting history
--------------

Passed with +1 from: TomK, Woodbridge, Assefa, Morissette


Questions/Comments from the review period
-----------------------------------------

* Q: Can libxml2 be used to generate XML responses to continue the work started 
  in mapowscommon.c?

  A: I'll keep libxml2 in mind during the implementation, but I do not plan to 
  refactor and risk breaking any code to convert it to libxml2 as part of 
  this upgrade.

  Since WMS 1.3.0 doesn't implement OWS common, it won't benefit from any of 
  the code that's already using libxml2. It will actually mostly reuse 
  existing printf-based code that's already well tested and working. I think 
  the right time to switch to libxml2 for WMS would be when it will support 
  OWS common and then there will be real benefits by reusing functions from 
  mapowscommon.c. 
