aboutsummaryrefslogtreecommitdiff
path: root/docs/source/usage/differences.rst
blob: e85ba039033f93e224f3fca24c4223a1c60fae3b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
.. _differences:

================================================================================
Known differences between versions
================================================================================

Once in a while, a new version of PROJ causes changes in the existing behaviour.
In this section we track deliberate changes to PROJ that break from previous
behaviour. Most times that will be caused by a bug fix. Unfortunately, some bugs
have existed for so long that their faulty behaviour is relied upon by software
that uses PROJ.

Behavioural changes caused by new bugs are not tracked here, as they should be
fixed in later versions of PROJ.

Version 4.6.0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The default datum application behavior changed with the 4.6.0 release. PROJ
will now only apply a datum shift if both the source and destination coordinate
system have valid datum shift information.

The PROJ 4.6.0 Release Notes states

    MAJOR: Rework :c:func:`pj_transform()` to avoid applying ellipsoid to ellipsoid
    transformations as a datum shift when no datum info is available.


Version 5.0.0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Longitude wrapping when using custom central meridian
-------------------------------------------------------------------------------

By default PROJ wraps output longitudes in the range -180 to 180. Previous to
PROJ 5, this was handled incorrectly when a custom central meridian was set with
:option:`+lon_0`. This caused a change in sign on the resulting easting as seen
below::

    $ proj +proj=merc +lon_0=110
    -70 0
    -20037508.34    0.00
    290 0
    20037508.34     0.00

From PROJ 5 on onwards, the same input now results in same coordinates, as seen
from the example below where PROJ 5 is used::

    $ proj +proj=merc +lon_0=110
    -70 0
    -20037508.34    0.00
    290 0
    -20037508.34    0.00

The change is made on the basis that :math:`\lambda=290^{\circ}` is a full
rotation of the circle larger than :math:`\lambda=-70^{\circ}` and hence
should return the same output for both.

Adding the ``+over`` flag to the projection definition provides
the old behaviour.

Version 6.0.0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Removal of proj_def.dat
-----------------------

Before PROJ 6, the ``proj_def.dat`` was used to provide general and per-projection
parameters, when ``+no_defs`` was not specified. It has now been removed. In case,
no ellipsoid or datum specification is provided in the PROJ string, the
default ellipsoid is GRS80 (was WGS84 in previous PROJ versions).

Changes to :ref:`deformation<deformation>`
------------------------------------------------------------------
.. _differences_deformation:


Reversed order of operation
...........................

In the initial version of the of :ref:`deformation<deformation>` operation
the time span between :math:`t_{obs}` and :math:`t_c` was determined by the
expression

.. math::

    dt = t_c - t_{obs}

With version 6.0.0 this has been reversed in order to behave similarly to
the :ref:`Helmert operation<helmert>`, which determines time differences as

.. math::

    dt = t_{obs} - t_c

Effectively this means that the direction of the operation has been reversed,
so that what in PROJ 5 was a forward operation is now an inverse operation and
vice versa.

Pipelines written for PROJ 5 can be migrated to PROJ 6 by adding :option:`+inv`
to forward steps involving the deformation operation. Similarly
:option:`+inv` should be removed from inverse steps to be compatible with
PROJ 6.

Removed ``+t_obs``  parameter
.............................

The ``+t_obs`` parameter was confusing for users since it effectively
overwrote the observation time in input coordinates. To make it more clear
what is the operation is doing, users are now required to directly specify
the time span for which they wish to apply a given deformation. The parameter
:option:`+dt` has been added for that purpose. The new parameter is mutually
exclusive with :option:`+t_epoch`. :option:`+dt` is used when deformation
for a set amount of time is needed and :option:`+t_epoch` is used (in
conjunction with the observation time of the input coordinate) when
deformation from a specific epoch to the observation time is needed.

Version 6.3.0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

projinfo
--------

Before PROJ 6.3.0, WKT1:GDAL was implicitly calling --boundcrs-to-wgs84, to
add a TOWGS84[] node in some cases. This is no longer the case.


Version 7.0.0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

proj
--------

Removed ``-ld`` option from application, since it promoted use of deprecated
paramters like ``+towgs`` and ``+datum``.

cs2cs
--------

Removed ``-ld`` option from application, since it promoted use of deprecated
paramters like ``+towgs`` and ``+datum``.