OGC WMS 1.3.0 Support

[liuar]

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

[liuar]

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
   

2. 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.

[liuar]

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

[liuar]

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.
   

2. 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().

[liuar]

Changeset [5025] for patch Default Response Format.patch

[liuar]

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.

[liuar]

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);
	}

	...
}

[liuar]

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);

[liuar]

Changeset [5049] for patch ProcessBoundingBoxAxes.patch

[liuar]

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.

[liuar]

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

[liuar]

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

[liuar]

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>

2. 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>

3. 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.

[liuar]

Changeset [5077]