Changes between Version 2 and Version 3 of MapGuideRfc94
- Timestamp:
- 06/09/10 13:57:41 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc94
v2 v3 24 24 == Overview == 25 25 26 Incorporate within the MgCoordinateSystem interface the features of MetaCRS/CS-MAP RFC - 2. The referenceCS-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).26 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). 27 27 28 There will be no change to any existing interface, although a fewinterface 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.28 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. 29 29 30 30 == Motivation == 31 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.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 correcting this situation. The changes proposed here are necessary to expose these changes to the affected applications. 33 33 34 34 == Proposed Solution == … … 36 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 37 38 * In order to support the enhanced UI components to be added to added to MgCoordinateSystem based applications, the enumerato e 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.38 * 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. 39 39 40 * For perfor amance 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 enableselection 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.40 * 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. 41 41 42 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. … … 44 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 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) :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). As currently implemented, these functions accomplish very little. 47 47 48 48 * double MgCoordinateSystemGeodeticTransformation::GetOffsetX(); … … 65 65 * bool MgCoordinateSystemGeodeticTransformation::IsLegalBwScale(double dBwScale); 66 66 67 68 67 69 68 == Implications == 70 69 71 As there 70 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. 72 71 72 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. 73 74 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. 73 75 74 76 == Test Plan == 75 77 76 How the proposed change will be tested, if applicable. New unit tests should be detailed here??? 78 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. 79 80 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. 81 82 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. 77 83 78 84 == Funding/Resources == 79 85 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.86 Funded by, and development and quality assurance resources provided by, Autodesk.
