[mapguide-trac] #1392: OGC WMS 1.3.0 Support
MapGuide Open Source
trac_mapguide at osgeo.org
Wed Jul 21 02:37:10 EDT 2010
#1392: OGC WMS 1.3.0 Support
-----------------------------+----------------------------------------------
Reporter: liuar | Owner: liuar
Type: enhancement | Status: new
Priority: medium | Milestone:
Component: WMS Interface | Version:
Severity: trivial | Keywords: WMS CITE
External_id: |
-----------------------------+----------------------------------------------
Comment(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. [[BR]]
[[BR]]
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.[[BR]]
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[[BR]]
{{{
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);
}
...
}
}}}
--
Ticket URL: <http://trac.osgeo.org/mapguide/ticket/1392#comment:6>
MapGuide Open Source <http://mapguide.osgeo.org/>
MapGuide Open Source Internals
More information about the mapguide-trac
mailing list