<div dir="ltr"><div dir="ltr"><br><br>On Sat, Feb 23, 2019 at 10:26 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> On samedi 23 février 2019 15:59:28 CET Markus Neteler wrote:<br>> > Hi devs,<br>> ><br>> > there is some discussion about packages that need to be patched to use<br>> > proj_api.h or proj.h which will no longer be available in recent PROJ.<br>> ><br>> > Is there anything to do in GRASS GIS (trunk)?<br>><br>> From what I can see in<br>> <a href="https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c">https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c</a><br>> Markus Metz made use of proj.h API of PROJ 5. This should still work with PROJ<br>> 6.<br>><br>> However the way of building pipelines in<br>> <a href="https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c#L92">https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c#L92</a><br>> from the PROJ string of the source and target CRS (PROJ strings are not a good<br>> way to capture a CRS definition, mostly due to losing the original datum<br>> information) will be suboptimal in PROJ 6 since still using a early-binding<br>> approach with WGS84 as a pivot, instead of the new late-binding capabilities<br>> brought by PROJ 6.<br>> If GRASS stores EPSG code and/or WKT in addition/instead of PROJ strings, then<br>> using proj_create_crs_to_crs() will lead to more accurace results in<br>> circumstances where WGS84 is not a natural pivot, like the case of<br>> NAD27+NVGD29 to NAD83+NAVD88 that Paul Ramsey exposed in<br>> <a href="http://blog.cleverelephant.ca/2019/02/proj4-postgis.html">http://blog.cleverelephant.ca/2019/02/proj4-postgis.html</a><br><div><br></div><div>I have seen the magic lookup you implemented in proj_create_crs_to_crs() for PROJ 6, really impressive! It's on my TODO list to make use of proj_create_crs_to_crs() in GRASS (for PROJ 5 it was not worth the effort because proj_create_crs_to_crs() constructed a very simple pipeline).</div><div><br></div><div>GRASS already stores EPSG code if plrovided which could be enhanced to store any SRID as supported by proj's +init=..., according to the init files coming with RPOJ (<a href="https://proj4.org/resource_files.html#init-files">https://proj4.org/resource_files.html#init-files</a>).</div><div><br></div><div>We could also store WKT, but then I would suggest to enable this only for PROJ6+ and store only WKT2, not WKT1.</div><div><br></div><div>Markus M<br></div><div>></div>> Even<br>><br>> --<br>> Spatialys - Geospatial professional services<br>> <a href="http://www.spatialys.com">http://www.spatialys.com</a><br>> _______________________________________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></div></div>