[Proj] Problem understanding the new API

Matthias Gabriel matthias.gabriel at etit.tu-chemnitz.de
Mon Feb 19 15:16:22 EST 2018

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

Again: thanks a lot, your answer was very helpful!


On 19 February 2018 18:44:03 CET, Thomas Knudsen <knudsen.thomas at gmail.com> wrote:
>Note that the old API is still available - the new, however, introduces
>methods that are needed in order to obtain high accuracy
>The world view represented by the old API is always sufficient if all
>care about is meter level accuracy - and in many cases it will provide
>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
>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,
>in many cases you need to handle and select that datum with more care
>the old API allows. The primary aim of the new API is to allow just
>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
>you need to work in 4 dimensions.
>Now, having described the background for introducing the new API, I
>the architect and primary - but certainly not sole - implementer of the
>API) should probably also try to reply to your request for a hint about
>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
>a FORWARD transformation from WGS84 to system B.
>With cs2cs being the command line interface to the old API, and cct
>the same for the new, I think this example of doing the same thing in
>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
>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
>> specifying source and target systems i could transform my
>> Now I tried to use the new API (proj.h) which seems to be much
>> 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
>> same: given a set of coordinates in source system A I want to
>> 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

Tel: +49 371 531-34458
Fax: +49 371 531-834458 

matthias.gabriel at etit.tu-chemnitz.de www.tu-chemnitz.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180219/c878d9fb/attachment.htm 

More information about the Proj mailing list