[Gdal-dev] OGR's importFromEPSG depends on libgeotiff?

[Frank Warmerdam]

On 10/6/05, Ben Discoe <ben at vterrain.org> wrote:
> Hi folks,
>
> One small observation and a question..
>
> The documentation for OGRSpatialReference::importFromEPSG says:
>         "This code uses the GeoTIFF cpl_csv services to access the EPSG CSV
> data. If frmts/gtiff/libgeotiff isn't linked in, linking will fail."
>
> This sounds like it might be out of date; isn't the cpl_csv quite a core
> component of GDAL/OGR nowadays...

Ben,

The comment is a bit inaccurate.  The importFromEPSG() method actually
depends on the functions in libgeotiff that are built on top of the cpl_csv
services.

> The question is, what method provides the inverse of importFromEPSG().  That
> is, given a common CRS in an OGRSpatialReference, can it return an EPSG
> coordinate system code, which when later passed to importFromEPSG(),
> re-constructs that same CRS?

Unfortunately this direction does not exist currently as a method
on the OGRSpatialReference.  In libgeotiff there is a function
GTIFMapSysToPCS() that does that a bit for some simple cases.

 #define MapSys_UTM_North	-9001
#define MapSys_UTM_South	-9002
#define MapSys_State_Plane_27	-9003
#define MapSys_State_Plane_83	-9004

int CPL_DLL   GTIFMapSysToPCS( int MapSys, int Datum, int nZone );

But it only works for a few common hardcoded cases (ie. UTM WGS84).
It has been an ambition of mine to some day build such a thing.

Note that some WKT coordinate system definitions include the PCS
(EPSG) code which can be extracted with the authority related
methods.

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    | Geospatial Programmer for Rent