Changes between Version 8 and Version 9 of MapGuideRfc94


Ignore:
Timestamp:
Jun 21, 2010, 2:35:40 PM (14 years ago)
Author:
brucedechant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc94

    v8 v9  
    1414||Implementation Status||pending||
    1515||Proposed Milestone||2.3||
    16 ||Assigned PSC guide(s)|| ||
     16||Assigned PSC guide(s)||Bruce Dechant||
    1717||'''Voting History'''|| ||
    1818||+1|| ||
    … …  
    2424== Overview ==
    2525
    26 It is proposed to incorporate within the MgCoordinateSystem interface the new features of MetaCRS/CS-MAP RFC 2.  The referenced CS-MAP RFC 2 proposes a major rework of how datum transformations are defined and is intended to 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 2 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
    2828There 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 transformation methods which could not be supported previously.
    … …  
    3434It 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 proposed to enable the above defined benefits to be added to the MgCoordinateSystem 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 !MgCoordinateSystem 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.
     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.
    4141
    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 listed 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).
     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 listed 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).
    4343
    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 ordered 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.
     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 ordered 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.
    4545
    46 * The referenced CS-MAP RFC 2 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.
     46 * The referenced CS-MAP RFC 2 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.
    4747
    4848== Implications ==
    4949
    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.
     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.
    5151
    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.
     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.
    5353
    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.
     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.
    5555
    56 * It is safe to say that existing applications which use the basic coordinate conversion interface will not see any change.
     56 * It is safe to say that existing applications which use the basic coordinate conversion interface will not see any change.
    5757
    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:
     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:
    5959
    60     * double MgCoordinateSystemGeodeticTransformation::GetOffsetX();
    61     * double MgCoordinateSystemGeodeticTransformation::GetOffsetY();
    62     * double MgCoordinateSystemGeodeticTransformation::GetOffsetZ();
    63     * void   MgCoordinateSystemGeodeticTransformation::SetOffset(double x, double y, double z);
    64     * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationX();
    65     * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationY();
    66     * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationZ();
    67     * double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformBwScale();
    68     * void   MgCoordinateSystemGeodeticTransformation::SetBursaWolfeTransform(double dRotationX, double dRotationY, double dRotationZ, double dBwScale);
    69     * INT32  MgCoordinateSystemGeodeticTransformation::GetGeodeticTransformationMethod();
    70     * void   MgCoordinateSystemGeodeticTransformation::SetGeodeticTransformationMethod(INT32 nGeodeticTransformationMethod);
     60{{{
     61double MgCoordinateSystemGeodeticTransformation::GetOffsetX();
     62double MgCoordinateSystemGeodeticTransformation::GetOffsetY();
     63double MgCoordinateSystemGeodeticTransformation::GetOffsetZ();
     64void   MgCoordinateSystemGeodeticTransformation::SetOffset(double x, double y, double z);
     65double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationX();
     66double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationY();
     67double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformRotationZ();
     68double MgCoordinateSystemGeodeticTransformation::GetBursaWolfeTransformBwScale();
     69void   MgCoordinateSystemGeodeticTransformation::SetBursaWolfeTransform(double dRotationX, double dRotationY, double dRotationZ, double dBwScale);
     70INT32  MgCoordinateSystemGeodeticTransformation::GetGeodeticTransformationMethod();
     71void   MgCoordinateSystemGeodeticTransformation::SetGeodeticTransformationMethod(INT32 nGeodeticTransformationMethod);
     72}}}
    7173
    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.
     74 * 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.
    7375
    7476== Test Plan ==
    7577
    76 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 produced 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.
     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 produced 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.
    7779
    78 == Funding/Resources ==
     80== !Funding/Resources ==
    7981
    8082Funded by, and development and quality assurance resources provided by, Autodesk.