[Geotiff] Encoding of "ETRS89 / ETRS-LAEA" (i.e. EPSG:3035)

Thu Jun 5 12:41:37 EDT 2008

Frank,

Thanks for your swift reply. Let me step in here and continue the topic also
on behalf of Pierre.
For us it is extremely important to be sure about our interpretation of the
GeoTiff rules, as we want to create an interoperable standard file type for
our projection(s).

Your advice is to "just use 3035 as the PCS and leave it at that". That's
what we thought we could do. Consulting the GeoTiff reference
http://www.remotesensing.org/geotiff/spec/geotiff2.7.html
we figured we should set the ProjectedCSTypeGeoKey (KeyID 3072) to 32767
i.e. 'user defined', give the projection a (not too arbitrary) name in the
PCSCitationGeoKey (KeyID 3073, which is required in this case, see below)
and store all relevant parameters in the ProjectionGeoKey and the following
Keys (3074-3089).
|---------------------------------------------
|ProjectedCSTypeGeoKey
|
|Key ID = 3072
|Type = SHORT (codes)
|Values:  Section 6.3.3.1 codes
|
|This code is provided to specify the projected coordinate system.
|
|GeoKey requirements for "user-defined" PCS families:
|   PCSCitationGeoKey
|   ProjectionGeoKey
|----------------------------------------------
|----------------------------------------------
|PCSCitationGeoKey
|Key ID = 3073
|Type = ASCII
|
|As with all the "Citation" GeoKeys, this is provided to give an ASCII
|reference to published documentation on the Projected Coordinate System
|particularly if this is a "user-defined" PCS.
|----------------------------------------------

In the PCSCitationGeoKey, we'd rather put a name ("ETRS89 / ETRS-LAEA" to be
consistent with EPSG) than a number thus staying consistent with other
couples such as the GeographicTypeGeoKey (2048) and the GeogCitationGeoKey
(2049)

We get a nice and consistent GeoTiff although some information is redundant,
as you indicated in your answer. This shouldn't hurt as long as there are no
contradictions. We prepared a sample of such a GeoTiff file at:
http://www.ec-gis.org/sdi/seminar/geotiff-sample.tif

The GeoKeys as obtained from this e.g. by listgeo are:

   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,9): "JRC-EGCS"
      GeographicTypeGeoKey (Short,1): GCS_EUREF89
      GeogCitationGeoKey (Ascii,7): "ETRS89"
      GeogGeodeticDatumGeoKey (Short,1):
Datum_European_Reference_System_1989
      GeogPrimeMeridianGeoKey (Double,1): 8901              
      GeogLinearUnitsGeoKey (Short,1): Linear_Meter
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      GeogEllipsoidGeoKey (Short,1): Ellipse_GRS_1980
      GeogSemiMajorAxisGeoKey (Double,1): 6378137          
      GeogInvFlatteningGeoKey (Double,1): 298.2572221       
      GeogPrimeMeridianLongGeoKey (Double,1): 0                
      ProjectedCSTypeGeoKey (Short,1): User-Defined
      PCSCitationGeoKey (Ascii,19): "ETRS89 / ETRS-LAEA"
      ProjectionGeoKey (Short,1): User-Defined
      ProjCoordTransGeoKey (Short,1): CT_LambertAzimEqualArea
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      ProjFalseEastingGeoKey (Double,1): 4321000          
      ProjFalseNorthingGeoKey (Double,1): 3210000          
      ProjCenterLongGeoKey (Double,1): 10               
      ProjCenterLatGeoKey (Double,1): 52               
    End_Of_Keys.

Unfortunately most software on earth seems not capable to read such a
GeoTiff properly (or better: the way we think it should be read).
Even gdal holds a surprise. If processed by gdal, which usually means a
transformation of the projection information into wkt format (right?) the
following result is achieved:   

PROJCS[JRC-EGCS,
       GEOGCS[ETRS89,
              DATUM[European_Terrestrial_Reference_System_1989,
                    SPHEROID[GRS1980,6378137,298.2572221000027,
                             AUTHORITY[EPSG,7019]],
                    AUTHORITY[EPSG,6258]],
                    PRIMEM[Greenwich,8.190126211110344e-320],
                    UNIT[degree,0.0174532925199433],
                    AUTHORITY[EPSG,4258]],
       PROJECTION[Lambert_Azimuthal_Equal_Area],
       PARAMETER[latitude_of_center,52],
       PARAMETER[longitude_of_center,10],
       PARAMETER[false_easting,4321000],
       PARAMETER[false_northing,3210000],
       UNIT[metre,1,AUTHORITY[EPSG,9001]]]

This means that the PCSCitationGeoKey gets obviously lost. Instead the
GTCitationGeokey (KeyID 1026) is quoted in the "PROJCS" field, pretending it
is describing the projection.

Why is this? All other parameters found in the PROJCS block (with the
exception of the sub-blocks) are from Projection Keys (30xx) it seems
illogic to refer to the citation key 1026 especially keeping in mind that
then the citation key 3073 is ignored.

We wanted to use the GTCitationGeoKey to indicate that that the given
GeoTiff file is (or pretends to be) written according to our proposed
scheme. (This, by the way covers different projections and foresees a number
of fixed grids.)

If this key overwrites the projection name in e.g. a gdal_translate
operation we are in trouble as the projection is no longer called the same.

Is there a problem in our understanding of the GeoTiff rules?
If yes, how can we better (i.e. more consistent and interoperable) encode
the projection?
And if not, what should we do?

Any advice how to solve this will be greatly appreciated!

Thanks again and best regards from rainy Italy

Peter

-----Original Message-----
From: geotiff-bounces at lists.maptools.org
[mailto:geotiff-bounces at lists.maptools.org] On Behalf Of Frank Warmerdam
Sent: 04 June 2008 17:03
To: Pierre Soille
Cc: geotiff at lists.maptools.org
Subject: Re: [Geotiff] Encoding of "ETRS89 / ETRS-LAEA" (i.e. EPSG:3035)

Pierre Soille wrote:
> 
> The problem we face is how to encode the "ETRS89 / ETRS-LAEA"
> (i.e. EPSG:3035) projection 'correctly' into GeoTiff Keys (see
> http://www.ec-gis.org/sdi/publist/pdfs/annoni-etal2003eur.pdf for the
> definition of this projection).
> 
>  From http://www.remotesensing.org/geotiff/spec/geotiff6.html#6.3.3.1
> we could not find any ProjectedCSTypeGeoKey code for this projection.
> Therefore, one is forced to user-define all relevant parameters. 

Pierre,

It is common practice to use PCS and GCS codes that have been added to
EPSG even though they do not appear in the GeoTIFF specification.  So
my primary advice is to just use 3035 as the PCS and leave it at that.

There is some danger in doing this for very recent codes, in that older
software packages (or new packages without an EPSG update) won't recognise
the coordinate system.  But I see that 3035 has been around since at least
EPSG 6.13.

> In any case, we would also be grateful for feedback on the purpose and
> proper use of the 'GTCitationGeoKey' and the 'PCSCitationGeoKey' which
> often are used quite arbitrarily.

These citations are pretty arbitrary.

> GeograpicTypeGeoKey
> 
> 4258
> 
> EPSG parameter COORD_REF_SYS_CODE for COORD_REF_SYS_NAME 'ETRS89', GeoTIFF
> label is 'GCS_EUREF89'
...
> GeogGeodeticDatumGeoKey
> 
> 6258
> 
> EPSG DATUM_CODE for  DATUM_NAME 'European Terrestrial Reference System
> 1989', GeoTIFF label is 'Datum_European_Reference_System_1989'"

Note that datum, prime meridian, etc are all implicit in the
GeographicTypeGeoKey value of 4258.  There is no harm in explicitly
defining them, but in theory it is not necessary.

...

> ProjCoordTransGeoKey          
> 10
> 
> GeoTIFF code for label: 'CT_LambertAzimEqualArea'
> 
> 
> 
> ProjLinearUnitsGeoKey
> 
> 9001
> 
> EPSG uom_code for 'meter' (ISO 1000)
> 
> 
> 
> ProjFalseEastingGeoKey
> 
> 4321000.0d
> 
> in Projection System Linear Units (Key 3076)
> 
> 
> 
> ProjFalseNorthingGeoKey
> 
> 3210000.0d
> 
> in Projection System Linear Units (Key 3076)
> 
>  
> ProjCenterLongGeoKey
> 
> 10.000000d
> 
> in Geographic System Angular Units (Key 2054)
> 
> 
> 
> ProjCenterLatGeoKey      
> 52.000000d
> 
> in Geographic System Angular Units (Key 2054)

These all look fine to me.

Just be aware that there is a wide variety of geotiff readers in this
world, with greater and lesser degrees of implementation sophistication.
I suspect you are running into some less sophisticated readers.  If you
want your formulation reviewed more exactly you might want to provide
a small sample file, with what you believe the corners ought to be if
reprojected into the geographic coordinate system.  Then I could try my
software on it, and more exactly see how you have written the file.

Best regards,
-- 
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Geotiff mailing list
Geotiff at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/geotiff