Changes between Version 1 and Version 2 of CsMapRfc2

Timestamp:

Jun 9, 2010, 9:57:21 AM (14 years ago)

Author:

Norm Olsen

Comment:

Fix typos and spelling errors

CsMapRfc2

@@ -24 +24 @@
 == Overview ==
 
-The 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 I call 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 convert to produce the desired result.
+CS-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 I call 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.
 
-It is proposed that this "pivot datum" model be replaced with a model which closely resembles that used by EPSG.  In this new model geodetic transformations will defined as methods which will convert from a source datum to a target datum (without the implcation 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.
+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 implcation 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.
+
 == Motivation ==
-The "pivot datum" model has many limitations.  This is especially true given the manner in which transfromations driven by grid data files has been kludged into the model.  Additionally, those gedetic transformations which required multiple geodetic transformation operations were hard coded, making it impossible for end users to add (for example) new grid file transformations.  Basically, we want to do away with the concept of Geodetic Data Catalogs which were kludged in 12 years ago to address what is no a non-existent problem.
+
+The "pivot datum" model has many limitations.  This is especially true given the manner in which transformations driven by grid data files has been kludged into the model.  Additionally, those gedetic transformations which required multiple geodetic transformation operations were hard coded, making it impossible for end users to add (for example) new grid file transformations.  Further, we want to do away with the concept of Geodetic Data Catalogs which were kludged in 12 years ago to address what is now a non-existent problem.
 
 == Proposed Solution ==
 
-The proposed solution requires the implementation of two new dictionaries and the modification of the use of an existing dictionary.  To keep development costs within reason, there will be no changes in the format or interfaces provided for the four existing dictionaries.  Obvisoulsy, changing the basic moidel upon which a major chunk of code is based requires some hefty changes.  These are briefly described below:
+The proposed solution requires the implementation of two new dictionaries and the modification of the use of an existing dictionary.  To keep development costs within reason, there will be no changes in the format or interfaces provided for the four existing dictionaries.  Obviously, changing the basic moidel upon which a major chunk of code is based requires some hefty changes.  These are briefly described below:
 
-* A datum definition becomes a simple definition the existence of the datum and attached some meta data to that definition.  The "transformation to WGS84" portion of the existing datum definitions will be left unchanged and used for limited purposes such as WKT production.
+* A datum definition becomes a simple definition the existence of the datum and attaches some meta data to that definition.  The "transformation to WGS84" portion of the existing datum definitions will be left unchanged and used for limited purposes such as WKT production.
+
 * A new Geodetic Transformation dictionary will be implemented.  The significant properties of a definition in this new dictionary will be:
    * identified by a unique 57 character name
@@ -41 +44 @@
    * the number of supported parameters will be dramatically increased
    * the parameters in the definition will include references to grid data files as necessary
-* A new Geodetic Path Dictionary will be implemented.  An entry in this dictionary shall establish an ordered list (and the direction) of Geodetic Transformations necessary to accomplish a geodetic transformation from any datum to any other datum.  The principle purposes of an entry in this dictionary shall be:
+   * it is expect that a one to one correpsondence between entries in this dictionary and EPSG "coordinate operations" shall exist
+
+* A new Geodetic Path Dictionary will be implemented.  An entry in this dictionary shall establish an ordered list and the direction (i.e. forward/inverse) of Geodetic Transformations necessary to accomplish a geodetic transformation from any datum to any other datum.  The principle purposes of an entry in this dictionary shall be:
    * enables a means by which distributions and/or end users can specify a specific set of geodetic transformations where ambiguity exists
    * enables chaining of geodetic transformations where necessary (ATS77 -> NAD27 -> CSRS)
-* It is the intent of the redesign to include support for a substantial UI effort to enable users improved means of examining, modifying, and/or creating definitions in all (now) six dictionaries.  (This RFC does not include such UI, only support for such.)
-* All geodetic transformation code related to a grid data file (e.g. NTv2) will be refactored so as to be organized along file format lines as opposed to specific datum lines.
+
+* It is the intent of the redesign to include support for a substantial UI effort to enable users improved means of examining, modifying, and/or creating definitions of all (now) six dictionaries.  (This RFC does not include such UI, only support for such.)
+
+* All geodetic transformation code related to a grid data file (e.g. NTv2) will be refactored so as to be organized along file format lines as opposed to specific datums.
+
 * The actual transformation code will be refactored into a system of protocol consistent functions similar to that used for projections.  Thus, a geodetic equivalent of CS-MAP's projection table will be used to drive the redeisgned system.
+
 * Should funding and resources be sufficient, the redesign should enable the addition of several new geodetic transformation methods which were previously unsupportable.
+
+* It is intended that the current CS_dtcsu (datum conversion setup) function operate as follows (given the source and target datums):
+   * examine the Geodetic Path dictionary, and use any entry without further consideration
+   * locate a unique geodetic transformation which converts from the source to target and use it if such exists
+   * using a user definable pivot datum (or list thereof)(defaults to WGS84), locate a unique path from source to target and use if if such exists
+   * starting at the source and target, walk back to a common pivot datum providing there is no ambiguity
+   * should any or all of these methods fail to produce a unique geodetic transformation path from source to target, the setup fails.
 
 == Implications ==
 
-The proposed modifications do not include any cahanges to existsing interfaces, and all existing dictionaries will remain intact.  All forseen interface changes are adddtions to the existing API.  What does change, however, is the use of the Datum dictionary.  The transformation information contained in the datum dictionary will now be pretty much ignored; used only in special cases such as producing the "TOWGS84" KWT element.  Thus, existing applications which twiddle the datum dictionary entry and then perfrom conversions using such changes will be adversely affected; such a technique will not longer work.
+The proposed modifications do not include any cahanges to existsing interfaces, and all existing dictionaries will remain intact.  All foreseen interface changes are adddtions to the existing API.  What does change, however, is the use of the Datum dictionary.  The transformation information contained in the datum dictionary will now be pretty much ignored; used only in special cases such as producing the "TOWGS84" KWT element.  Thus, existing applications which twiddle the datum dictionary entry and then perform transformations using such changes will be adversely affected; such a technique will no longer work.
 
-Products using CS-MAP will need to distribute the new dictionaries, and quite possibly devise user interfaces to edit same.  Also, existing user interfaces which examine, modify, and/or create entries in the Datums dictionary will need to be reworked.
+Products using CS-MAP will need to distribute the new dictionaries, and quite likely devise user interfaces to edit same.  Also, existing user interfaces which examine, modify, and/or create entries in the Datums dictionary will need to be reworked.
 
 User documentation of applications using CS-MAP will require substantial rewrites as the functionality of the Datum dictionary changes, and there are two completely new dictionaries which have been created expressly for the purpose of enabling users to edit them.
@@ -61 +77 @@
 Subtantial opportunites for regression are inherent in this effort.  To insure against the development plan calls for the production of a data file of thousands of test data points to be generated using the existing library.  It is necessary for this data file to exercise most all datum conversion techniques and all currently supported variations.  A test module (such as the currently existsing Console Test mdoule Test 4 or somthing similar) will then be used to verify that there are no regressions in the actual calculations produced by the new and refactored code.
 
-Other aspects of this redesign will be test through normal Quality Assurance methods.
+Other aspects of this redesign will be tested through normal Quality Assurance methods.
 
 == Funding/Resources ==
 
-Funding, development, and quality assurance resources to be provided by Autodesk.
+Funding, development, and initial quality assurance resources to be provided by Autodesk.