Opened 20 years ago
Closed 15 years ago
#473 closed enhancement (fixed)
WMS 1.3.0 is now public
Reported by: | Owned by: | assefa | |
---|---|---|---|
Priority: | normal | Milestone: | 5.4 release |
Component: | WMS Server | Version: | unspecified |
Severity: | minor | Keywords: | |
Cc: | bartvde@…, tom.kralidis@…, warmerdam, dmorissette |
Description (last modified by )
Heads up:
Attachments (1)
Change History (32)
comment:1 by , 19 years ago
Milestone: | → FUTURE |
---|---|
Summary: | WMS 1.2.0 is now public → WMS 1.3.0 is now public |
comment:3 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | FUTURE → 5.0 release |
Owner: | changed from | to
I have created MS RFC 30 about this:
comment:4 by , 17 years ago
Milestone: | 5.0 release → 5.2 release |
---|
comment:5 by , 17 years ago
Cc: | added |
---|
Adding my current self to cc (I've since left the reporter email address)
comment:6 by , 16 years ago
Milestone: | 5.2 release → 5.4 release |
---|
comment:8 by , 15 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
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.
comment:9 by , 15 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
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.
comment:10 by , 15 years ago
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)
follow-up: 14 comment:11 by , 15 years ago
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
comment:12 by , 15 years ago
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.
follow-up: 15 comment:13 by , 15 years ago
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.
comment:14 by , 15 years ago
- 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.
comment:15 by , 15 years ago
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 :)
follow-up: 19 comment:16 by , 15 years ago
follow-up: 20 comment:17 by , 15 years ago
Assefa: for SLD, any chance we can look at #1451 as well? This is applicable to GetLegendGraphic for 1.3.0 as well.
follow-up: 21 comment:18 by , 15 years ago
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?
comment:19 by , 15 years ago
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)
comment:20 by , 15 years ago
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.
follow-up: 22 comment:21 by , 15 years ago
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?
comment:22 by , 15 years ago
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?
comment:23 by , 15 years ago
Do you think it is possible to just put the schema on osgeo site and point to it?
comment:24 by , 15 years ago
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.
by , 15 years ago
Attachment: | ms-trac-473.patch added |
---|
comment:25 by , 15 years ago
Just updated the patch. Applying this patch now produces a valid WMS Capabilities XML output, with ms:GetStyles per comment:22
comment:27 by , 15 years ago
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.
follow-up: 30 comment:28 by , 15 years ago
yes GetLegendGraphic requires the sld_version (this is already added). You are right for the LegnedURL (It is not yet done)
comment:29 by , 15 years ago
comment:30 by , 15 years ago
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
comment:31 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
docs updated. closing this. Specific tickets will be open when needed.