MapGuide RFC 55 - Switch from PROJ4 to CS-Map coordinate system library

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	August 07, 2008
Last Modified	Hugues Wisniewski Timestamp
Author	Hugues Wisniewski
RFC Status	for feview
Implementation Status	(pending, under development, completed)
Proposed Milestone	2.1
Assigned PSC guide(s)	Bruce Dechant
Voting History
+1
+0
-0
-1
no vote

Overview

For the coordinate system work, MapGuide uses the PROJ4 library which is wrapped into the MgGeometry.dll binary module. The coordinate system functionality is exposed through all the API interfaces prefixed with MgCoodinateSystem This proposal aims at replacing the PROJ4 implementation with the CS-Map implementation. CS-Map was recently open sourced and posted on at:
​http://svn.osgeo.org/metacrs/csmap/

Motivation

The CS-Map code has a broader range of functionality than what PROJ4 can offer.

CS-Map can address things that are not well addressed by PROJ4 like:

• vertical datum shifting
  
• WKT transformations in multiple flavors like Oracle
  
• greater coverage in terms of coordinate system definitions, right now more than 4000 systems, roughly 700 datums and 100 ellipsoids
  
• CS-Map can provide an implementation to all the MgCoordinateSystem API methods that currently throw MgNotImplementedException
  

Proposed Solution

The current MgCoordinateSystem API implementation code is a wrapper around PROJ4
This implementation code is located here:
​http://svn.osgeo.org/mapguide/trunk/MgDev/Common/CoordinateSystem/
The new API implementation would wrap the CS-Map code hosted at:
​http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev/

This API is part of the module MgGeometry.dll generated from the project:
​http://svn.osgeo.org/mapguide/trunk/MgDev/Common/Geometry/Geometry.vcproj

This project is used in the solutions:

​http://svn.osgeo.org/mapguide/trunk/MgDev/Server/Server.sln
​http://svn.osgeo.org/mapguide/trunk/MgDev/Web/src/WebTier.sln

The current PROJ4 implementation would not be supported anymore. Only CS-Map would remain in the place where the PROJ4 currently resides:
​http://svn.osgeo.org/mapguide/trunk/MgDev/Common/CoordinateSystem/

Implications

PROJ4 would not be supported anymore.
The coordinate system definitions will come from the CS-Map coordinate system dictionaries.
All the MgCoordinateSystem API methods that currently throw MgNotImplementedException would have a fully functional implementation.
The build process documentation will have to be updated to explain how to get and build CS-Map and then build MapGuide using CS-Map instead of PROJ4.

Concerning the possible risk that users would see differences from one application to the next when moving from PROJ4 to CS-Map, this may indeed impact MapGuide because of the differences between Proj4 and CSMap. Ie: supported projections, the way transformations are calculated, or slightly different coefficient precision in the coordinate system definitions, etc...
Any of the well known and highly used systems in CS-Map is unit tested with a list of test points that should be transformed to an expected target point within a certain tolerance. This test points in this list typically come from official sources. We can expect slightly different results between the two libraries depending on the reasons listed above but if there is a large difference between the two products, and we have valid test points for a given transformation to test what is expected, the resulting defect we would be facing in that case in the algorithm or in the system definition will have to be fixed.

Test Plan

CS-Map has its own standalone unit tests so it can be tested separately.
The existing unit MapGuide unit tests would remain the same.
More can be added, especially for the new functionality that CS-Map provides, like the WKT conversions.

Funding/Resources

Provided by Autodesk.

Additional Notes

The code is ready to be distributed.
If this request is accepted, the implementation would be trivial as it has already been intensively tested and is fully functional.