[gdal-dev] Pre-RFC for OGRSpatialReference use in GDAL and changes in how to deal with axis order issues

Andrew C Aitchison andrew at aitchison.me.uk
Tue Dec 18 22:30:30 PST 2018


Do we need to consider (real and false) precision when converting between 
OGRSpatialReference and string ?

On Tue, 18 Dec 2018, Even Rouault wrote:

> Hi,
>
> I call this pre-RFC as I don't have yet any code implementing the following
> ideas (so there might be holes in the analysis), but I wanted to get some
> feedback before investing too much time into this substantial work.
>
> Let's start with the easiest topic:
>
> 1) Use of OGRSpatialReference in GDAL
>
> Currently GDAL datasets accept and return a WKT 1 string to describe the SRS.
> To be more independant of the actual encoding, and for example allowing a
> GeoPackage raster dataset to be able to use WKT 2, I propose we switch from a
> string representation to the more abstract representation offered by
> OGRSpatialReference. In the current state of GDAL, OGRSpatialReference is just
> a direct mapping of WKT 1, but in my in-progress gdalbarn branch at
> https://github.com/rouault/gdal/tree/gdalbarn , OGRSpatialReference is now
> more or less encapsulating a osgeo::proj::crs object (ie a C++ object
> representing a CRS as modelled by OGC Topic 2 / ISO-19111), that can have
> several representations: OGC WKT1 (GDAL WKT1), WKT2, ESRI WKT1, PROJ strings.
>
> So the proposal would be to change:
>
> GDALDataset:
>    virtual const char* GetProjectionRef();
>
> to
>    virtual OGRSpatialReference *GetSpatialRef();
>
>    // compatibility layer (conceptually)
>    const char* GetProjectionRef() {
> 		return GetSpatialRef()->ExportToWkt1(); }
>
> Similarly on the set side,
>
> Change
>    virtual CPLErr SetProjection(const char* pszWKT);
> to
>    virtual CPLErr SetSpatialRef(OGRSpatialReference*);
>
>    // compatibility layer (conceptually)
>    CPLErr SetProjection(const char* pszWKT) {
> 		return SetSpatialRef(OGRSpatialReference::importFromWkt(pszWKT)); }
>
> Regarding ownership, I guess we would do similarly to the vector side, that is
> GetSpatialRef() returns an an object that it owns and doesn't increment the
> refcount. And SetSpatialRef() would potentially increment the reference count
> on the passed object or clone it (like ICreateLayer() does)
>
> To ease the transition that will require going through all the ~150 raster
> drivers, I may add in GDALDataset:
>  protected:
>    OGRSpatialReference* GetSpatialRefFromOldGetProjectionRef()
> 		// conceptual implementation
> 		{ return OGRSpatialReference::importFromWkt(OldGetProjectionRef()); }
>
>    virtual const char* OldGetProjectionRef() { return ""; }
>
> Drivers would rename their existing GetProjectionRef() to
> OldGetProjectionRef() and implement a GetSpatialRef() that would just call
> GetSpatialRefFromOldGetProjectionRef(). This is just a technical detail to be
> able to complete the transition of API easier in a semi-automatic way. Over
> time we may remove the hack and implement natively GetSpatialRef(). And
> similarly for the write side.



More information about the gdal-dev mailing list