2

As the title says, why doesn't the unix tools listgeo and gdalinfo show the same proj4 strings?

Check this file: https://github.com/geotrellis/geotrellis/blob/master/raster-test/data/econic.tif?raw=true

This gives with listgeo -proj4 econic.tif the proj4 string:

+proj=eqdc +lat_1=33.903634028 +lat_2=33.625290028 +lat_0=33.764462028 +lon_0=-117.474542889 +x_0=0.000 +y_0=0.000 +ellps=clrk66 +units=m

And with gdalinfo -proj4 econic.tif the proj4 string:

+proj=eqdc +lat_0=33.76446202777777 +lon_0=-117.4745428888889 +lat_1=33.90363402777778 +lat_2=33.62529002777778 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs

The only thing different is the ellps flag for listgeo and datum for gdalinfo. I have looked at the listgeo source and it never writes a datum flag.

Another question here of course is how do I compare these two, in a module I'm writing, and still get that they are the same?

0

Obviously listgeo and gdalinfo implement the same task in a bit different way. You can see that listgeo can read the datum even it does not write it into Proj4 string:

listgeo -proj4 econic.tif
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0
         -15411.615311508815448.7289683279 0
      ModelPixelScaleTag (1,3):
         60               60               0
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,17): "EC          E000"
      GeographicTypeGeoKey (Short,1): GCS_NAD27
      GeogLinearUnitsGeoKey (Short,1): Linear_Meter
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjectedCSTypeGeoKey (Short,1): User-Defined
      ProjectionGeoKey (Short,1): User-Defined
      ProjCoordTransGeoKey (Short,1): CT_EquidistantConic
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      ProjStdParallel1GeoKey (Double,1): 33.9036340277778
      ProjStdParallel2GeoKey (Double,1): 33.6252900277778
      ProjNatOriginLatGeoKey (Double,1): 33.7644620277778
      ProjFalseEastingGeoKey (Double,1): 0
      ProjFalseNorthingGeoKey (Double,1): 0
      ProjCenterLongGeoKey (Double,1): -117.474542888889
      End_Of_Keys.
   End_Of_Geotiff.

Projection Method: CT_EquidistantConic
   ProjStdParallel1GeoKey: 33.903634 ( 33d54'13.08"N)
   ProjStdParallel2GeoKey: 33.625290 ( 33d37'31.04"N)
   ProjNatOriginLatGeoKey: 33.764462 ( 33d45'52.06"N)
   ProjNatOriginLongGeoKey: -117.474543 (117d28'28.35"W)
   ProjFalseEastingGeoKey: 0.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4267/NAD27
Datum: 6267/North American Datum 1927
Ellipsoid: 7008/Clarke 1866 (6378206.40,6356583.80)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

PROJ.4 Definition: +proj=eqdc +lat_1=33.903634028 +lat_2=33.625290028 +lat_0=33.764462028 +lon_0=-11
7.474542889 +x_0=0.000 +y_0=0.000 +ellps=clrk66 +units=m

Comparing WKT strings of projections and trying to interpret if they mean the same or not is not solved yet. Sometimes for example ESRI WKT and EPSG WKT from GDAL and Proj4 differ a bit and programs like QGIS think they are different projections. See a somehow related question QGIS show gdal_polygonized file in EPSG:54004 instead of EPSG:3857.

  • Okay, this is a great answer but not the one I was hoping for. My current own reader implements the listgeo code for generating proj4 strings. I will change that to the GDAL implementation, that is, swap out ellipsoid for the datum. Thanks for the answer. – Johan S Sep 10 '14 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.