<div dir="ltr">Computationally datum transformations are completely separable from map projections, but from the end users perspective they are inextricably combined in the modern era. A user should reasonably expect to get the same results in QGIS and ArcMap given the same ESPG codes, but in many cases they do not because of datum differences. I know Gerald disagreed with me on this in the past and obviously others still disagree with me. I do not believe that moving Proj into the 21st century threatens users who do not care about datum transformations. But ignoring datum transformations will make Proj irrelevant in the future.<div><br></div><div>Rich</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 10, 2017 at 5:44 AM, Thomas Knudsen <span dir="ltr"><<a href="mailto:knudsen.thomas@gmail.com" target="_blank">knudsen.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Duncan (and daan),</div><div><br></div><div>Yes, map projections are mathematical functions, while reference frame shifts are geophysical/geodetical transformations.</div><div><br></div><div>The latter are, however, also *in practice* represented by sequential application of parameterized mathematical functions, drawn from a rather limited gamut - basically consisting of Helmert, Horner, Molodensky, Grid interpolation and ellipsoidal/cartesian transformation.</div><div><br></div><div>All of these fundamental operations are architecturally similar to the map projection functions of the original libproj, and are implemented in a similar way.</div><div><br></div><div>Hence, what Kristian Evers and I have done over the last 18 months is technically to add 5 (or so) new projections to the original libproj.</div><div><br></div><div>To string the stuff together, we designed the pipeline metaphor, which is also materialized as just another projection.</div><div><br></div><div>So we have added what amounts to a few more projections to the library. These can be used or ignored, in the same way you may ignore the Transverse Mercator implementation if you are only interested in the Lambert Conformal Conic (You can probably even compile a version of the library leaving most of the “pseudoprojections” out).</div><div><br></div><div>All parameters for implementing actual reference frame transformations *are stored in parameter files, not in the library per se*.</div><div><br></div><div>If you are *not interested* in reference frame shifts, the code supporting reference frame shifts will *not affect you*. And the parameter files will only affect you through the (limited) disk space required. But you are not forced to install them anyway.</div><div><br></div><div>So if you are *not interested* in reference frame shifts, please *ignore the matter* and stop arguing against stuff that will *not affect you*. This stuff is certainly useful for a range of other people.</div><div><br></div><div>Should we want to follow daan’s recipe of splitting the reference frame handling entirely from the projection library, we would have to duplicate most of the well tested libproj infrastructural architecture into another library, which would, in most cases, be used in applications also depending on libproj.</div><div><br></div><div>Simply leveraging the existing infrastructure and adding a handful of pseudoprojections was definitely the way to go. Especially since the libproj architecture makes it possible to do so in a neat and non-intrusive way.</div><div><br></div><div>Regarding the new API:</div><div><br></div><div>The new API emerged as a by-product of attempts to make the libproj internals more maintainable, by improving namespacing and introducing new internal data types in order to reduce type-punning. This makes it more clear exactly what kind of coordinate is expected at each spot in the code.</div><div><br></div><div>The new API exposes these data types, simplifies a wide field of operations, and provides a unified interface to 2D, 3D and 4D transformations.</div><div><br></div><div>The new API does not replace the old API, but obviously the designers hope that it will become the preferred one for new applications. The old API may some day gain a “deprecated” status, but will only rot entirely away if no one is interested in maintaining it. So if anyone needs it badly enough to sponsor its maintenance, it will live on forever.</div><div><br></div><div>In a limited number of cases, software pre-dating the original API, described in proj-api.h, may experience breakage, since the original projects.h file does not describe an actual interface (API), but rather exposes every single function and data structure in the library.</div><div><br></div><div>So there is only one way to ensure that each-and-every program, using projects.h to do calls to libproj internals, would keep working with new versions of libproj: That would be to freeze both development and maintenance of the PROJ system. And anyone wishing for that may get theirs by just sticking with proj 4.3.0.</div><div><br></div><div>I personally believe, though, that we should make efforts not to hamper more well disciplined programs using projects.h just to do calls to the “obvious API” of projects.h (pj_init, pj_fwd, pj_inv, pj_free, and probably a few more).</div><div><br></div><div>The proj and cs2cs filters will live on as long as anyone wants to maintain them. But they definitely need some tlc, so test cases involving some of your more esoteric use cases of proj and cs2cs would be very welcome, and would greatly reduce the risk of regressions during maintenance.</div><div><br></div><div>/thomas</div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2017-08-10 6:56 GMT+02:00 Duncan Agnew <span dir="ltr"><<a href="mailto:dagnew@ucsd.edu" target="_blank">dagnew@ucsd.edu</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All:<br><br><div><div class="h5">I pretty much agree with Dan. For clarity (lacking in my previous entry),<br>there are two things, easily conflated, to talk about:<br><br> A. proj the program that people use (often on the command line)<br>to go between lat-long and projection coordinates. Most of these users<br>don't care about which lat/long they are using: certainly not important<br>if making a map, and probably not if using it to set up a grid system<br>for your own use (I've used it for both).<br><br> B. PROJ the package, which includes not just projections<br>but all the additional machinery to handle different datums--and<br>in the future heights and temporal changes.<br><br> I completely agree that PROJ needs to keep evolving; but at the<br>same time I (and probably many other users) would like to have proj<br>stay the same. This ought to be relatively easy since it is almost all<br>mathematics, the only parameters being the size and shape of the<br>ellipsoid--and I don't imagine there will be new values of this being<br>produced. But it depends on allowing the functionality of proj (not<br>PROJ) to not require the user who just wants a projection to have to<br>master the additional features needed to do datum transformations.<br><br> Of course grids are just projections, so it was easy for Gerald<br>to add things like SPCS, blurring the line a bit; but, with Daan (and<br>Gerald) I'd argue that it would be helpful to many users to have things<br>somewhat distinct.<br><br> And, I'd like to raise a question (I'm genuinely curious) about how<br>time-dependent motion will be added. Having been professionally engaged in<br>measuring and modeling crustal motion for the last 30+ years, I can say that it<br>is going to be a lot more complicated to keep track of. proj (as above) needs<br>only the -le parameters (a fixed set); once you add the rigid-body motions for<br>datum transformations there are a lot more parameters, many conventional (and<br>so unchanging), which EPSG fortunately collects; adding grids for distortion<br>(HARN) needs more information yet. But once you get into temporal changes,<br>things are even worse: models will keep changing either because of better data<br>or earthquakes (cf HTDP). This seems like a progression from a package<br>dominated by algebra to a small algebraic component attached to a large<br>and ever-growing database of parameters. I'm not arguing against it, at<br>all, just saying that it is going to be quite a challenge beyond modifying<br>the programs. (I completely lack the expertise to contribute to the code,<br>but if anyone has any geophysics questions I'm happy to try to answer them).<br><br>Thanks<span class="m_-1470674231595667303HOEnZb"><font color="#888888"><br>Duncan Agnew<br></font></span></div></div></div><div class="m_-1470674231595667303HOEnZb"><div class="m_-1470674231595667303h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br></div>
<br><span class="">______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br></span></blockquote></div><br></div>
</div></div><span class=""><br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Richard W. Greenwood, PLS<br><a href="http://www.greenwoodmap.com" target="_blank">www.greenwoodmap.com</a></div></div>
</div>