| Date: | 2007/06/15 |
|---|---|
| Author: | Daniel Morissette |
| Contact: | dmorissette at mapgears.com |
| Last Edited: | 2007/09/05 |
| Status: | Draft |
| Version: | MapServer 5.2 |
| Id: | $Id: ms-rfc-30.txt 8278 2008-12-23 21:34:31Z hobu $ |
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.
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 SRS codes in the CRS:xxxx space have also been added by WMS 1.3.0 that will need to be supported by MapServer
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.
At this point the exact implementation details have not all been sorted out. They will be documented here as we refine them.
None. This affects only the WMS server interface and WMS CONNECTION type.
mapwms.c
mapwmslayer.c
...
No vote yet.
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.