Changes between Version 2 and Version 3 of MapGuideRfc94


Ignore:
Timestamp:
Jun 9, 2010, 1:57:41 PM (14 years ago)
Author:
NormOlsen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc94

    v2 v3  
    2424== Overview ==
    2525
    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).
     26Incorporate 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).
    2727
    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.
     28There 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.
    2929
    3030== Motivation ==
    3131
    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.
     32Usability 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.
    3333
    3434== Proposed Solution ==
    … …  
    3636* 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.
    3737
    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.
     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.
    3939
    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.
     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.
    4141
    4242* 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.
    … …  
    4444* 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.
    4545
    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.
    4747
    4848    * double MgCoordinateSystemGeodeticTransformation::GetOffsetX();
    … …  
    6565    * bool   MgCoordinateSystemGeodeticTransformation::IsLegalBwScale(double dBwScale);
    6666
    67 
    6867 
    6968== Implications ==
    7069
    71 As there
     70Several 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.
    7271
     72Installation 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
     74The 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.
    7375
    7476== Test Plan ==
    7577
    76 How the proposed change will be tested, if applicable.  New unit tests should be detailed here???
     78The 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
     80To 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
     82The 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.
    7783
    7884== Funding/Resources ==
    7985
    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.
     86Funded by, and development and quality assurance resources provided by, Autodesk.