[gdal-dev] GDAL 3 and PROJ 6

Juan Pedro Pérez Alcántara jp.perez.alcantara at gmail.com
Mon Sep 2 08:46:15 PDT 2019


Many thanks for the quick response, Even. By the way, many, many, many
congratulations for the Sol Katz! You truly and heartly deserve it, thanks
for your impressive work!

Ok, I'll work the proj.db way, it seems to be more profitable to do so. If
I'm not mistaken, both PROJ 6 and QGIS rely on proj.db to reproject, isn't
it?

With PROJ 6 patched with the epsg file, I was trying on a vanilla GDAL
installation this:

gdaltransform -s_srs epsg:23030 -t_srs epsg:25830 <<EOF
235205.243 4142110.093
265467 3988010
EOF

Curiously enough, if I use this:

gdaltransform -s_srs +init=epsg:23030 -t_srs +init=epsg:25830 <<EOF
235205.243 4142110.093
265467 3988010
EOF

it does use the grid and the transformation is decimeter-perfect. However,
I'm getting a big DEPRECATION warning! Not good.

So, for not to take much of your time, do you think if I work the original
patching of PROJ 6 via the proj.db way a vanilla GDAL build will rely on it
out-of-the-box? Not wanting to abuse, but... any hint of what to expect
when I come to PostGIS? Will it use PROJ 6 out-of-the-box?

Besides, if I'm not mistaken, you, Even, are also one of the people behind
PROJ 6. How difficult can be to contribute the Spanish patch to the source?

Thanks again!

---

Juan Pedro Pérez Alcántara

jp.perez.alcantara at gmail.com


On Mon, 2 Sep 2019 at 17:32, Even Rouault <even.rouault at spatialys.com>
wrote:

> Juan Pedro,
>
> > I maintain a set of Docker containers of PostGIS and currently I'm
> working
> > on a new release with updated version of the stack, which include PROJ 6,
> > GDAL 3, PostgreSQL 11.5, and PostGIS 2.5.3. I know PROJ 6 is a game
> > changer, and all the work I've done in the past configuring PROJ 4 to my
> > country (Spain) transformations with GSB grids might have been
> deprecated.
> > It appears so! Hopefully, after attempting a lot of things, I was able to
> > make PROJ 6 work nicely with the GSB by providing a resource epsg file.
>
> Creating a 'epsg' text resource file is now deprecated, in favor of using
> the
> 'proj.db' database. See below
>
> > My hopes were that, once PROJ 6 was in place, GDAL 3 would make use of it
> > for gdaltransform, but somehow GDAL is not playing nicely with PROJ 6 and
> > transformations are not using the grids. If someone can shed some light
> > regarding this issues, I'll be most grateful:
> >
> > - what is the relation between GDAL 3 and PROJ 6? I mean, if cs2cs is
> using
> > the grid to transform, shouldn't GDAL rely on PROJ for reprojection and
> do
> > it well too?
>
> Yes, normally if something works with cs2cs it should work with GDAL
> reprojection API too, but they don't exactly use the same PROJ API, so
> details
> may matter. Can you give a full reproducer of your issue ?
>
> > - if GDAL has to be configured independently, what's the proper way to
> > attach a grid to a EPSG code so reprojections using the epsg:XXXXX syntax
> > would work with the grid?
>
> This is doable by addinng a new entry in the 'grid_transformation' table
> of
> the proj.db file.
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190902/0b0c8c88/attachment.html>


More information about the gdal-dev mailing list