MapGuide RFC 98 - EPSG/SRID Code Upgrade
This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.
Status
| RFC Template Version | (1.0) |
| Submission Date | 21 June 2010 |
| Last Modified | Norm Olsen 21 June 2010 |
| Author | Norm Olsen |
| RFC Status | adopted |
| Implementation Status | pending |
| Proposed Milestone | 2.3 |
| Assigned PSC guide(s) | Bruce Dechant |
| Voting History | (vote date) |
| +1 | Bruce, Tom, Trevor, Jason, Zac, Jackie, Haris |
| +0 | |
| -0 | |
| -1 | |
| no vote | Bob, Paul |
Overview
CS-MAP RFC 3 proposes to add three items to the coordinate system dictionary, and one item each to the Datums and Ellipsoid dictionaries. (The format doesn't change, we'll be using currently unused holes in the structures.) This RFC proposes to expose these new data values through the MgCoordinateSystem interface. The items being added are EPSG code, Oracle SRID code, and the EPSG Quadrant code.
Motivation
The EPSG code and the Oracle SRID code are becomming frequently desired/referenced data items. Conversion between CS-MAP key name and EPSG code is currently possible, but requires the use of the NameMapper which can be painfully slow if one intends to map large segments of the EPSG code set. While supported in the NameMapper, mapping between CS-MAP key names and Oracle SRID codes is not expsed through the MgCoordinateSystem interface. Implementation of this RFC would, in conjunction with CS-MAP RFC 3, enable direct access to both codes using the MgCoordinateSystem interface.
There exists a problem encountered when using the latest version of WMS specification. This new specification now requires strict adherence to the axis specifications in Coordinate Reference System (CRS) definitions. CS-MAP RFC 3 calls for the addition to the coordinate system dictionary an quadrant value (using the same values as the standard CS-MAP quad parameter) which indicates what the EPSG definition indicates the axis specification to be. Implementation of this RFC will expose this value through the MgCoordinateSystem interface.
Proposed Solution
Implementation of this RFC would be achieved by adding three new methods to the MgCoordinateSystem interface, and one new method to each of the MgCoordinateSystemDatum and MgCoordinateSystemEllipsoid interfaces as follows:
INT32 MgCoordinateSystem::GetEpsgCode (void); INT32 MgCoordinateSystem::GetSridCode (void); INT16 MgCoordinateSystem::GetEpsgQuadrant (void); INT32 MgCoordinateSystemDatum::GetEpsgCode (void); INT32 MgCoordinateSystemEllipsoid::GetEpsgCode (void);
All methods will return a zero if the information is unknown; no exceptions will be thrown.
The quadrant values are (X is the first ordinate and Y is the second ordinate):
| Value | Description |
| 0 | Unknown, assume 1 |
| 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 |
Implications
Since we would be using currently unused holes in the CS-MAP dictionary structures, it would be nice to rename these elements. Doing so will break the build of MapGuide if the changes are not synchronized.
Test Plan
A test function will be written which will cycle through the three dictionaries affected and the results of these new methods compared to the current contents of the NameMapper. This effort will be done at the CS-MAP level. As these methods are simple one liners, no special test module is being planned at the MgCoordinateSystem level.
Funding/Resources
Software developement resources and funding to be provided by Autodesk.
