WMS 1.3.0 is now public

WMS 1.2.0 has been removed and replaced by WMS 1.3.0. Changing the title of this
bug to say 1.3.0.

Setting FUTURE target milestone... not sure when we'll implement this version
since it implies several non-trivial changes, mostly with SRS codes, and anyway
WMS 1.1.1 still seems to be the most popular.

Added myself to the cc.

I have created MS RFC 30 about this:

http://mapserver.gis.umn.edu/development/rfc/ms-rfc-30

Adding my current self to cc (I've since left the reporter email address)

FYI RFC 30 http://mapserver.org/development/rfc/ms-rfc-30.html

Initial notes on projections: wms 1.3.0

1 - Every Layer CRS has an identifier that is a character string. Two types of Layer CRS identifiers are permitted: “label” and “URL” identifiers:

Label is CRS, EPSG and AUTO2 URL: The identifier is a fully-qualified URL that references a publicly-accessible file containing a definition of the CRS that is compliant with ISO 19111.

The intention is to support only the label types CRS

2- CRS:CRS” namespace Several CRS are defined and these should be supported:

CRS:84 (WGS 84 longitude-latitude) CRS:83 (NAD83 longitude-latitude) CRS:27 (NAD27 longitude-latitude) CRS:1 (pixel coordinates)

The intention is to extend msLoadProjectionString function to parse these CRS and assign the corresponding epsg code Not sure yet about about all the implications of CRS:1: the idea from what I can see is to be able to expose for example layers that do not have any projection defined. I guess this would be treated as a special case.

3-AUTO2 projections

They are similar to the AUTO projections that we already support. The main diffrence being the factor parameter:

A complete “AUTO2” CRS label comprises the “AUTO2” namespace prefix, a numeric CRS identifier from the AUTO2 namespace, a number indicating what conversion factor to apply to convert between bounding box units and AUTO2 CRS units, and values for the central longitude and latitude in degrees: AUTO2:auto_crs_id,factor,lon0,lat0

EXAMPLES ,

• “CRS=AUTO2:42003,1,-100,45”.
• same as above but with conversion factor allowing bounding box in U.S. feet:

"CRS=AUTO2:42003,0.3048006096012192,-100,45"

The once we will support are 42001, 42002, 42003, 42004, 42005

From what I can understand, the unit is assumed to be meters for these projections.

Support in Mapserver will be based on what we already do for the AUTO projections.

We need to take the factor element and apply it to BBOX.

4- EPSG name space

Note here that the axis are reversed. Same functions as wcs should be used to be able to read the projection and account for the axis.

4- URNs Nothing in the wms1.3.0 specs about using URNs, But there seems to be a Recommended paper (URNs of definitions in ogc namespace OGC 05-010), that suggests that the best practice is to use the URNs. Common URN defined look like:

urn:ogc:def:crs:OGC:1.3:CRS84 urn:ogc:def:crs:OGC:1.3:AUTO42001:99:8888 urn:ogc:def:crs:EPSG::4326

Should we support them (+ the non urn types such as CRS:84)?

One other note looking at wcs implementation, from what I understand, It is assumed that if an EPSG CRS is given using the URN format, the axis are reversed. If we get the "regular" espg code (EPSG:4326), we treat it like before.

Should we follow the same approach here?

If you have comments/inputs please let me know. I will then update the RFC to reflect this.

About your last question, my understanding is that in WMS 1.3, any use of "regular" epsg codes (e.g. EPSG:4326) requires that we use the axis order from the EPSG database, which is the reverse of what we used to do in WMS 1.1 and older... and also doesn't match what you say our WCS implementation is doing.

What I meant was that if the user gives an URN type espg definition, we would assume the reverse axes. If the user gives EPSG:4326 we assume non reversed axes. This was a suggestion and I agree It might be confusing for the user. We can also always assume reverse axis for any type of EPSG code given (URN or not)

Some updates/notes:

Example WMS 1.3.0

• updated URL to document: http://portal.opengeospatial.org/files/?artifact_id=14416
• client: http://demo.cubewerx.com/demo/cubexplor/cubexplor.cgi
• server: http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?service=WMS&version=1.3.0&request=GetCapabilities

First pass (in a long time) through the document shows:

• HTTP POST is an XML document (6.3.4)
• GetCapabilities service keyword is mandatory (more info in #2531)
• /WMS_Capabilities/Service/Name shall be "WMS" (why didn't they hardcode this in the schema, then?)
• Service metadata now has optional LayerLimit, MaxWidth, MapHeight
• Exception formats are non-MIME types again
• GetFeatureInfo X and Y keywords are now I and J

From what I can see http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd extends the wms capabilities and defines DescribeLayer? and GetLegendGraphic?. But I could not figure out what happened to the GetStyles/PutStyles? operations. From what I have seen from cubewerx implementation, they define their own xsd to include GetStyles?. I am wondering if I have missed something on this.

Wasn't one of the big changes in 1.3.0 removal of SLD? Having said this, the schema does have a wms:_ExtendedCapabilities type where one could put SLD defs. Of course, we would want to see how others do it so as to maximize interoperability.

* HTTP POST is an XML document (6.3.4)

I missed this when I was reading initially the spec. I am not sure at this point if is going to make it for next week (5.4 release). I will add it in the RFC as a maybe.

Wasn't one of the big changes in 1.3.0 removal of SLD? Having said this, the schema does have a wms:_ExtendedCapabilities type where one could put SLD defs. Of course, we would want to see how others do it so as to maximize interoperability.

Yes It has been removed and replaces with 2 specs (Styled Layer Descriptor profile of the Web Map Service and Symbology Encoding Implementation Specification).

The first spec is the one that defines the DescribeLayer? and the GetLegendGraphic? but I do not see GetStyles? and PutStyles? in it. I am not sure at this point where they are. From what I can see (at least looking at cubewerx), they define their own xsd and extend the wms:_ExtendedOperation to add the GetStyles? and PutStyles? operations. I will try to inquire on the wms-dev list and see if that is the way.

The Symbology Encoding Implementation is basically the SLD 1.1 version (uses FE1.1 I believe) and is divided into multiple small xsds. The intention is to support most/all parameters that we support for SLD1.0

Another point is that these specs specify that WMS 1.3.0 needs to be used only with an SLD 1.1 version. I am not sure why that needed to be in the spec. I am not having fun at all on this :)

Assefa: I've made some changes (see r8563) to your changes in r8562, to show valid SLD 1.1.0. Does the code handle incoming valid SLD 1.1.0?.

Assefa: for SLD, any chance we can look at #1451 as well? This is applicable to GetLegendGraphic for 1.3.0 as well.

Assefa: more questions :)

• how will mapscript $oMap->generatesld() work now? Which version will it return? Can/should we add an arg for version? With the default being 1.1.0?

Replying to tomkralidis:

Assefa: I've made some changes (see r8563) to your changes in r8562, to show valid SLD 1.1.0. Does the code handle incoming valid SLD 1.1.0?.

It should. all the tests I am doing uses SLDs that are validated through XML Spy. Note though that we do not validate the SLD when parsing it (so things like name spaces, schemas are discarded)

Replying to tomkralidis:

Assefa: for SLD, any chance we can look at #1451 as well? This is applicable to GetLegendGraphic for 1.3.0 as well.

Ok. Will look at all bugs in the next couple of weeks and correct if possible.

Replying to tomkralidis:

Assefa: more questions :) * how will mapscript $oMap->generatesld() work now? Which version will it return? Can/should we add an arg for version? With the default being 1.1.0?

I think adding a version is a good idea. Note that I did not yet change the code to generate SLD1.1.0. I think the version will be defaulted to SLD 1.0 since I believe most of the users still use wms 1.1.1.

I also send an e-mail to wms-dev to know how to handle the GetStyles? request (since I could not see it in the official specs). see comment #12. Any takes on how to handle this?

Replying to assefa:

Replying to tomkralidis:

Assefa: more questions :) * how will mapscript $oMap->generatesld() work now? Which version will it return? Can/should we add an arg for version? With the default being 1.1.0?

I think adding a version is a good idea. Note that I did not yet change the code to generate SLD1.1.0. I think the version will be defaulted to SLD 1.0 since I believe most of the users still use wms 1.1.1. I also send an e-mail to wms-dev to know how to handle the GetStyles? request (since I could not see it in the official specs). see comment #12. Any takes on how to handle this?

I would say:

      <ms:GetStyles>
        <Format>text/xml</Format>
        <DCPType>
          <HTTP>
            <Get>
              <OnlineResource xlink:type="simple"
                xlink:href="http://host/wms"/>
            </Get>
            <Post>
              <OnlineResource xlink:type="simple"
                xlink:href="http://host/wms"/>
            </Post>
          </HTTP>
        </DCPType>
      </ms:GetStyles>

For this to be valid, we would need:

• to define, in the root element xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
• to alter xsi:schemaLocation to:

xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd  http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd http://mapserver.gis.umn.edu/mapserver ./mswms.xsd">

Of course, mswms.xsd should be a CGI call which generates the small xsd which would return:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:wms="http://www.opengis.net/wms" xmlns:ms="http://mapserver.gis.umn.edu/mapserver" targetNamespace="http://mapserver.gis.umn.edu/mapserver" elementFormDefault="qualified">
	<import namespace="http://www.opengis.net/wms" schemaLocation="http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd"/>
	<element name="GetStyles" type="wms:OperationType" substitutionGroup="wms:_ExtendedOperation"/>
</schema>

Maybe a call like http://host/mapservwms?service=WMS&version=1.3.0&request=GetWMSSchemaExtension

Comments?

Do you think it is possible to just put the schema on osgeo site and point to it?

We could. But that would tie us to a hardcoded URL in the codebase.

here's a patch (see attachment:"ms-trac-473.patch") which does comment:22, for review and comment.

Just updated the patch. Applying this patch now produces a valid WMS Capabilities XML output, with ms:GetStyles per comment:22

ok cool. Can you commit the patch? Thanks.

I'll commit sometime today.

Question: does GetLegendGraphic require SLD_VERSION now? If yes, we need to augment the Capabilities !LegendURL xlink:href values to pass along SLD_VERSION.

yes GetLegendGraphic? requires the sld_version (this is already added). You are right for the LegnedURL (It is not yet done)

Replying to assefa:

ok cool. Can you commit the patch? Thanks.

Committed in r8567

Replying to assefa:

yes GetLegendGraphic? requires the sld_version (this is already added). You are right for the LegnedURL (It is not yet done)

Fixed in r8568

docs updated. closing this. Specific tickets will be open when needed.