[gdal-dev] GSoC 2014 Weekly Report 11 : GDAL PostGIS Raster driver

[Even Rouault]

Le vendredi 08 août 2014 10:26:27, Jorge Arevalo a écrit :
> On Thu, Aug 7, 2014 at 10:28 PM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > Le jeudi 07 août 2014 22:26:07, Varun Saraf a écrit :
> > > Hello,
> > > 
> > > Thanks. I will use that.
> > > 
> > > When the PostGISRasterDataset::SetProjection method returns, a
> > 
> > segmentation
> > 
> > > fault is being shown. The methods I have made changes to IWriteBlock,
> > > IRasterIO are not being called. What is the following flow of methods
> > 
> > that
> > 
> > > are called? What could be the issue?
> > 
> > You're in the best position to know ;-) More seriously without looking at
> > the
> > code, I can only suggest you attaching a debugger or running Valgrind to
> > identify the flaw. (assuming you are developing on Linux)
> 
> Hello,
> 
> First of all, I will take guilt for my mistake: as Even said,
> gdal_translate will always call CreateCopy, as stated at
> http://www.gdal.org/classGDALDriver.html#a2c897da2a6e25169cccc49ef48797ce1.
> My (wrong) assumption was that if you force a modification with regard to
> the source raster (like providing a different outsize), gdal_translate will
> avoid CreateCopy. My fault.
> 
> Default implementation of CreateCopy will call Create at the end, but as
> PostGIS Raster driver provides its own implementation of CreateCopy, this
> doesn't happen. Quick fix, as also Even suggested, avoid the PostGIS Raster
> implementation of CreateCopy.
> 
> Varun, about the use of FetchSRSId, I think is a good idea too. The problem
> is your WKT representation of the SRS is a bit different from the
> representation stored in PostGIS (btw, where does your WKT representation
> come from?). Well, both of them have the authority code 32644. You just
> need a method to get this SRID from the WKT.

There are many possible correct variants of WKT for the same EPSG code. 
Depends on if you include all authority nodes, or other optional information. 
Like if you strip AXIS order information or not. GDAL has add itself 
variations on the way it export EPSG database as WKT. 
The one if spatial_ref_sys mentionned by Varun must likely comes from a GDAL 
<= 1.6 where we, wrongly (according to the BNF of WKT), put the AXIS nodes 
after the AUTHORITY code. This has been fixed in later GDAL versions, but the 
PostGIS spatial_ref_sys had not been regenerated since (something I've done in 
the recent weeks and that should hopefully go with PostGIS 2.2 : 
http://trac.osgeo.org/postgis/ticket/2737). So all in all relying on WKT 
strict matching isn't reliable.

> 
> One way to do it was the query in PostGIS Raster implementation of
> SetProjection (
> http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/postgisraster/postgisra
> sterdataset.cpp#L3024), but it doesn't work for you (again, the PostGIS WKT
> representation is a bit different, so, the query doesn't return a value).
> 
> Another way is, like Even suggested, to reuse OGRPGDataSource::FetchSRSId
> (Even, correct me if this isn't what you meant). You just need to build an
> instance of OGRSpatialReference from your WKT string (
> http://www.gdal.org/classOGRSpatialReference.html#a10e93344649a380d75b9925a
> d53d86ac), and then call FetchSRSId using a pointer to that instance as
> argument (check the method:
> http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/pg/ogrpgdatas
> ource.cpp#L1931 ).

Calling directling OGRPGDataSource::FetchSRSId from PostGISRaster isn't 
directly doable since it is a member function of OGRPGDataSource. From my 
quick look, it only requires the hPGConn member. For Varun's need, 
copying&pasting the method and doing the small needed adjustment might be the 
quick way for now. In an ideal world, we could think of unifying the 2 drivers 
but that's another business !

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com