> 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?
Yes (QGIS 3.8 or later needed to use PROJ 6 new capabilities) > > 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. Yes, init files are now deprecated in PROJ6. And using epsg:xxxx or +init=epsg:xxxx is indeed different: the former doesn't try to use a init file but a corresponding entry in proj.db, whereas the later will try first to locate a epsg init file, and if not found, will fallbak to proj.db. > 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? If you use PostGIS 3 beta, it should use proj.db out of the box. Older versions will rather use the PROJ strings of the spatial_ref_sys table. > > 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? Depends exactly on what you intend to do, but https://github.com/OSGeo/proj-datumgrid/blob/master/CONTRIBUTING.md should give you some hints. -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
