Opened 8 years ago

Closed 7 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 8 years ago.
Default Response Format.patch (1.8 KB) - added by liuar 8 years ago.
Validate INFO_FORMAT.patch (2.9 KB) - added by liuar 8 years ago.
ProcessBoundingboxAxes.patch (6.1 KB) - added by liuar 8 years ago.
ProcessBoundingBoxAxes.patch (6.2 KB) - added by liuar 8 years ago.
Exception Formats.patch (854 bytes) - added by liuar 8 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 8 years ago by liuar

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.

Changed 8 years ago by liuar

comment:2 Changed 8 years ago by liuar

Owner: set to liuar
Version: 2.1.0

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

comment:3 Changed 8 years ago by 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.


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

Changed 8 years ago by liuar

comment:4 Changed 8 years ago by liuar

Changeset [5025] for patch Default Response Format.patch

comment:5 Changed 8 years ago by 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.

Changed 8 years ago by liuar

Attachment: Validate INFO_FORMAT.patch added

comment:6 Changed 8 years ago by 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);
	}

	...
}

Changed 8 years ago by liuar

comment:7 Changed 8 years ago by 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);

Changed 8 years ago by liuar

comment:8 Changed 8 years ago by liuar

Changeset [5049] for patch ProcessBoundingBoxAxes.patch

comment:9 Changed 8 years ago by 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.

Changed 8 years ago by liuar

Attachment: Exception Formats.patch added

comment:10 Changed 8 years ago by liuar

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

comment:11 Changed 8 years ago by liuar

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

comment:12 Changed 8 years ago by 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>
  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 Changed 8 years ago by liuar

Changeset [5077]

comment:14 Changed 7 years ago by liuar

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