| | 1 | = !MapGuide RFC 94 - Dtaum Transformation Upgrade = |
| | 2 | |
| | 3 | This page contains an change request (RFC) for the !MapGuide Open Source project. |
| | 4 | More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page. |
| | 5 | |
| | 6 | |
| | 7 | == Status == |
| | 8 | |
| | 9 | ||RFC Template Version||(1.0)|| |
| | 10 | ||Submission Date||[[TimeStamp]]|| |
| | 11 | ||Last Modified||Norm Olsen [[TimeStamp]]|| |
| | 12 | ||Author||Norm Olsen|| |
| | 13 | ||RFC Status||draft|| |
| | 14 | ||Implementation Status||pending|| |
| | 15 | ||Proposed Milestone||2.3|| |
| | 16 | ||Assigned PSC guide(s)|| || |
| | 17 | ||'''Voting History'''|| || |
| | 18 | ||+1|| || |
| | 19 | ||+0|| || |
| | 20 | ||-0|| || |
| | 21 | ||-1|| || |
| | 22 | ||no vote|| || |
| | 23 | |
| | 24 | == Overview == |
| | 25 | |
| | 26 | Incorporate within the MgCoordinateSystem interface the features of MetaCRS/CS-MAP RFC - 2. The reference 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). |
| | 27 | |
| | 28 | There will be no change to any existing interface, although a few 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. |
| | 29 | |
| | 30 | == Motivation == |
| | 31 | |
| | 32 | 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 improving this situation. The changes proposed here are necessary to expose these changes to the affected applications. |
| | 33 | |
| | 34 | == Proposed Solution == |
| | 35 | |
| | 36 | * 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. |
| | 37 | |
| | 38 | * In order to support the enhanced UI components to be added to added to MgCoordinateSystem based applications, the enumeratoe portion of all (now 6) dictionaries will be enhanced so that supported meta data includes information cirrently only available from the NameMapper facility. Such information includes items such as EPSG code, Oracle SRID, ESRI name, deprecation status, etc. |
| | 39 | |
| | 40 | * For perforamance purposes, the filtering associated with the above mentioned enumerators will be enhanced such that the filtering will not require access to each individual definition but enable 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. |
| | 41 | |
| | 42 | * 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. |
| | 43 | |
| | 44 | * 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. |
| | 45 | |
| | 46 | * 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): |
| | 47 | |
| | 48 | * double MgCoordinateSystemGeodeticTransformation::GetOffsetX(); |
| | 49 | * double MgCoordinateSystemGeodeticTransformation::GetOffsetY(); |
| | 50 | * double MgCoordinateSystemGeodeticTransformation::GetOffsetZ(); |
| | 51 | * void MgCoordinateSystemGeodeticTransformation::SetOffset(double x, double y, double z); |
| | 52 | * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationX(); |
| | 53 | * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationY(); |
| | 54 | * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationZ(); |
| | 55 | * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformBwScale(); |
| | 56 | * void MgCoordinateSystemGeodeticTransformation::SetBursaWolfeTransform(double dRotationX, double dRotationY, double dRotationZ, double dBwScale); |
| | 57 | * INT32 MgCoordinateSystemGeodeticTransformation::GetGeodeticTransformationMethod(); |
| | 58 | * void MgCoordinateSystemGeodeticTransformation::SetGeodeticTransformationMethod(INT32 nGeodeticTransformationMethod); |
| | 59 | * double MgCoordinateSystemGeodeticTransformation::GetMaxOffset(); |
| | 60 | * bool MgCoordinateSystemGeodeticTransformation::IsLegalOffset(double dOffset); |
| | 61 | * double MgCoordinateSystemGeodeticTransformation::GetMaxRotation(); |
| | 62 | * bool MgCoordinateSystemGeodeticTransformation::IsLegalRotation(double dRotation); |
| | 63 | * double MgCoordinateSystemGeodeticTransformation::GetBwScaleMin(); |
| | 64 | * double MgCoordinateSystemGeodeticTransformation::GetBwScaleMax(); |
| | 65 | * bool MgCoordinateSystemGeodeticTransformation::IsLegalBwScale(double dBwScale); |
| | 66 | |
| | 67 | |
| | 68 | |
| | 69 | == Implications == |
| | 70 | |
| | 71 | As there |
| | 72 | |
| | 73 | |
| | 74 | == Test Plan == |
| | 75 | |
| | 76 | How the proposed change will be tested, if applicable. New unit tests should be detailed here??? |
| | 77 | |
| | 78 | == Funding/Resources == |
| | 79 | |
| | 80 | This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change. |
