[Proj] Problem understanding the new API

[Thomas Knudsen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180219/9ed165df/attachment.htm