[gdal-dev] [GRASS-dev] PROJ 5 support in trunk

[Markus Metz]

On Mon, Mar 26, 2018 at 10:51 PM, Kristian Evers <kreve at sdfe.dk> wrote:

>
>
> On 26 Mar 2018, at 21:21, Markus Metz <markus.metz.giswork at gmail.com>
> wrote:
>
> There is an important difference between the PROJ4 and the PROJ5+
> API/syntax:
>
> The old PROJ4 API uses latlong WGS84 as pivot datum for coordinate
> transformations like
>
> projection1 -> latlong WGS84 -> projection2
> or in '+to' syntax
> projection1 +to projection2
>
> The new PROJ5+ API no longer uses a pivot datum. The advantage is that you
> can directly convert from one datum to another, without going through
> WGS84. The disadvantage is that the user/software using the new API has to
> make sure that either a common pivot datum is used or coordinates are
> correctly transformed from one datum to another, e.g. with a Helmert
> Transform.
>
> Both GDAL and GRASS have implemented the new API as a simple 2-step
> pipeline like
>
> 1. projection1 -> some latlong
> 2. some latlong -> projection2
>
> or in pipeline syntax
>
> +proj=pipeline
> +step +inv projection1
> +step projection2
>
>
> This is actually exactly what the proj_crs_to_crs() function does. When I
> originally wrote it I had an idea that this should only be used with
> init-files,
> but seeing how people need a simple way to do what they’ve always done I
> think it might be better to relax that requirement and allow input similar
> to what goes into cs2cs and pj_transform().
>

The challenge is that users of other software using the new PROJ API like
GDAL and GRASS expect that reprojecting a dataset from one CRS to another
CRS "just works".  Input and output CRS can be anything custom defined.
Either PROJ or other software using PROJ must have some mechanism to decide
if the requested reprojection can be done or not.

>
> My plan for this function is that it eventually will be able to construct
> a transformation between CRS’s without the WGS84 pivot. This will be guided
> by the EPSG database. I have still to work out exactly how. For now
> though, it works fine with already existing init files and WGS84 as a pivot
> datum.
> My hope is that this will land in version 6 but I won’t promise that just
> yet.
>

Looking forward to this function! But what if a dataset comes with a CRS
definition without EPSG code? Can we expect that PROJ handles this or
should applications using the PROJ API handle this?

Markus M


>
> Even Rouault has done some tests and found sometimes subtle differences in
> the results between the old and new API/syntax. Further on, there is no
> mechanism (yet) in place to validate the pipeline, most importantly that
> the output of step 1 conforms to the required input for step 2.
>
>
> I believe we have sorted those problems out in the coming version 5.0.1.
>
> Regarding validation of input/output from pipeline steps. We can probably
> do some basic checks, but in the end you will always be required to know
> what you are doing. Mind you, we are not expecting everyday users to
> construct their own pipelines all the time. It is a powertool for the
> accomplished
> user that knows what he is doing. Most users should have their needs met
> by predefined transformations in init-files such as the epsg file. And
> eventually
> in a more clever way using the EPSG database directly as mentioned above.
>
>
> IMHO, the implementation of the new PROJ5+ API/syntax in GDAL and GRASS
> should be regarded as experimental and testing by as many people as
> possible would be a huge benefit to PROJ/GDAL/GRASS and to all applications
> using these projects.
>
> Markus M
>
> On Sun, Mar 25, 2018 at 10:47 PM, Helmut Kudrnovsky <hellik at web.de> wrote:
> >
> > >Now (last related commit is trunk r72522) it's finished. I have
> >introduced
> > a new GRASS API that handles both PROJ 4 and PROJ >5, consisting of
> >
> > Thanks for this Update!
> >
> > Fyi See
> > https://lists.osgeo.org/pipermail/osgeo4w-dev/2018-March/003557.html
> >
> > -------
> > [...]
> > The API from PROJ 4 lives on in PROJ 5, so GRASS 7.4 should be able to
> use
> > PROJ 5 as well. We’ve been carefull not to breaking anything with this
> > release.
> > That comes with PROJ 6 and 7. Of course there might be implementation
> > details
> > in GRASS that I am unaware of that makes using PROJ 5 impossible.
> > --------
> >
> >
> >
> > -----
> > best regards
> > Helmut
> > --
> > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180327/97cfc2ff/attachment.html>