Opened 14 years ago

Closed 14 years ago

#1392 closed enhancement (fixed)

OGC WMS 1.3.0 Support

Reported by: liuar Owned by: liuar
Priority: medium Milestone:
Component: WMS Interface Version:
Severity: trivial Keywords: WMS CITE
Cc: External ID:

Description

Enhance the WMS 1.3.0 implmentation of MapGuide according to OGC WMS 1.3.0 specification. The goal is to make sure MapGuide could pass the OGC certification for WMS 1.3.0 and 1.1.1
This is a relevate ticket for RFC95

Attachments (6)

update config and add template.patch (15.6 KB ) - added by liuar 14 years ago.
Default Response Format.patch (1.8 KB ) - added by liuar 14 years ago.
Validate INFO_FORMAT.patch (2.9 KB ) - added by liuar 14 years ago.
ProcessBoundingboxAxes.patch (6.1 KB ) - added by liuar 14 years ago.
ProcessBoundingBoxAxes.patch (6.2 KB ) - added by liuar 14 years ago.
Exception Formats.patch (854 bytes ) - added by liuar 14 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 by liuar, 14 years ago

Priority: lowmedium
  1. Update the OgcWmsService.config.awd
    (1)Add WMS 1.3.0 as new supported versions.
    (2)Define a new item "RS_CRS.xml" as reference system in WMS 1.3.0
    (3)Define a new item "Enum.item.CRS", a replacement of "Enum.item.SRS", used in WMS 1.3.0
  1. Add a template file 1.3.0.xml.awd for WMS 1.3.0
    (1)Update some keywords which are defined in 1.3.0 specification. For example: SRS -> CRS
    (2)Define a new item "EX_GeographicBoundingBox", a replacement of "LatLonBoundingBox", defined in WMS 1.3.0 specification. And some relevant items are also updated.

comment:2 by liuar, 14 years ago

Owner: set to liuar
Version: 2.1.0

Changeset [4994] for patch "update config and add template.patch"

comment:3 by liuar, 14 years ago

  1. The default response format of 1.0.0 is text/xml for GetCapabilities request and the defualt format of 1.1.0 and 1.1.1 is application/vnd.ogc.wms_xml. From 1.3.0 on, OGC decides to change the format back to text/xml. Therefore, I adapt the implementation of MgOgcWmsServer::GetCapabilitiesResponse() for this update.


  1. The term SRS(Sptial Reference System) is deprecated from WMS 1.3.0 and CRS(Coordinate Reference System) is suggested to be used. Most part of code has been update previously, and I made a supplement in MgWmsLayerDefinitions::LayerSupportsReferenceSystem().

by liuar, 14 years ago

comment:4 by liuar, 14 years ago

Changeset [5025] for patch Default Response Format.patch

comment:5 by liuar, 14 years ago

In OGC 06-042 WMS 1.3.0 specification:
The mandatory INFO_FORMAT parameter indicates what format to use when returning the feature infomation.
So, the parameter INFO_FORMAT becomes a mandatory parameter in WMS 1.3.0 If the INFO_FORMAT is missing from the request parameters, an exception with code "MissingInfoFormat" will be thrown.

NOTE: There's no specified error code defined in the specification when the INFO_FORMAT missed.

by liuar, 14 years ago

Attachment: Validate INFO_FORMAT.patch added

comment:6 by liuar, 14 years ago

One significant change in WMS 1.3.0 is the axis orientation. In order to align with the definitions from the EPSG database, OGC WMS 1.3.0 specification reversed the axis sequence for some EPSG code include EPSG:4326. Which means for some EPSG CRS, the meaning of (x,y) is changed from (lon,lat) to (lat,lon) or even other orientations.

1) To obtain the axis orientation from a particular EPSG coordinate system, CS team enhances the Mentor_CS library and provides an API named MgCoordinateSystem::GetEpsgQuadrant

// 0    X increases to the East,  Y increases to the North    
// 1    X increases to the East,  Y increases to the North
// 2    X increases to the West,  Y increases to the North
// 3    X increases to the West,  Y increases to the South
// 4    X increases to the East,  Y increases to the South
// -1   X increases to the North, Y increases to the East
// -2   X increases to the North, Y increases to the West
// -3   X increases to the South, Y increases to the West
// -4   X increases to the South, Y increases to the East
INT16 MgCoordinateSystem::GetEpsgQuadrant (void)

2) Because different coordinate system has different axis orientation, the request parameter boundingbox (coord1,coord2,coord3,coord4) may indicate different area.
Therefore, after getting the quadrant of the EPSG coordinate system, it's necessary for MapGuide to process boundingbox (coord1,coord2,coord3,coord4) to the normal format (minX,minY,MaxX,MaxY). There are 3 methods to help handling the boundingbox axes orientation, and these method are implemented as utility methods

class MgWmsMapUtil
{
    public:
		
    ...

    // Handle the CRS(SRS) which have their axis orientation changed
    static void ProcessBoundingboxAxes(STRING sSrs, REFSTRING bbox);
    //Help method to swap coordinates in boundingbox
    static void SwapCoords(double* coord);
    //Help method to make coordinates about-turn
    static void SwerveCoords(double* coord1, double* coord2);
}

3) If the required wms version is higher than 1.3.0. then the request parameter boundingbox should be processed at three different places. When the request parameters are initializing in two MgHttpRequestResponseHandler: MgHttpWmsGetMap and MgHttpWmsGetFeatureInfo, and when it's need to validate the "GetMap" request request parameters in MgOgcWmsServer. Note that because the ValidateMapParameters is invoked by ValidateGetFeatureInfoParameters, so it's not necessary for ValidateGetFeatureInfoParameters to process the boundingbox axes.

void MgHttpWmsGetMap::InitializeRequestParameters(MgOgcWmsServer& oServer)
{
	...

	if(m_version >= _("1.3.0"))
    {
        MgWmsMapUtil::ProcessBoundingboxAxes(m_crs,m_bbox);
    }

	...
}

void MgHttpWmsGetFeatureInfo::InitializeRequestParameters(MgOgcWmsServer& 
oServer)
{
	...
	
	if(m_version >= _("1.3.0"))
    {
        MgWmsMapUtil::ProcessBoundingboxAxes(m_crs,m_bbox);
    }
	
	...
}

bool MgOgcWmsServer::ValidateMapParameters(MgStringCollection* queryableLayers)
{

	...

	if(sVersion >= _("1.3.0"))
    {
    	CPSZ crs = RequestParameter(kpszQueryStringCrs);
    	if(crs == NULL || szlen(crs) == 0)
    	{
        	crs = RequestParameter(kpszQueryStringSrs);
     	}
		MgWmsMapUtil::ProcessBoundingboxAxes(crs,sBBox);
	}

	...
}

by liuar, 14 years ago

comment:7 by liuar, 14 years ago

Thank Bruce's review, I update following methods in ProcessBoundingBoxAxes patch to avoid NULL pointer problem.

    // Handle the CRS(SRS) which have their axis orientation changed
    static void ProcessBoundingBoxAxes(STRING sSrs,REFSTRING bbox);
    //Help method to swap coordinates in boundingbox
    static void SwapCoords(double(& coord)[4]);
    //Help method to make coordinates about-turn
    static void ReverseCoords(double& coord1, double& coord2);

by liuar, 14 years ago

comment:8 by liuar, 14 years ago

Changeset [5049] for patch ProcessBoundingBoxAxes.patch

comment:9 by liuar, 14 years ago

In WMS 1.3.0 specification section 7.3.3.11 defines the Exceptions in WMS service.

The default value is "XML" if this parameter is absent from the request.

There are 3 kinds of exception formats defined in this section: XML, INIMAGE and BLANK. The XML is a mandatory format and the other two are optional.

by liuar, 14 years ago

Attachment: Exception Formats.patch added

comment:10 by liuar, 14 years ago

Changeset [5054] for patch "Exception Formats.patch"

comment:11 by liuar, 14 years ago

Changeset [5058] added the validation of version parameter in GetMap and GetFeatureInfo operation.

comment:12 by liuar, 14 years ago

In order to pass the OGC certification, the following implementation of MapGuide web map service should be updated

  1. The server must contain the test dataset in layers that are subsetable and resizable and support CRS:84.

So, it is necessary to add a CRS:84 translate in SRS.WKT.map

<translate from="CRS:84">GEOGCS["LL84",DATUM["WGS84",SPHEROID["WGS84",6378137.000,298.25722293]],PRIMEM["Greenwich",0],UNIT["Degree",0.01745329251994]]</translate>
  1. The exception format must be text/xml if the format is specified as XML.

The exception schema is upgrade to 1.3.0

<Response request="Exception" content-type="text/xml">
<ServiceExceptionReport version="&TemplateVersion;" 
   xmlns="http://www.opengis.net/ogc"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wms/1.3.0/exceptions_1_3_0.xsd">
 <ServiceException code="&Exception.Type;">
  &Exception.message;
 </ServiceException>
</ServiceExceptionReport>
</Response>
  1. In GetFeatureInfo operation, if user specify an invalid info_format request parameter. The server should generate an exception with error code "InvalidFormat"
CPSZ pszSupportedFormats = this->Definition(_("Formats.GetFeatureInfo")); 

bool bSupport = false;

if(pszSupportedFormats != NULL)
{
    MgXmlParser SupportedFormats(pszSupportedFormats);
    
    while(SupportedFormats.Next())
    {
        MgXmlNode& node = SupportedFormats.Current();
        if(node.Contents() == pszFormat)
        {
            bSupport = true;
            break;
        }
    }
}

if(!bSupport)
{
    ServiceExceptionReportResponse(MgOgcWmsException(MgOgcWmsException::kpszInvalidFormat,
                                             kpszExceptionMessageInvalidInfoFormat));
    bValid = false;
}

NONE: CS-Map does't support CRS:84 currently. So I ignore the ProcessBoundingBoxAxes for CRS:84 to avoid MgCoordinateSystem exceptions.

comment:13 by liuar, 14 years ago

Changeset [5077]

comment:14 by liuar, 14 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.