[PROJ] Axis ordering and proj_trans

[Thomas Knudsen]

Nyall,

If you take a look at the source code for proj_trans_generic() over at
https://github.com/OSGeo/proj.4/blob/6.0/src/4D_api.cpp
you will see in line 414, that it works by calling proj_trans() for each
coordinate tuple in the generic data structure.

So proj_trans_generic() works exactly like proj_trans().

In fact, don't get fooled by whatever names are used to denote the
elementary coordinates in a coordinate tuple: They are just identifiers
representing the index of the coordinate in the tuple, but since the C
programming language does not allow numericals as identifiers, xyzt are
used instead of 0123.

Until release 5.0 PROJ was still suffering under the wrong assumption that
there exists some "God given axis order that all systems must adhere to",
and some "God given fundamental coordinate system, that all other systems
are defined in terms of".

It was a long, tough trip to clean out these assumptions from the code, so
it wasn't done in one step. In hindsight, it would have been better to
represent a coordinate tuple as an array of four doubles + a pointer to a
(potentially const) PJ-object, describing the system. But in 2016, this
would not have flown: It takes some time getting used to the thought that
the world is more chaotic than you have grown used to assume.

So initially, building up the understanding (and later consensus) among
developers, that AXIS ORDER IS A PART OF THE COORDINATE SYSTEM DEFINITION,
and may/will differ between coordinate systems, was an important part of
that trip. Hence the alphabetical, rather than numeric, identifiers of the
PJ_COORD object: The ingrained PROJ assumptions had to be changed, and that
took some time.

A few releases down the line it will hopefully be common consensus that you
should NEVER have any assumtions about the internal structure of a PJ_COORD
object.

Until then: just read x, y, z, t as "first, second, third, fourth"
coordinate of a 4D coordinate tuple, and accept that the meaning of those
coordinates are defined entirely by the coordinate system identification.
Without the system identification it is just four numbers.

For example, if your reference frame is WGS84, and your coordinate tuple
has axis order (longitude, latitude), then it's not EPSG:4326, but
something else, that can be transformed to EPSG:4326 by swapping the two
first axis.

/thomas

Den tor. 28. mar. 2019 kl. 01.53 skrev Nyall Dawson <nyall.dawson at gmail.com
>:

> Hi list,
>
> It's my interpretation of reading the docs that when calling
> proj_trans the order of values in PJ_COORD.v must match the expected
> axis order (when using EPSG codes for the transform parameters).
>
> What's unclear is if this **doesn't** apply when calling
> proj_trans_generic? Is it safe to assume that for proj_trans_generic x
> is ALWAYS x (or longitude), y is ALWAYS y (or latitude), etc?
>
> And on a related note: For one-off, single point transforms, is it
> preferable to use proj_trans? Or is it equally efficient to use
> proj_trans_generic with one element arrays?
>
> Nyall
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190328/b4e0c67b/attachment.html>