Changes between Version 4 and Version 5 of MapGuideRfc94


Ignore:
Timestamp:
Jun 14, 2010, 5:05:50 PM (14 years ago)
Author:
NormOlsen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc94

    v4 v5  
    2424== Overview ==
    2525
    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).
     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 generality of geodetic transformations (i.e. datum shifts).
    2727
    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.
     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.  These changes will increase the number of parameters supported for a geodetic transformation, thus enabling the implementation of additional tranformation methods which could not be supported previously.
    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 correcting this situation.  The changes proposed here are necessary to expose these changes to the affected applications.
     32CS-MAP's existing datum transformation model is an anachronism dating back to DMA TR-8350.2-B, December 1987 (TR == Technical Report). It is based on the concept of using WGS84 as what is referred to as a "pivot datum".  All geodetic transformations are defined as part of a datum definition, where the datum definition carries the method and parameters necessary to convert from the datum being defined to WGS84. A complete geodetic transformation is currently accomplished (usually) by using the forward method of the source datum to convert to WGS84 and the inverse method of the target datum to produce the desired result.
     33
     34It is proposed that this "pivot datum" model be replaced with a model which closely resembles that used by EPSG. In this new model a geodetic transformation definition will associate a geodetic method with the appropriate parameters which will convert from a source datum to a target datum (without the implication of using WGS84 or any other pivot datum) and the concept of a geodetic transformation path which enable the specification of an ordered list of geodetic transformations as the means to convert from any datum to any other.  The new geodetiv transformation dictionary will provide anincrease in the number of transformation parameters thus enabling implementation of new transformation methods which the lack of additional parameters prohibited.
     35
     36The above motivations are the motivations of the referenced CS-MAP RFC #2 project.  This MapGuide RFC is prposed to enable the above defined benefits to be added to the MgCoordinateSysteme API of MapGuide.
    3337
    3438== Proposed Solution ==
    3539
    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.
     40* 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 would to be added to the MgCoordinateSystem interface.
    3741
    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.
     42* 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.  This would not alter any existing interface, simply add an additional interface more conistent with a multi-pltform product environment.
    3943
    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 
    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).  As currently implemented, these functions accomplish very little.
     44* 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. continued to be supported, but documented as will be removed in future releases).  As currently implemented, these functions accomplish very little.  You can retrieve and set the indicated values, but in the current implementation doing so has no effecton the calculations of the underlying object.  Nor can the modifed values be written at any dictionary (a geodetic transformation dictionary does not exist, YET!)
    4745
    4846    * double MgCoordinateSystemGeodeticTransformation::GetOffsetX();
    … …  
    6563    * bool   MgCoordinateSystemGeodeticTransformation::IsLegalBwScale(double dBwScale);
    6664
    67  
    6865== Implications ==
    6966
    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.
     67Several 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 CS-MAP RFC #2.
    7168
    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.
     69Two additional dictionary files will need to be included in the MapGuide distribution, in the same folder as the current four dictionaries are distributed.
    7370
    7471The 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.
    … …  
    7875The 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.
    7976
    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.
    83 
    8477== Funding/Resources ==
    8578