<div dir="ltr"><div dir="ltr"><div>Nyall,</div><div><br></div><div>If you take a look at the source code for proj_trans_generic() over at <a href="https://github.com/OSGeo/proj.4/blob/6.0/src/4D_api.cpp">https://github.com/OSGeo/proj.4/blob/6.0/src/4D_api.cpp</a></div><div>you will see in line 414, that it works by calling proj_trans() for each coordinate tuple in the generic data structure.</div><div><br></div><div>So proj_trans_generic() works exactly like proj_trans().</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>/thomas<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tor. 28. mar. 2019 kl. 01.53 skrev Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
It's my interpretation of reading the docs that when calling<br>
proj_trans the order of values in PJ_COORD.v must match the expected<br>
axis order (when using EPSG codes for the transform parameters).<br>
<br>
What's unclear is if this **doesn't** apply when calling<br>
proj_trans_generic? Is it safe to assume that for proj_trans_generic x<br>
is ALWAYS x (or longitude), y is ALWAYS y (or latitude), etc?<br>
<br>
And on a related note: For one-off, single point transforms, is it<br>
preferable to use proj_trans? Or is it equally efficient to use<br>
proj_trans_generic with one element arrays?<br>
<br>
Nyall<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>