MapGuide RFC 94 - Dtaum Transformation 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	Timestamp
Last Modified	Norm Olsen Timestamp
Author	Norm Olsen
RFC Status	draft
Implementation Status	pending
Proposed Milestone	2.3
Assigned PSC guide(s)
Voting History
+1
+0
-0
-1
no vote

Overview

Incorporate within the MgCoordinateSystem interface the new features of MetaCRS/CS-MAP RFC 2. The referenced CS-MAP RFC proposes a major rework of how datum transformations are defined and is intended to vastly improve the ability of end users to examine, modify, create, and/or delete geodetic transformations (i.e. datum shifts).

There will be few changes to any existing interface, although several interface methods are recommended for deprecation. Numerical results produced by the suggested changes will not change. There will be several additions to the existing interface in the area of enhanced access to definition meta data in support of significant UI enhancements and additions necessary to support the concept of separation of custom and distribution definitions into separate dictionary files.

Motivation

Usability of existing applications based on the MgCoordinateSystem interface is quite limited by the existing UI components for selecting coordinate systems and defining custom definitions (coordinate systems, datums, etc.) The referenced CS-MAP RFC proposal is a major effort to address the structural deficiences within CS-MAP which are obstacles to correcting this situation. The changes proposed here are necessary to expose these changes to the affected applications.

Proposed Solution

• The referenced CS-MAP RFC proposes the implementation of two entirely new dictionaries: a Geodetic Transformation Dictionary and a Geodetic Path Dictionary. Interfaces to these new dictionaries which mimic the existing four dictionary objects will need to be added to the MgCoordinateSystem interface.

• In order to support the enhanced UI components to be added to added to MgCoordinateSystem based applications, the enumerator portion of all (now 6) dictionaries will be enhanced so that supported meta data includes information currently only available from the NameMapper facility. Such information includes items such as EPSG code, Oracle SRID, ESRI name, deprecation status, etc.

• For performance purposes, the filtering associated with the above mentioned enumerators will be enhanced such that the filtering will not require access to each individual definition and enabling selection based on the enhanced data included in the expanded meta data to be included in the enumerators. This is proposed expressly for such features as listing all definitions for which an EPSG code is known.

• Primarily to overcome installation and hot fix problems, it is proposed that the (now 6) dictionary objects will be modified to support the separation of distribution definitions and custom (i.e. user defined) definitions into separate and distinct dictionary files. Thus, distribution dictionaries may be proteced by file system security and changed only by installation and/or update mechanisms.

• The constructor for the MgCoordinateSystemCatalog object will be overloaded with a constructor which accepts a parameter which indicates the dictionary folder path, thus enabling applications to specify the location in a platform independent manner.

• The major thrust of this effort is the redesign of the underlying CS-MAP datum transformation model. In sympathy with this effort, it is recommended that the following portions of the MgCoordinateSystem interface be deprecated (i.e. supported, but documented as will be removed in future releases). As currently implemented, these functions accomplish very little.

• double MgCoordinateSystemGeodeticTransformation::GetOffsetX();
• double MgCoordinateSystemGeodeticTransformation::GetOffsetY();
• double MgCoordinateSystemGeodeticTransformation::GetOffsetZ();
• void MgCoordinateSystemGeodeticTransformation::SetOffset(double x, double y, double z);
• double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationX();
• double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationY();
• double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationZ();
• double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformBwScale();
• void MgCoordinateSystemGeodeticTransformation::SetBursaWolfeTransform(double dRotationX, double dRotationY, double dRotationZ, double dBwScale);
• INT32 MgCoordinateSystemGeodeticTransformation::GetGeodeticTransformationMethod();
• void MgCoordinateSystemGeodeticTransformation::SetGeodeticTransformationMethod(INT32 nGeodeticTransformationMethod);
• double MgCoordinateSystemGeodeticTransformation::GetMaxOffset();
• bool MgCoordinateSystemGeodeticTransformation::IsLegalOffset(double dOffset);
• double MgCoordinateSystemGeodeticTransformation::GetMaxRotation();
• bool MgCoordinateSystemGeodeticTransformation::IsLegalRotation(double dRotation);
• double MgCoordinateSystemGeodeticTransformation::GetBwScaleMin();
• double MgCoordinateSystemGeodeticTransformation::GetBwScaleMax();
• bool MgCoordinateSystemGeodeticTransformation::IsLegalBwScale(double dBwScale);

Implications

Several MgCoordinateSystem interface methods will be deprecated. It is unlikely that they are used by any application as they do not really accomplish much. The deprecation is recommended as their function is incompatible with geodetic transformations as they will be implemented by the CS-MAP RFC.

Installation programs may need to be changed. The implementation of this RFC should make installation procedures eaier and more reliable; but any existing procedure which deals with user defined definitions in dictionaries will need to be updated.

The performance of the "setup" portion of a geodetic transformation may be reduced, but no effect on the actual perfromance of the conversion process is expected.

Test Plan

The referenced CS-MAP RFC proposes a rigorous regression test feature to insure that numerical results produced after implementation of the RFC are identical to the results produce prior to implementation of the RFC. This same test data and algorithm will be implemented on top of the MgCoordinateSystem interface to assure that there are no regressions in the MgCoordinateSystem interface.

To facilitate testing of the UI features, a module will be written which will test the integrity of a dictionary enumerator by verifying its contents against the NameMapper. A test module which generates a wide variety of enumeration results will then be used to generate enumerators and verify their validity.

The proposing organization intends to develope an application UI which is based on the several of these features, such application will be subjetc to traditional Quality Assurance testing procedures.

Funding/Resources

Funded by, and development and quality assurance resources provided by, Autodesk.