Showing results for 
Search instead for 
Do you mean 

Datum Transformation Using the autodt.ini File

by on ‎06-10-2016 01:33 PM (1,647 Views)

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[,GridFileName]

 

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,DeltaX,DeltaY,DeltaZ,OmegaX,OmegaY,OmegaZ,RotationOriginX,RotationOriginY,RotationOriginZ

 

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,DeltaX,DeltaY,DeltaZ,OmegaX,OmegaY,OmegaZ

 

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,DeltaX,DeltaY,DeltaZ[,DeltaEqatorialRad,DeltaFlattening,[FwdInputEllipsoid[,Eccentricity,EqatorialRadius]]]

 

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,ComplexPolynomialModelType

 

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,ModelForwardInputUnitID,ModelForwardOutputUnitID,ForwardInputSpaceXofOrigin,ForwardInputSpaceYofOrigin,XNormalizationFactor,YNormalizationFactor,a0,a1,a2,b0,b1,b2

 

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,ModelForwardInputUnitID,ModelForwardOutputUnitID,ForwardInputSpaceXofOrigin,ForwardInputSpaceYofOrigin,XNormalizationFactor,YNormalizationFactor,a0,a1,a2,a3,a4,a5,b0,b1,b2,b3,b4,b5

 

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,ProgID=<value>;[OptionalParam1=<value>;...]

 

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.

 

Comments
by
on ‎01-17-2020 07:54 AM

Hi,

 

 

Is it possible to use autodt.ini for transformation between several local custom projection CS?

Pls. find my post here:  https://community.hexagongeospatial.com/t5/GeoMedia-Discussions/Local-Coordinate-System-transformati... 

 

Thank you,

Kirill

Contributors