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

[Jorge Arevalo]

Hello,


On Fri, Aug 8, 2014 at 10:40 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

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

Thanks for the confirmation.


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

Yes, that was what I meant. For that reason I said 'reuse', not just
'call'. Sorry if I wasn't clear. A C&P should be enough, for the time being
(unifying the drivers sounds right. I'm having the same idea with the QGIS
loader for PostGIS, but I think it requires a lot of work).

Thanks again, Even

Best regards,

Jorge

-- 
Jorge Arevalo

http://about.me/jorgeas80
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140808/8d6f3f3e/attachment-0001.html>