[Proj] Problem understanding the new API

Mon Feb 19 15:04:26 PST 2018

Matthias,

Let me try to answer on Thomas’ behalf:

> On 19 Feb 2018, at 21:16, Matthias Gabriel <matthias.gabriel at etit.tu-chemnitz.de> wrote:
> 
> Hi Thomas,
> 
> 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…
> 

I have added Thomas’ answer to the API migration guide. See a preview of the 5.0.0 docs here: https://kbevers.github.io/development/migration.html

> 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?

The coordinate system in the first part is just UTM Zone 33 on the GRS80 ellipsoid. In Thomas’ example there is not any datum attached to the coordinate system, which I think is what you are really asking. UTM is just a projection that converts coordinates on the sphere/ellipsoid onto the plane. That’s it. Thomas’ example though, is also a good explanation  of what happens in the old API, if we say that the thing that the input coordinates are converted to is WGS84 geodetic coordinates. WGS84 is used as the hub-datum in cs2cs and pj_transform() from the old API. The last step of the pipeline-example converts of course from WGS84 to UTM32. Of course with the old API it is also possible to use parameters such as +towgs84 that defines a set of parameters for a Helmert transformation going from whatever datum your coordinates are in TO WGS84. Depending on whether the proj-string is used as the source og destination system.

> I understand that the transformation is "taking" a utm coordinate pair as argument but what does it actually calculate?
> 

So in summation, the transformation calculates the corresponding geodetic coordinate of that particular UTM coordinate. The next step converts the geodetic coordinate to UTM again, albeit a different zone this time.

Thomas and I wrote a paper about this concept last year in which we go into some more details about how the pipeline setup works. It might be of interest to you: http://www.fig.net/resources/proceedings/fig_proceedings/fig2017/papers/iss6b/ISS6B_evers_knudsen_9156.pdf

/Kristian

> Again: thanks a lot, your answer was very helpful!
> 
> Regards,
> Matthias
> 
> On 19 February 2018 18:44:03 CET, Thomas Knudsen <knudsen.thomas at gmail.com> wrote:
> 
> Matthias,
> 
> Note that the old API is still available - the new, however, introduces methods that are needed in order to obtain high accuracy transformations.
> 
> 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.
> 
> First and foremost because any time WGS84 is mentioned, you should ask yourself “Which of the six WGS84 realizations are we talking about here?”.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> $ echo 300000 6100000 | cs2cs_d +proj=utm +zone=33 +ellps=GRS80 +to +proj=utm +zone=32 +ellps=GRS80
> 
> 683687.87       6099299.66 0.00
>       
> $ echo 300000 6100000 0 0 | cct +proj=pipeline +step +inv +proj=utm +zone=33 +ellps=GRS80 +step +proj=utm +zone=32 +ellps=GRS80
> 
> 683687.8667   6099299.6624    0.0000    0.0000
> 
> 
> (lookout for the "+inv" in the first +step, indicating an inverse transform).
> 
> /Thomas
> 
> 
> 2018-02-19 16:07 GMT+01:00 Matthias Gabriel <matthias.gabriel at etit.tu-chemnitz.de>:
> Hi,
> 
> I've been using the old proj4 API successfully an did understand that by
> specifying source and target systems i could transform my coordinates.
> Now I tried to use the new API (proj.h) which seems to be much cleaner
> and easier to use. I checked the manual and found:
> 
> "the fundamental concept of transformations in PROJ are now handled in a
> single transformation object (PJ) and not by stating the source and
> destination systems as previously."
> 
> Ok, fine.. understood. Unfortunately my problem definition is still the
> same: given a set of coordinates in source system A I want to calculate
> their representation in system B. ..
> 
> So before it was straight-forward: I specified what I had and what I
> wanted, but now I don't know how to get the required "direct
> transformation" from A to B using the new API?! I tried to use a
> cs2cs-style string with the "+to" specifier  but that didn't work.
> proj_create_crs_to_crs would be an option but doesn't quite suit my
> problem (we don't use EPSG codes etm).
> 
> Could you please give me a hint on how to proceed here?
> 
> Best Regards,
> Matthias
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
> 
> 
> --
> M.Sc. Matthias Gabriel
> Fakultät für Elektrotechnik und Informationstechnik
> 
> Technische Universität Chemnitz
> Reichenhainer Straße 70 | R. W440
> 09126 Chemnitz
> Germany
> 
> Tel: +49 371 531-34458
> Fax: +49 371 531-834458 
> 
> matthias.gabriel at etit.tu-chemnitz.de www.tu-chemnitz.de_______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj