<div dir="ltr">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!<div><br></div><div>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?</div><div><br></div><div>With PROJ 6 patched with the epsg file, I was trying on a vanilla GDAL installation this:</div><div><br></div><div>gdaltransform -s_srs epsg:23030 -t_srs epsg:25830 <<EOF<br>235205.243 4142110.093<br>265467 3988010<br>EOF<br></div><div><br></div><div>Curiously enough, if I use this:</div><div><br></div><div>gdaltransform -s_srs +init=epsg:23030 -t_srs +init=epsg:25830 <<EOF<br>235205.243 4142110.093<br>265467 3988010<br>EOF<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr">







<p>it does use the grid and the transformation is decimeter-perfect. However, I'm getting a big DEPRECATION warning! Not good.</p><p>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?</p><p>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?</p><p>Thanks again!</p><p>---<br></p><p><span>Juan Pedro Pérez Alcántara</span></p>
<p><span><a href="mailto:jp.perez.alcantara@gmail.com" target="_blank">jp.perez.alcantara@gmail.com</a></span></p></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 2 Sep 2019 at 17:32, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Juan Pedro,<br>
<br>
> I maintain a set of Docker containers of PostGIS and currently I'm working<br>
> on a new release with updated version of the stack, which include PROJ 6,<br>
> GDAL 3, PostgreSQL 11.5, and PostGIS 2.5.3. I know PROJ 6 is a game<br>
> changer, and all the work I've done in the past configuring PROJ 4 to my<br>
> country (Spain) transformations with GSB grids might have been deprecated.<br>
> It appears so! Hopefully, after attempting a lot of things, I was able to<br>
> make PROJ 6 work nicely with the GSB by providing a resource epsg file.<br>
<br>
Creating a 'epsg' text resource file is now deprecated, in favor of using the <br>
'proj.db' database. See below<br>
<br>
> My hopes were that, once PROJ 6 was in place, GDAL 3 would make use of it<br>
> for gdaltransform, but somehow GDAL is not playing nicely with PROJ 6 and<br>
> transformations are not using the grids. If someone can shed some light<br>
> regarding this issues, I'll be most grateful:<br>
> <br>
> - what is the relation between GDAL 3 and PROJ 6? I mean, if cs2cs is using<br>
> the grid to transform, shouldn't GDAL rely on PROJ for reprojection and do<br>
> it well too?<br>
<br>
Yes, normally if something works with cs2cs it should work with GDAL <br>
reprojection API too, but they don't exactly use the same PROJ API, so details <br>
may matter. Can you give a full reproducer of your issue ?<br>
<br>
> - if GDAL has to be configured independently, what's the proper way to<br>
> attach a grid to a EPSG code so reprojections using the epsg:XXXXX syntax<br>
> would work with the grid?<br>
<br>
This is doable by addinng a new entry in the 'grid_transformation' table of <br>
the proj.db file.<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>