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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Pierre Soille

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.  This
is what we did.  The comprehensive list of defined parameters, their
values and a series of comments is included at the bottom of this
message (see also output of gdalinfo on a sample file which can be
downloaded at http://www.ec-gis.org/sdi/seminar/geotiff-sample.tif).

Unfortunately, most of the common packages are not capable to read and
interpret correctly the geoinformation stored in these GeoTIFF files.
We would like to understand if this is due to the way we generate
our files or to software inabilities to handle these files.  In the
latter case, we will try to convince software vendors to upgrade their
GeoTIFF readers.

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.


Pierre Soille and Peter Strobl

 

----------------------------------------------------------------------------
--------------------------------

Order is the following:

GeoKey Name

Value

comment

----------------------------------------------------------------------------
--------------------------------

GTModelTypeGeoKey

1

GeoTiff code for label: 'ModelTypeProjected'

 

GTRasterTypeGeoKey

1

GeoTiff code for label: 'RasterPixelIsArea'

 

GTCitationGeoKey

'JRC-EGCS'

refers to JRC's 'European Grid Coding System', here we encode that this is
our scheme, this is the only field for which we do NOT use an adopted
spelling, we also believe that stating 'ETRS89 / ETRS-LAEA' in this key
is not
correct as a GeoTiff scheme is more than just a projection

 

GeograpicTypeGeoKey

4258

EPSG parameter COORD_REF_SYS_CODE for COORD_REF_SYS_NAME 'ETRS89', GeoTIFF
label is 'GCS_EUREF89'

 

GeogCitationGeoKey

'ETRS89'

spelling adopted from EPSG COORD_REF_SYS_NAME of COORD_REF_SYS_CODE 4258

 

GeogGeodeticDatumGeoKey

6258

EPSG DATUM_CODE for  DATUM_NAME 'European Terrestrial Reference System
1989', GeoTIFF label is 'Datum_European_Reference_System_1989'"

 

GeogPrimeMeridianGeoKey

8901

EPSG PRIME_MERIDIAN_CODE for PRIME_MERIDIAN_NAME 'Greenwich'

 

GeogLinearUnitsGeoKey

9001

EPSG uom_code for 'meter' (ISO 1000)

 

GeogAngularUnitsGeoKey

9102

EPSG uom_code for 'degree'

 

GeogEllipsoidGeoKey

7019

"EPSG ellipsoid_code for ellipsoid_name 'GRS 1980,' GeoTIFF label is
'Ellipse_GRS_1980"

 

GeogSemiMajorAxisGeoKey

6378137.0d

in Geographic System Linear Units (Key 2052)

 

GeogInvFlatteningGeoKey

298.2572221d

unitless

 

GeogPrimeMeridianLongGeoKey

0.0000000d

'Greenwich' in Geographic System Angular Units (Key 2052)

 

ProjectedCSTypeGeoKey

32767

'user defined', the EPSG COORD_REF_SYS_CODE 3035 is not implemented in
GeoTiff!!!

 

PCSCitationGeoKey

'ETRS89 / ETRS-LAEA'

spelling adopted from EPSG COORD_REF_SYS_NAME of COORD_REF_SYS_CODE 3035,
this is the proper place for the projection name

 

ProjectionGeoKey

32767

'user defined'

 

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)

----------------------------------------------------------------------------
----------------------------------------------------------------------------
--------------------------------------------------

 

 
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

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

Frank Warmerdam
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, [hidden email]
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
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

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

Peter Strobl
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.

The GeoTiff manual states:
|----------------------------------------------
|GTCitationGeoKey
|
|Key ID = 1026  
|Type = ASCII
|
|As with all the "Citation" GeoKeys, this is provided to give an ASCII
|reference to published documentation on the overall configuration of this
|GeoTIFF file.
|----------------------------------------------

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: [hidden email]
[mailto:[hidden email]] On Behalf Of Frank Warmerdam
Sent: 04 June 2008 17:03
To: Pierre Soille
Cc: [hidden email]
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,
[hidden email]
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
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

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

Frank Warmerdam
Peter Strobl wrote:

> 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?

Peter,

I agree that the selection of GTCitation instead of PCSCitation
for the PROJCS[] name by GDAL seems imprudent.  However, the citations
are just informational, and the definition otherwise seems fine.

BTW, did GDAL really produce a WKT report without quotes around
the various names?  I'm rather surprised to see that.

If you like, you can file a ticket against GDAL suggesting that it
use PCSCitation in preference to GTCitation for the PROJCS.  But otherwise
your file seems correct.  The fact that many packages can't read it isn't
strictly your fault, though I would not call the GDAL behavior failure, just
slightly suboptimal.

Nevertheless, I still think you would be better off the
ProjectedCSTypeGeoKey to 3035.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
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
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

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

Peter Strobl
Frank,

Thanks for your kind words, they give us some confidence that our
specification is justifiable. For now we will leave it as is.

However, we don't get your point in saying "I still think you would be
better off the ProjectedCSTypeGeoKey to 3035." We would love to do so, but
GeoTiff specs for that Key reserve only the range [20000, 32760] for EPSG
Projection System codes. In no case an EPSG number can be used directly but
the projection has to be identified in a list and the respective number,
which is never the same as the EPSG code has to be used. We don't see the
possibility to set the ProjectedCSTypeGeoKey to any EPSG code. This would
clearly violate the GeoTiff specs and thus jeopardize any attempt of
standardisation. Ideally the GeoTiff specs would be amended, but this seems
a hard thing to do...

Regarding the PROJCS, you are right, it is tweaked. I produced one on
Windows and got the following: 'PROJCS["JRC-EGCS", ...' On Linux
this file was rejected by gdal so to process it further we kicked out all
the '"' stuff. Then it was digested silently. If written by gdal on
Linux we get 'PROJCS["JRC-EGCS", ...' which I guess is what it should look
like.

Best regards & have a nice weekend!

Peter & Pierre


-----Original Message-----
From: Frank Warmerdam [mailto:[hidden email]]
Sent: 05 June 2008 20:03
To: Peter Strobl
Cc: [hidden email]; 'Pierre Soille'
Subject: Re: [Geotiff] Encoding of "ETRS89 / ETRS-LAEA" (i.e. EPSG:3035)

Peter Strobl wrote:

> 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?

Peter,

I agree that the selection of GTCitation instead of PCSCitation
for the PROJCS[] name by GDAL seems imprudent.  However, the citations
are just informational, and the definition otherwise seems fine.

BTW, did GDAL really produce a WKT report without quotes around
the various names?  I'm rather surprised to see that.

If you like, you can file a ticket against GDAL suggesting that it
use PCSCitation in preference to GTCitation for the PROJCS.  But otherwise
your file seems correct.  The fact that many packages can't read it isn't
strictly your fault, though I would not call the GDAL behavior failure, just
slightly suboptimal.

Nevertheless, I still think you would be better off the
ProjectedCSTypeGeoKey to 3035.

Best regards,
--
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
[hidden email]
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
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

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

Frank Warmerdam
Peter Strobl wrote:
> Frank,
>
> Thanks for your kind words, they give us some confidence that our
> specification is justifiable. For now we will leave it as is.
>
> However, we don't get your point in saying "I still think you would be
> better off the ProjectedCSTypeGeoKey to 3035." We would love to do so, but
> GeoTiff specs for that Key reserve only the range [20000, 32760] for EPSG
> Projection System codes.

Peter,

OK, I see the above comment about the range [20000,32760] being used for
the PCS codes, but that rule within EPSG has been since relaxed and so we
disregard that aspect of the GeoTIFF specification (which was only an attempt
to describe EPSG behavior).


 >  In no case an EPSG number can be used directly but
> the projection has to be identified in a list and the respective number,
> which is never the same as the EPSG code has to be used.

I'm not sure where you get this information.  The ProjectedCSTypeGeoKey
contains the EPSG PCS code number.  Accepted behavior is to not be concerned
whether the antique GeoTIFF .inc files actually have a corresponding #define
for the code or not.

 > We don't see the
> possibility to set the ProjectedCSTypeGeoKey to any EPSG code.

Well, not *any* EPSG code.  It has to be an EPSG projected coordinate
system code.  But doing so is exactly the accepted practice.

 >  This would
> clearly violate the GeoTiff specs and thus jeopardize any attempt of
> standardisation. Ideally the GeoTiff specs would be amended, but this seems
> a hard thing to do...

Well, I remain confused why you think that.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
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
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff