WMS 1.3.0 is now public

[tom.kralidis@…]

Heads up:

​http://www.opengis.org/docs/03-086.pdf

[dmorissette]

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.

[bartvde@…]

Added myself to the cc.

[dmorissette]

I have created MS RFC 30 about this:

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

[tomkralidis]

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

[tomkralidis]

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

[assefa]

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.

[dmorissette]

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.