diff options
| author | Kristian Evers <kristianevers@gmail.com> | 2019-03-28 11:24:43 +0100 |
|---|---|---|
| committer | Kristian Evers <kristianevers@gmail.com> | 2019-03-28 14:15:37 +0100 |
| commit | fec376c3eb0e17443c4338f217b70278247973df (patch) | |
| tree | d1eddd7ae13c97babf412f3b2f5a03768981de24 /docs/source/development | |
| parent | e476bc2012cfcd71f787ed036c49f1d48627c1ef (diff) | |
| download | PROJ-fec376c3eb0e17443c4338f217b70278247973df.tar.gz PROJ-fec376c3eb0e17443c4338f217b70278247973df.zip | |
Docs: Clarify axis ordering used in proj_trans_generic()
Diffstat (limited to 'docs/source/development')
| -rw-r--r-- | docs/source/development/reference/functions.rst | 25 |
1 files changed, 16 insertions, 9 deletions
diff --git a/docs/source/development/reference/functions.rst b/docs/source/development/reference/functions.rst index 4052ff82..0066c3a2 100644 --- a/docs/source/development/reference/functions.rst +++ b/docs/source/development/reference/functions.rst @@ -221,10 +221,16 @@ Coordinate transformation 3. of length one, i.e. a constant, which will be treated as a fully populated array of that constant value + .. note:: Even though he coordinate components are named :c:data:`x`, :c:data:`y`, + :c:data:`z` and :c:data:`t`, axis ordering of the to and from CRS + is respected. Transformations exhibit the same behaviour + as if they were gathered in a :c:type:`PJ_COORD` struct. + + The strides, :c:data:`sx`, :c:data:`sy`, :c:data:`sz`, :c:data:`st`, represent the step length, in bytes, between consecutive elements of the corresponding array. This makes it possible for - :c:func:`proj_transform` to handle transformation of a large class of application + :c:func:`proj_trans_generic` to handle transformation of a large class of application specific data structures, without necessarily understanding the data structure format, as in: @@ -250,21 +256,22 @@ Coordinate transformation 0, 0 /* and the time is the constant 0.00 s */ ); - This is similar to the inner workings of the deprecated pj_transform function, but the - stride functionality has been generalized to work for any size of basic unit, - not just a fixed number of doubles. + This is similar to the inner workings of the deprecated :c:func:`pj_transform` + function, but the stride functionality has been generalized to work for any + size of basic unit, not just a fixed number of doubles. In most cases, the stride will be identical for x, y, z, and t, since they will - typically be either individual arrays (stride = sizeof(double)), or strided - views into an array of application specific data structures (stride = sizeof (...)). + typically be either individual arrays (``stride = sizeof(double)``), or strided + views into an array of application specific data structures (``stride = sizeof (...)``). But in order to support cases where :c:data:`x`, :c:data:`y`, :c:data:`z`, and :c:data:`t` come from heterogeneous sources, individual strides, :c:data:`sx`, :c:data:`sy`, :c:data:`sz`, :c:data:`st`, are used. - .. note:: Since :c:func:`proj_transform` does its work *in place*, this means that even the - supposedly constants (i.e. length 1 arrays) will return from the call in altered - state. Hence, remember to reinitialize between repeated calls. + .. note:: Since :c:func:`proj_trans_generic` does its work *in place*, + this means that even the supposedly constants (i.e. length 1 arrays) + will return from the call in altered state. Hence, remember to + reinitialize between repeated calls. :param PJ* P: Transformation object :param `direction`: Transformation direction |
