Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Article History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content

Labels:

**General Background**

Datum transformations are needed when data must be converted between two different coordinate reference systems that are defined with reference to different horizontal or vertical datum values. The *autodt.ini* file is used for the automatic generation of datum transformations during the building of certain coordinate system transformation paths, such as the transformation path between a display coordinate reference system and a storage coordinate reference system. This file is typically located in either the *C:\Program Files\Common Files\Intergraph\Coordinate Systems\3.0\Config* folder or the *C:\Program Files (x86)\Common Files\Intergraph\Coordinate Systems\3.0\Config* folder. On a 64-bit operating system it is possible to find it in both folders if the machine has installations of both 32- and 64-bit applications that use this transformation software.

**How the autodt.ini File is Used**

When datum transformation is needed to transform coordinates between a specific set of datum values the entries from this file are used to create an internal network graph of the datum transformation possibilities and the shortest path through the graph is used to choose the desired set of datum transformations. Where no single datum transformation exists to convert between the desired datum values the software may internally concatenate multiple datum transformations to do the work. When building the graph this file is processed in order from top to bottom. Where more than one file entry exists to transform between a given set of datum values, only the first entry will be used. The other entries exist so that users may customize the behavior of the software by changing the order of file entries in order to cause a different model or definition to be used. Note that all datum transformation models are capable of transforming in both the forward and inverse directions. Thus, for example, an entry which begins "*csgdNAD27,csvdNAVD88,csgdNAD83,csvdNAVD88,...*" will match a search for a transformation to go from NAD83 to NAD27 as well as matching a search for a transformation to go from NAD27 to NAD83.

When you edit *autodt.ini* the changes will not affect any process that is currently running. This is because the coordinate transformation software reads the file only at startup time, so if the file is altered afterwards, the process will not know about the alteration until the next time the process is run.

When you edit *autodt.ini* the changes will not affect multi-coordinate reference system transformations that have already been persisted in a product's data store. This is because the coordinate transformation software uses *autodt.ini* only to build new datum transformations. Any datum transformations that have already been created and saved will not be affected by the changes to *autodt.ini*.

**Organization of Entries Within the autodt.ini File**

The vast majority of the entries in this file deal exclusively with horizontal geodetic datum transformation (most vertical transformation entries are near the end). These horizontal transformations typically ignore height coordinates and pass them through unchanged, leaving intact whatever vertical datum definition they happen to encounter. However, to be able to assemble the internal network graph of transformation possibilities we require valid vertical datum information on all entries in this file. Therefore, most of the horizontal transformation entries in this file are defined with a vertical datum that matches a past or present default value and is thus likely to be encountered in data that uses default values for vertical datum. Older data used *csvdUserDefined* as the default (this includes earlier versions of this software when vertical datum was not exposed). Current data is likely to use *csvdEGM* as the default vertical datum. If you are explicitly using other vertical datum values you should include appropriate horizontal transformation entries in this file that reference the vertical datum values that you use.

The order of entries in the *autodt.ini* file generally places horizontal transformations in order of the typical accuracy of the general transformation type. Thus we list gridded transformations, then ten-parameter transformations, then seven-parameter transformations, then Standard Molodensky transformations. Other less-often used models follow, regardless of their generally acknowledged accuracy (polynomials, multiple regression, etc.).

**Syntax**

The syntax for an entry in autodt.ini is:

[;]*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*DatumTransModelType*[,*model-specific-parameters...*]

Each entry must be entirely contained on one line. A semicolon in the first column denotes a comment line. Fields are separated by the comma character. This file is never localized for different languages, rather, it is always interpreted in English (uses comma for field separator, dot for decimal character). No thousands grouping character is used. Floating point values are never written in scientific notation.

Horizontal datum values are defined using the ascii mnemonics from the **CSGeodeticDatumConstants** enumeration and named horizontal datum names from the *NamedHDatum.ini* configuration file. (The *NamedHDatum.ini* file is found in the same folder as *autodt.ini*.) The mnemonics must be used for standard (preset) horizontal datum values, and the values *csgdNamed* and *csgdUndefined* cannot be used. For named horizontal datum values, the named datum names should be used exactly as they are defined in the *NamedHDatum.ini* configuration file.

Vertical datum values are defined using the ascii mnemonics from the **CSVerticalDatumConstants** enumeration.

Datum transformation model types are defined using the ascii mnemonics from the **CSDatumTransformationModelConstants** enumeration.

The values for the mnemonics for datum transformation model types, horizontal geodetic datum values, vertical datum values, ellipsoids complex polynomial model types, and units may be found in the **Intergraph Coordinate Systems API Reference** document within the topics describing each enumeration. More information regarding datum transformation models may be found in the **Intergraph Coordinate Systems Help** document within the **Coordinate System Information Appendix** in the **Datum Transformation Models** topic.

** **

**Model-specific Details**

** **

**Canadian National (NTv2)**

The syntax for the NTv2 transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdtCanadianNational**[,

Beginning with the 3.0 release of the *Intergraph Coordinate Systems* component, this entry may contain the optional *GridFileName* parameter. This release is a component of some **Hexagon Geospatial** products (including *GeoMedia* and *APOLLO*) beginning with release 15.0 and is also a component of **Hexagon Safety & Infrastructure**’s *G/Technology* product beginning with release 10.2.1. When present, this parameter is the name.extension of the binary grid file to be used with the transformation defined by that particular *autodt.ini* entry. The parameter names a grid file located in the *...\Coordinate Systems\3.0\Config\Canada* folder. When the parameter is not present the software, as in previous releases, determines the grid file name by reading the *area.ini* file contained in the same folder. That *area.ini* file contains the name, without extension, of a grid file to be used when one is not specified using the optional parameter of the *autodt.ini* entry.

Note that the NTv2 transformation as originally defined for Canadian usage defines the forward direction as transforming from NAD27 to NAD83. All NTv2 entries for this usage are required to follow this convention and list NAD27 (or the named datum based on NAD27) as the *ForwardInputHorizontalDatum* and list NAD83 (or the named datum based on NAD83) as the *ForwardOutputHorizontalDatum*. Use of NTv2 as defined by other agencies for transformation between other horizontal datum values is as defined by the agencies that produce the associated grid files.

**NADCON (Version 2.10)**

The NADCON transformation has two variants, with the following syntax:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*csdtNADCONforNAD27toNAD83*

and

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*csdtNADCONforNAD83toHARN*

The NADCON model requires no model-specific parameters. The first NADCON variant defines the forward direction as transforming from NAD27 to NAD83. All NADCON entries for this usage are required to follow this convention and list NAD27 (or the named datum based on NAD27, or in certain cases the old island datum) as the *ForwardInputHorizontalDatum* and list NAD83 (or the named datum based on NAD83) as the *ForwardOutputHorizontalDatum*. The second NADCON variant defines the forward direction as transforming from NAD83 to NAD83-HARN. All entries for these models are required to follow this convention and list NAD83 (or the named datum based on NAD83, or in certain cases the old island datum) as the *ForwardInputHorizontalDatum* and list NAD83-HARN (or the named datum based on NAD83-HARN) as the *ForwardOutputHorizontalDatum*.

**Molodensky-Badekas (10-parameter)**

The syntax for the Molodensky-Badekas (10-parameter) transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdtMolodenskyBadekas**,

*DeltaScale* is unitless. *DeltaX*, *DeltaY*, *DeltaZ*, *RotationOriginX*, *RotationOriginY*, and *RotationOriginZ* are expressed in meters. *OmegaX*, *OmegaY*, and *OmegaZ* are expressed in radians, and represent rotations of the coordinate axes.

Some agencies publish 10-parameter transformations where the rotations represent rotation of position around the coordinate axes. To use such parameters here, change the signs of the three rotation parameters (*OmegaX*/*Y*/*Z*). Expressed in terms of the *OGP Surveying and Positioning Guidance Note 7.2* document, parameters published for the "Coordinate Frame Rotation" transformation may be used here after conversion into the appropriate units, while parameters published for the "Position Vector" transformation may be used here by conversion into the appropriate units and reversing the signs of the three rotations.

Regarding the Shifts (*DeltaX/Y/Z*) and rotation origin, there are two commonly referenced formulae with differing definitions. The implementation here derives from the (U.S.) *National Geospatial-Intelligence Agency* formula ( http://earth-info.nga.mil/GandG/coordsys/datums/molodensky.html ) which defines the shifts as a translation between the rotation origin (which is relative to source system origin) and the destination system origin. In contrast, *OGP Guidance Note 7.2* defines the shifts as a translation between source system origin and destination system origin. Thus when given parameters in the GN 7.2 formula, to use them here you should add each rotation origin ordinate to the corresponding shift to obtain the shift parameter values (and then use the rotation origin values un-altered as the separate rotation origin parameters).

**Bursa-Wolf (7-parameter)**

The syntax for the Bursa-Wolf (7-parameter) transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdtBursaWolf**,

*DeltaScale* is unitless. *DeltaX*, *DeltaY*, and *DeltaZ* are expressed in meters. *OmegaX*, *OmegaY*, and *OmegaZ* are expressed in radians, and represent rotations of the coordinate axes. Some agencies publish 7-parameter transformations where the rotations represent rotation of position around the coordinate axes. To use such parameters here, change the signs of the three rotation parameters. Expressed in terms of the *OGP Surveying and Positioning Guidance Note 7.2* document, parameters published for the "Coordinate Frame Rotation" transformation may be used here after conversion into the appropriate units, while parameters published for the "Position Vector" transformation may be used here by conversion into the appropriate units and reversing the signs of the three rotations.

**Standard Molodensky (Geocentric Shifts)**

The syntax for the Standard Molodensky (geocentric shifts) transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdtStandardMolodensky**,

For Standard Molodensky, *DeltaX*, *DeltaY*, and *DeltaZ* are always required, and are expressed in meters. These three parameters may be used for parameters published as geocentric shifts. If both the Forward Input datum and the Forward Output datum are well-known models (neither is "undefined" or "user-defined"), no further parameters are required. Otherwise, you must supply the Delta Equatorial Radius (in meters) and Delta Flattening (unitless) parameters (ellipsoid parameter of Forward Output ellipsoid minus ellipsoid parameter of Forward Input ellipsoid). Additionally, if the Forward Input datum is not a well-known model, the Forward Input ellipsoid model must be supplied, and if it is given as *cseUserDefined*, the eccentricity (unitless) and equatorial radius (in meters) of the Forward Input ellipsoid must be supplied.

**Complex Polynomial**

The syntax for the Complex Polynomial transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdtComplexPolynomial**,

Complex Polynomial model types are defined using the ascii mnemonics from the **CSComplexPolynomialModelConstants** enumeration.

Note that all of these models transform between a common datum such as European 1950 and local datum values which generally are not specifically available in our system. Therefore these unavailable local datum values are often identified as *csgdUserDefined*. Where more is known regarding the local datum a named datum (using a value added to the *NamedHDatum.ini* file) should be used for clarity and to differentiate between what would otherwise be unknown or incompatible uses of *csgdUserDefined*.

Note also that these are intended for very special local cases, where the data being transformed is expected to be in specific local projected coordinates, being transformed to specific grid system or Universal Transverse Mercator zone coordinates. Thus, accidental usage of these complex polynomials in cases where the coordinate systems are not defined to the appropriate projection definitions will result in very unpredictable results. These entries have therefore all been commented out in the delivered *autodt.ini* file, with the intent that those who have the specific need will un-comment the single model which applies to their usage.

**Second Degree Conformal Polynomial**

The syntax for the Second Degree Conformal Polynomial transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdt2ndDegConformalPolynomial**,

For the Second Degree Conformal Polynomial, all of the above fields are required. The *ModelForwardInputUnitID* and *ModelForwardOutputUnitID* are both defined using the ascii mnemonics from the **UnitConstants** enumeration, choosing from linear type units. If user-defined units need to be used, the actual numeric value for the Unit ID should be used (since there is no mnemonic). The X and Y origin coordinates for the forward input space should be expressed in the model forward input unit. The normalization factors and polynomial coefficients (*a0*-*a2* and *b0*- *b2*) are unitless, but are assumed to have been calculated with respect to coordinates in the respective input and output units.

Note that Second Degree Conformal polynomial entries are intended for very special local cases, where the data being transformed is expected to be in specific projected coordinates, being transformed to other specific projected coordinates. Thus, accidental usage of the Second Degree Conformal polynomial in cases where the coordinate systems are not defined to the appropriate projection definitions will result in very unpredictable results. Also note that the polynomial equations assume they are operating between right-handed reference spaces. In cases where an agency publishes parameters with respect to projected coordinates where the projected coordinate reference system is not right-handed (+East, +North) the polynomial parameters will require adjustment.

The Second Degree Conformal polynomial may be used to accomplish a Helmert transformation between projected coordinates of two different reference spaces. In such a case, the unused coefficients (*a2* and *b2*) are set to zero. Examples of Helmert transformation are included in the delivered *autodt.ini* file.

**Second Degree General Polynomial**

The syntax for the Second Degree General Polynomial transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdt2ndDegGeneralPolynomial**,

For the Second Degree General Polynomial, all of the above fields are required. The *ModelForwardInputUnitID* and *ModelForwardOutputUnitID* are both defined using the ascii mnemonics from the **UnitConstants** enumeration, choosing from linear type units. If user-defined units need to be used, the actual numeric value for the Unit ID should be used (since there is no mnemonic). The X and Y origin coordinates for the forward input space should be expressed in the model forward input unit. The normalization factors and polynomial coefficients (*a0*-*a5* and *b0*-*b5*) are unitless, but are assumed to have been calculated with respect to coordinates in the respective input and output units.

Note that Second Degree General polynomial entries are intended for very special local cases, where the data being transformed is expected to be in specific projected coordinates, being transformed to other specific projected coordinates. Thus, accidental usage of the Second Degree General polynomial in cases where the coordinate systems are not defined to the appropriate projection definitions will result in very unpredictable results. Also note that the polynomial equations assume they are operating between right-handed reference spaces. In cases where an agency publishes parameters with respect to projected coordinates where the projected coordinate reference system is not right-handed (+East, +North) the polynomial parameters will require adjustment.

The Second Degree General polynomial may also be used to accomplish a Helmert transformation between projected coordinates of two different reference spaces. In such a case, the unused coefficients (*a3*-*a5* and *b3*-*b5*) are set to zero and two of the Helmert parameters will be repeated, with a sign change on one of them. The Second Degree General polynomial may also be used to accomplish an Affine transformation between projected coordinates of two different reference spaces. In such a case, the unused coefficients (*a3*-*a5* and *b3*-*b5*) are set to zero. However, depending upon the content of the transformation (contains skew or not, etc.) there may or may not be repetition of parameters (as seen emulating Helmert).

**User-Supplied Transformation**

The syntax for the User-Supplied transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,** csdtUserSupplied**,

The entire string which begins with "*ProgID=*" and continues to the end of the line will be used to set the **UserSuppliedConfigurationParameters** property on the **DatumTransformation** object. The **UserSuppliedConfigurationParameters** string consists of a semicolon-delimited sequence of name-value pairs in the form of "name=value;". The first such name-value pair is required to have the name "*ProgID*" and its value specifies the ProgID for a user-created object which implements the user-supplied datum transformation and has properties and methods conforming to the **IGMUserSuppliedTransformation** interface specification. The presence and number of optional parameters is defined by the user-supplied object identified by the given *ProgID*. For more details, please see the **Intergraph Coordinate Systems API Reference** document regarding the **IDatumTransformation.UserSuppliedConfigurationParameters** method, and, within the **Intergraph Coordinate Systems Help** document see the “User-Supplied Transformation Programming Help” set of topics.

If a User-Supplied datum transformation is capable of more than one basic action (not counting a typical inverse direction as a separate action) then for it to be useable in *autodt.ini* it must be possible to restrict its actions based upon its configuration parameter string. For example, if the object is capable of transforming between horizontal datum values A and B and also capable of transforming between vertical datum values C and D, then it must be possible to create two distinct *autodt.ini* entries where the configuration strings differ, where one entry invokes the horizontal A to B functionality and the other entry invokes the vertical C to D functionality. Furthermore, if, for example, the object is capable of transforming between vertical datum values C and D using either geographic or projected type points, those must also be considered as two distinctly configurable capabilities.

**Vertical Transformation between Geoid and Ellipsoid**

Three datum transformation models transform vertical coordinates between geoid-based (orthometric) and ellipsoid-based (geometric) height reference. These models, NGA Earth Gravity Model (EGM96), GEOID (NGS hybrid geoid), and USGG (NGS gravimetric geoid) share similar syntax:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*csdtNGAEGM*

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*csdtNGSGEOID*

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*csdtNGSUSGG*

There are no model-specific parameters. All three models define the forward direction as transforming from orthometric to geometric height type. All entries for these models are required to follow this convention and list the orthometric vertical datum as *ForwardInputVerticalDatum* and the geometric vertical datum as *ForwardOutputVerticalDatum*.

**VERTCON (Version 2.10)**

The syntax for the VERTCON transformation is:

*ForwardInputHorizontalDatum*,*ForwardInputVerticalDatum*,*ForwardOutputHorizontalDatum*,*ForwardOutputVerticalDatum*,*csdtVERTCON*

There are no model-specific parameters. The VERTCON orthometric vertical datum transformation defines the forward direction as transforming from the National Geodetic Vertical Datum 1929 (*csvdNGVD29*) to the North American Vertical Datum 1988 (*csvdNAVD88*), so all entries for this model are required to follow this convention and list *csvdNGVD29* as *ForwardInputVerticalDatum* and *csvdNAVD88* as *ForwardOutputVerticalDatum*.

Rate this article:

1 Comment (1 New)

Hide Comment

Comments