[Proj] Problem understanding the new API

[Matthias Gabriel]

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!

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180219/c878d9fb/attachment.html>