<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Don,
<div class=""><br class="">
</div>
<div class="">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
<a href="https://proj4.org" class="">https://proj4.org</a>&nbsp;instead. The migration guide is the same but the rest of the docs are significantly improved.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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 &#43;init setups which unfortunately has led to most people doing similar pipelines as &nbsp;below invoked with proj_create(). I intend to make this easier in PROJ 6.0.0.</div>
<div class=""><br class="">
</div>
<div class="">For examples of how the pipeline framework can be used to do transformations without stepping through WGS84 have a look at&nbsp;<a href="https://github.com/NordicGeodesy/NordicTransformations" class="">https://github.com/NordicGeodesy/NordicTransformations</a>.
 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.</div>
<div class=""><br class="">
</div>
<div class="">/Kristian</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 25 Sep 2018, at 01:01, MacQueen, Don &lt;<a href="mailto:macqueen1@llnl.gov" class="">macqueen1@llnl.gov</a>&gt; wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">In effect, this is a question about whether or how well I understand the new pipeline approach.<br class="">
<br class="">
Here's an example transformation I have been using at my site, using cs2cs. It is considered to be correct.<br class="">
<br class="">
echo 1501839.77549 &nbsp;&nbsp;&nbsp;&nbsp;456388.976491 | \<br class="">
&nbsp;&nbsp;&nbsp;cs2cs \<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>&#43;from \<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>&nbsp;&#43;init=epsg:26743 \<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>&nbsp;&#43;nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat \<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>&nbsp;&#43;to \<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>&nbsp;&#43;init=epsg:2227 \<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>&nbsp;&#43;nadgrids=null<br class="">
<br class="">
The online Version 4 to Version 5 API migration guide<br class="">
&nbsp;( <a href="https://kbevers.github.io/development/migration.html" class="">https://kbevers.github.io/development/migration.html</a> )<br class="">
describes that cs2cs does a transformation like this one by passing &quot;through the ill-defined WGS84 reference frame, using it as a hub&quot; and points out shortcomings of that approach.
<br class="">
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 &quot;hub&quot;.<br class="">
<br class="">
Following the example in the migration guide, here's what I've found for performing the same using cct:<br class="">
<br class="">
echo 1501839.77549 &nbsp;&nbsp;&nbsp;&nbsp;456388.976491 | \<br class="">
cct -z 0 -t 0\<br class="">
&#43;proj=pipeline \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;step \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;inv \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;init=epsg:26743 \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;step \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;init=epsg:2227 \<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;nadgrids=null<br class="">
<br class="">
The respective outputs match &nbsp;-- great!<br class="">
<br class="">
But it also eems to me that by specifying &#43;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?<br class="">
<br class="">
Or am I just completely confused?<br class="">
<br class="">
Thanks<br class="">
-Don<br class="">
<br class="">
--<br class="">
Don MacQueen<br class="">
Lawrence Livermore National Laboratory<br class="">
7000 East Ave., L-627<br class="">
Livermore, CA 94550<br class="">
925-423-1062<br class="">
Lab cell 925-724-7509<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
Proj mailing list<br class="">
<a href="mailto:Proj@lists.maptools.org" class="">Proj@lists.maptools.org</a><br class="">
http://lists.maptools.org/mailman/listinfo/proj</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>