[Proj] Question about migrating to Proj 5.x.x

Kristian Evers kreve at sdfe.dk
Mon Sep 24 23:08:04 EST 2018


I see that you are looking at an outdated development version of the docs. I should have removed that a long time ago. Please go to https://proj4.org instead. The migration guide is the same but the rest of the docs are significantly improved.

Regarding the pipeline you’ve described below, yes it is exactly same as what cs2cs is doing. While stepping through WGS84 as a hub is generally a bad idea, quite often it is the only practical choice. Either because you haven’t got access to a better way to do the transformation or because that is simply how they are defined. Often times there will be a better way to do the transformation but we still haven’t got a mechanism for helping you set that up. We are working on that though (or Even is, I should say).

So in summary, you’ve got it all right. I acknowledge that we haven’t made it particularly easy to do transformations as simple as they are done with pj_transform(). The function proj_create_crs_to_crs() is meant to replace it but so far it has been restricted to +init setups which unfortunately has led to most people doing similar pipelines as  below invoked with proj_create(). I intend to make this easier in PROJ 6.0.0.

For examples of how the pipeline framework can be used to do transformations without stepping through WGS84 have a look at https://github.com/NordicGeodesy/NordicTransformations. These are a collection of transformations used in the Nordic countries and none of them use WGS84 a hub. Some are quite complicated (have a look at the resources/NKG file) and some are rather similar to what you are used to from cs2cs.


On 25 Sep 2018, at 01:01, MacQueen, Don <macqueen1 at llnl.gov<mailto:macqueen1 at llnl.gov>> wrote:

In effect, this is a question about whether or how well I understand the new pipeline approach.

Here's an example transformation I have been using at my site, using cs2cs. It is considered to be correct.

echo 1501839.77549     456388.976491 | \
   cs2cs \
+from \
 +init=epsg:26743 \
 +nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat \
 +to \
 +init=epsg:2227 \

The online Version 4 to Version 5 API migration guide
 ( https://kbevers.github.io/development/migration.html )
describes that cs2cs does a transformation like this one by passing "through the ill-defined WGS84 reference frame, using it as a hub" and points out shortcomings of that approach.
Various descriptions I've seen of the new pipeline approach have seemed to imply that it's better at least in part because it doesn't use WGS84 as a "hub".

Following the example in the migration guide, here's what I've found for performing the same using cct:

echo 1501839.77549     456388.976491 | \
cct -z 0 -t 0\
+proj=pipeline \
     +step \
     +inv \
     +init=epsg:26743 \
     +nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat \
     +step \
     +init=epsg:2227 \

The respective outputs match  -- great!

But it also eems to me that by specifying +inv, it is still passing through WGS84. It's now explicit, which is good, but is it really fundamentally different? Is there some other way to get from one projected system to another?

Or am I just completely confused?


Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
Lab cell 925-724-7509

Proj mailing list
Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180925/9fca6d40/attachment.htm 

More information about the Proj mailing list