[GRASS-dev] [PROJ] PROJ 6RC2

neteler · February 23, 2019, 2:59pm

Hi devs,

there is some discussion about packages that need to be patched to use
proj_api.h or proj.h which will no longer be available in recent PROJ.

Is there anything to do in GRASS GIS (trunk)?

thanks
markusN

---------- Forwarded message ---------
From: Even Rouault
Date: Sat, Feb 23, 2019 at 2:50 PM
Subject: Re: [PROJ] PROJ 6RC2
To: <proj@lists.osgeo.org>
Cc: Sebastiaan Couwenberg

I haven't rebuilt any reverse dependencies with PROJ 6.0.0 yet, as we
can't transition to it in the near future anyway. But once that is done
we should have an overview which package need to be patched to use
proj_api.h or proj.h. Several of these packages aren't actively
developed any more, so those patches will need to be contributed by
someone experienced with the new APIs.

For the parts I maintain (with a lot of double quotes around """"maintain""""
for some of them),

- GDAL master / 2.5.0dev, to be released around May this year will require
PROJ 6 (GDAL 2.4 should probably already work fine with PROJ 6, since it uses
proj.h, but I didn't test)

- libgeotiff master / 1.5.0dev, to be probably released around the same time
of GDAL 2.5, will require PROJ 6. Current versions should likely work fine
since using proj_api.h if ACCEPT_USE_OF_DEPRECATED_PROJ_API_H is defined.

- the next version of shapelib will likely see its PROJ dependency removed
(only affects the contrib area) since I don't care about it:
https://lists.osgeo.org/pipermail/shapelib/2019-February/000645.html

- the next version of OGDI will likely see its PROJ dependency removed for the
same reason (it still uses project.h)
https://groups.yahoo.com/neo/groups/ogdidev/conversations/messages/314

- regarding MapServer, no immediate plan for action as far as I'm concerned.
It uses proj_api.h so ACCEPT_USE_OF_DEPRECATED_PROJ_API_H can be used for now.
Perhaps upgrading to proj.h would be a good topic for the OSGeo code sprint
for those who can attend.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj

sebastic · February 23, 2019, 4:17pm

On 2/23/19 3:59 PM, Markus Neteler wrote:

there is some discussion about packages that need to be patched to use
proj_api.h or proj.h which will no longer be available in recent PROJ.

To clarify, the discussion is about patching packages that use
projects.h which is no longer available in PROJ 6.

As announced with the release of PROJ 5, project should use proj_api.h
or proj.h.

GRASS now uses proj_api.h which will remain available until PROJ 7, see:

https://github.com/OSGeo/proj.4/milestones

Is there anything to do in GRASS GIS (trunk)?

Work could be started on supporting the new proj.h API.

Kind Regards,

Bas

--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

rouault · February 23, 2019, 8:44pm

On samedi 23 février 2019 15:59:28 CET Markus Neteler wrote:

Hi devs,

there is some discussion about packages that need to be patched to use
proj_api.h or proj.h which will no longer be available in recent PROJ.

Is there anything to do in GRASS GIS (trunk)?

From what I can see in
https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c
Markus Metz made use of proj.h API of PROJ 5. This should still work with PROJ
6.

However the way of building pipelines in
https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c#L92
from the PROJ string of the source and target CRS (PROJ strings are not a good
way to capture a CRS definition, mostly due to losing the original datum
information) will be suboptimal in PROJ 6 since still using a early-binding
approach with WGS84 as a pivot, instead of the new late-binding capabilities
brought by PROJ 6.
If GRASS stores EPSG code and/or WKT in addition/instead of PROJ strings, then
using proj_create_crs_to_crs() will lead to more accurace results in
circumstances where WGS84 is not a natural pivot, like the case of
NAD27+NVGD29 to NAD83+NAVD88 that Paul Ramsey exposed in
http://blog.cleverelephant.ca/2019/02/proj4-postgis.html

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com

Markus_Metz · February 23, 2019, 8:46pm

On Sat, Feb 23, 2019 at 5:17 PM Sebastiaan Couwenberg <sebastic@xs4all.nl> wrote:

On 2/23/19 3:59 PM, Markus Neteler wrote:

there is some discussion about packages that need to be patched to use
proj_api.h or proj.h which will no longer be available in recent PROJ.

To clarify, the discussion is about patching packages that use
projects.h which is no longer available in PROJ 6.

As announced with the release of PROJ 5, project should use proj_api.h
or proj.h.

GRASS now uses proj_api.h which will remain available until PROJ 7, see:

GRASS now (since the code sprint in Bonn early last year) uses the new proj.h if available, there is nothing to do to maintain compatibility with the upcoming PROJ 6 release.

We could start making use of the new features implemented by Even, particularly the new magic to find the best transformation from one CRS to another CRS, i.e. the new behaviour of proj_create_crs_to_crs().

Markus M

https://github.com/OSGeo/proj.4/milestones

Is there anything to do in GRASS GIS (trunk)?

Work could be started on supporting the new proj.h API.

Kind Regards,

Bas

–
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Markus_Metz · February 24, 2019, 5:48pm

On Sat, Feb 23, 2019 at 10:26 PM Even Rouault <even.rouault@spatialys.com> wrote:

On samedi 23 février 2019 15:59:28 CET Markus Neteler wrote:

Hi devs,

there is some discussion about packages that need to be patched to use
proj_api.h or proj.h which will no longer be available in recent PROJ.

Is there anything to do in GRASS GIS (trunk)?

From what I can see in
https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c
Markus Metz made use of proj.h API of PROJ 5. This should still work with PROJ
6.

However the way of building pipelines in
https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c#L92
from the PROJ string of the source and target CRS (PROJ strings are not a good
way to capture a CRS definition, mostly due to losing the original datum
information) will be suboptimal in PROJ 6 since still using a early-binding
approach with WGS84 as a pivot, instead of the new late-binding capabilities
brought by PROJ 6.
If GRASS stores EPSG code and/or WKT in addition/instead of PROJ strings, then
using proj_create_crs_to_crs() will lead to more accurace results in
circumstances where WGS84 is not a natural pivot, like the case of
NAD27+NVGD29 to NAD83+NAVD88 that Paul Ramsey exposed in
http://blog.cleverelephant.ca/2019/02/proj4-postgis.html

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

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 (https://proj4.org/resource_files.html#init-files).

We could also store WKT, but then I would suggest to enable this only for PROJ6+ and store only WKT2, not WKT1.

Markus M

Even

–
Spatialys - Geospatial professional services
http://www.spatialys.com

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev