[Proj] Problem understanding the new API

Mon Feb 19 21:21:30 PST 2018

Hi,

Which CRS is exactly the hub in the old API? Is it WGS84 lat/lon or
geocentric?
Should it be more accurate or faster to use the new API to transform WGS84
lat/lon to WGS84 UTM,  will it use any different transformation path?

Thanks.

On 20 Feb 2018 01:10, "Kristian Evers" <kreve at sdfe.dk> wrote:

> 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
>
> _______________________________________________
> 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.osgeo.org/pipermail/proj/attachments/20180220/418adafe/attachment.html>