Changes between Version 6 and Version 7 of MapGuideRfc94


Ignore:
Timestamp:
Jun 17, 2010, 2:01:00 PM (14 years ago)
Author:
NormOlsen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc94

    v6 v7  
    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 generality of geodetic transformations (i.e. datum shifts).
     26It is proposed to 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 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.  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.
     28There may be few changes to existing interfaces as described below, but mostly the effort will augment (rather than change) the existing interfaces.  Numerical results produced by the proposed changes will not change, nor will the performance of the package change in either direction.  Among other things, the proposed 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 ==
    … …  
    3232CS-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.
    3333
    34 It 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.
     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 for either the source or target) 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 geodetic transformation dictionary will provide an increase in the number of transformation parameters thus enabling implementation of new transformation methods which the lack of additional parameters prohibited.
    3535
    36 The 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.
     36The above motivations are the motivations of the referenced CS-MAP RFC #2 project.  This MapGuide RFC is proposed to enable the above defined benefits to be added to the MgCoordinateSysteme API of MapGuide.
    3737
    3838== Proposed Solution ==
    3939
     40* The reference CS-MAP RFC #2 proposes to introduce two new objects to the CS-MAP repetoire: a Geodetic Transformation object and a Geodetic Path object.
     41
     42* The existing MgCoordinateSystemGeodeticTransform object will be reworked to interface with this new CS-MAP equivalent and be associated with a new Geodetic Transformation Dictionary object as described below.  It is expected that the reworked interface will support all existing members of this interface; possible exceptions are linsted in the Implications section of this RFC.  As far as numeric results are concerned, the interface will not change.  There will be several additions to this interface enabling support of all transformation techniques (such as the grid file techniques).
     43
     44* A new MapGuide object will be implemented to interface with the new CS-MAP Geodetic Path object.  This new object will be connected to a new dictionary object as detailed below.  The interface for this object will enable the specification of an order list of one or more geodetic transformations as the means by which a complete datum shift from any defined datum to any other defined datum is to be accomplished.
     45
    4046* 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.
    4147
    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.
     48== Implications ==
    4349
    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.  They will not be replaced with anything.  You can retrieve and set the indicated values, but in the current implementation doing so has no effect on the calculations of the underlying object.  Nor can the modifed values be written at any dictionary (a geodetic transformation dictionary does not exist, YET!)
     50* The intent is to leave all existing interfaces and functionality undisturbed.  However, note that the two new objects will be provided as a means to access and maintain the underlying CS-MAP dictionary files.  All datum shift calculations will continue to be accomplished within the CS-MAP library.
     51
     52* Two additional dictionary files will need to be included in the MapGuide distribution, in the same folder as the current four dictionaries are distributed.
     53
     54* The performance of the "setup" portion of a geodetic transformation may be reduced (i.e. MgCoordinateSystemTransform constructor), but no effect on the actual performance of the conversion process is expected.
     55
     56* It is safe to say that existing applications which use the basic coordinate conversion interface will not see any change.
     57
     58* Applications which use the current API to manipulate dictionary entries may experience some small changes.  This will be due to the fact that the definition of a datum transformation will no longer reside in the Datum Dictionary and that a single geodetic transformation object may be only one of a series of transformations necessary to calculate the shift from source to target datums.  Such differences will not be apparent for geodetic transformations which are consistent with the current datum transformation model (i.e. using a pivot datum of WGS84).  A new and different behavior might be observed for new geodetic transformations which do not fit within this model.   The specific API's which might be affected are:
    4559
    4660    * double MgCoordinateSystemGeodeticTransformation::GetOffsetX();
    … …  
    5569    * INT32  MgCoordinateSystemGeodeticTransformation::GetGeodeticTransformationMethod();
    5670    * void   MgCoordinateSystemGeodeticTransformation::SetGeodeticTransformationMethod(INT32 nGeodeticTransformationMethod);
    57     * double MgCoordinateSystemGeodeticTransformation::GetMaxOffset();
    58     * bool   MgCoordinateSystemGeodeticTransformation::IsLegalOffset(double dOffset);
    59     * double MgCoordinateSystemGeodeticTransformation::GetMaxRotation();
    60     * bool   MgCoordinateSystemGeodeticTransformation::IsLegalRotation(double dRotation);
    61     * double MgCoordinateSystemGeodeticTransformation::GetBwScaleMin();
    62     * double MgCoordinateSystemGeodeticTransformation::GetBwScaleMax();
    63     * bool   MgCoordinateSystemGeodeticTransformation::IsLegalBwScale(double dBwScale);
    6471
    65 * Three new functions will be added to the API
    66     * INT32 MgCoordinateSystem::GetEpsgCode()
    67     * INT32 MgCoordinateSystem::GetEpsgQuadrant()
    68     * INT32 MgCoordinateSystem::GetSrid ()
    69 
    70 GetEpsgCode will return the EPSG Code of the CRS definition, returns 0 if such is not known
    71 GetEpsgCode will return the EpsgQuadrantCode which may be different from the CS-MAP quadrant code:
    72   0    X increases to the East, Y increases to the North
    73   1    X increases to the East, Y increases to the North
    74   2    X increases to the West, Y increases to the North
    75   3    X increases to the West, Y increases to the South
    76   4    X increases to the East, Y increases to the South
    77  -1   X increases to the North, Y increases to the East
    78  -2   X increases to the North, Y increases to the West
    79  -3   X increases to the South, Y increases to the West
    80  -4   X increases to the South, Y increases to the East
    81 GetEpsgCode will return the SRID code of the CRS definition, returns 0 if such is not known
    82 
    83 * An overload to the MgCoordinateSystemCatalog constructor will be added which will accept as its only parameter a string value which specifies the location of the dictionary folder.
    84 
    85 == Implications ==
    86 
    87 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 CS-MAP RFC #2.
    88 
    89 Two additional dictionary files will need to be included in the MapGuide distribution, in the same folder as the current four dictionaries are distributed.
    90 
    91 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.
     72* Since CS-MAP is now Open Source, it is possible (certainly not recommended) that there exist applications which access the CS-MAP library directly.  While the primary CS-MAP API will not change, certian lower level functions will necessarily change; thus such applications may be negatively affected.
    9273
    9374== Test Plan ==