Re: [netcdf-java] [CF-metadata] ESRI implementation of ellipsoidal-earth

Hello again

Close. A method to transform lat/long on one *datum* to lat/lon on another.
Many different datum may exist for the same ellipsoid. The ellipsoid axis length alone are not suffisient.

ok, so if i understand, a datum might just use the ellipsoid as the datum, but others may specify a different surface, but possibly using some ellipsoid as a reference. Is that accurate?
Not exactly... The surface is always the ellipsoid; we don't try to make more complicated surface (the more complicated surface would be a "geoid", but this is an other topic). What may change between different datum is the origin of the coordinate system. For example I found 61 different datum in the EPSG database using the "GRS 1980" ellipsoid. Below is a few examples. Let emphase that all those 61 datum use exactly the same "GRS 1980" ellipsoid!

Datum name                    Origin
--------------------  ------------------------
Taiwan Datum 1997        ITRF94 at epoch 1997.0
Mexican Datum of 1993  ITRF1992 at epoch 1988.00
IRENET95                        ETRS89 stations in Ireland
Latvia 1992 Constrained to 4 ETRS89 points in Latvia from the EUREF Baltic 1992 campaign. Estonia 1997 Densification of ETRS89 during EUREF-ESTONIA97 campaign through transformation from ITRF96 at epoch 1997.56
... 56 more ...

An ellipsoid is only a mathematical thing. A datum is:

   * Choosing a point on the ellipsoid, not necessarily the 0°N,0°E coordinate
     - countries will typically choose a (latitude,longitude) on their 
   * Specify where on Earth the above point is located, typically through
     campaign and marks put in the real world.

Consequently, the coordinate 20°N 30°W (for example) according the "Mexican Datum of 1993" may be at a slightly different place than the same coordinate according the "IRENET95" datum; *even if the ellipsoid is exactly the same for both datum*, because the *origin* of the coordinate system is located at a slightly different place. The error depends on the particular pair of datum being considered, but a 1 km error can be considered typical (I not sure if the same error magnitude apply for datum having the same ellipsoid however, but some error remain anyway).

Transforming coordinates from one datum to the other is more complicated than just shifting the origin. Actually the way the ellipsoid is "linked" to the Earth is determined empirically though "real world" campaigns, and the result vary between different countries because the campaigns were done in different landscapes. The most accurate transformations from one datum to an other is to interpolate in an empirical grid. For example the transformation between NAD27 and NAD83 (two datums used by USA) is nicely illustrated there:

You can see from the pictures that the shift between those two datum is really not a simple mathematical function.

An *approximation* of datum shift is often performed by the following methods:

   * Convert geographic coordinates to geocentric coordinates
   * Apply a scale, translation and rotation of *geocentric* coordinates by
     some amount specified empirically (as "Bursa-Wolf parameters") for some
     pairs of datum.
   * Convert back the resulting geocentric coordinates to geographic 

As said above, if those steps are ignored, the error is typically 1 km (sometime less, sometime more). It may be acceptable or not depending on the application... A possible approach would be to keep NetCDF referencing relatively simple, while allowing user to use an other referencing libraries if they need more precision.



  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: