<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>Hi Thomas,<br>
<br>
thank your for your fast and very helpful answer! indeed that makes it much clearer... Maybe that usecase could be part of the upcoming documentation as I believe it's very common...<br>
<br>
I got one follow up question: In which coordinate system is the"result" of the first part of your pipeline, the"inverse" utm projection, defined? I understand that the transformation is "taking" a utm coordinate pair as argument but what does it actually calculate?<br>
<br>
Again: thanks a lot, your answer was very helpful!<br>
<br>
Regards,<br>
Matthias<br><br><div class="gmail_quote">On 19 February 2018 18:44:03 CET, Thomas Knudsen <knudsen.thomas@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div><div><br>Matthias,<br><br>Note that the old API is still available - the new, however, introduces methods that are needed in order to obtain high accuracy transformations.<br><br>The world view represented by the old API is always sufficient if all you care about is meter level accuracy - and in many cases it will provide much higher accuracy than that. But the view that “WGS84 is the *true* foundation of the world, and everything else can be transformed natively to and from WGS84” is inherently flawed.<br><br>First and foremost because any time WGS84 is mentioned, you should ask yourself “Which of the six WGS84 realizations are we talking about here?”.<br><br>Second, because for many (especially legacy) systems, it may not be straightforward to transform to WGS84 (or actually ITRF-something, ETRS-something or NAD-something which appear to be the practical meaning of the term WGS84 in everyday PROJ related work), while centimeter-level accurate transformations may exist between pairs of older systems.<br><br>The concept of a pivot reference frame (“datum”) is not inherently bad, but in many cases you need to handle and select that datum with more care than the old API allows. The primary aim of the new API is to allow just that. And to do that, you must realize that the world is inherently 4 dimensional. You may in many cases assume one or more of the coordinates to be constant, but basically, to obtain geodetic accuracy transformations, you need to work in 4 dimensions.<br><br>Now, having described the background for introducing the new API, I (being the architect and primary - but certainly not sole - implementer of the new API) should probably also try to reply to your request for a hint about how to use it.<br><br>First note that in order to go from system A to system B, the old API starts by doing an INVERSE transformation from system A to WGS84, then does a FORWARD transformation from WGS84 to system B.<br><br>With cs2cs being the command line interface to the old API, and cct being the same for the new, I think this example of doing the same thing in both world views will probably be ample hinting for you:<br><br>$ echo 300000 6100000 | cs2cs_d +proj=utm +zone=33 +ellps=GRS80 +to +proj=utm +zone=32 +ellps=GRS80<br><br>683687.87 6099299.66 0.00<br> <br>$ echo 300000 6100000 0 0 | cct +proj=pipeline +step +inv +proj=utm +zone=33 +ellps=GRS80 +step +proj=utm +zone=32 +ellps=GRS80<br><br>683687.8667 6099299.6624 0.0000 0.0000<br><br><br></div>(lookout for the "+inv" in the first +step, indicating an inverse transform).<br><br></div>/Thomas<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-19 16:07 GMT+01:00 Matthias Gabriel <span dir="ltr"><<a href="mailto:matthias.gabriel@etit.tu-chemnitz.de" target="_blank">matthias.gabriel@etit.tu-chemnitz.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I've been using the old proj4 API successfully an did understand that by<br>
specifying source and target systems i could transform my coordinates.<br>
Now I tried to use the new API (proj.h) which seems to be much cleaner<br>
and easier to use. I checked the manual and found:<br>
<br>
"the fundamental concept of transformations in PROJ are now handled in a<br>
single transformation object (PJ) and not by stating the source and<br>
destination systems as previously."<br>
<br>
Ok, fine.. understood. Unfortunately my problem definition is still the<br>
same: given a set of coordinates in source system A I want to calculate<br>
their representation in system B. ..<br>
<br>
So before it was straight-forward: I specified what I had and what I<br>
wanted, but now I don't know how to get the required "direct<br>
transformation" from A to B using the new API?! I tried to use a<br>
cs2cs-style string with the "+to" specifier but that didn't work.<br>
proj_create_crs_to_crs would be an option but doesn't quite suit my<br>
problem (we don't use EPSG codes etm).<br>
<br>
Could you please give me a hint on how to proceed here?<br>
<br>
Best Regards,<br>
Matthias<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></blockquote></div><br></div>
</blockquote></div><br>
--<br>
M.Sc. Matthias Gabriel<br>
Fakultät für Elektrotechnik und Informationstechnik<br>
<br>
Technische Universität Chemnitz<br>
Reichenhainer Straße 70 | R. W440<br>
09126 Chemnitz<br>
Germany<br>
<br>
Tel: +49 371 531-34458<br>
Fax: +49 371 531-834458 <br>
<br>
matthias.gabriel@etit.tu-chemnitz.de www.tu-chemnitz.de</body></html>