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

MacQueen, Don macqueen1 at llnl.gov
Mon Sep 24 18:01:15 EST 2018

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

More information about the Proj mailing list