| Age | Commit message (Collapse) | Author |
|---|
|
- classification
- tests
- coding style
|
|
|
|
image to caption
|
|
[BREAKING] Helmert: add +convention=position_vector/coordinate_frame, forbids +transpose (fixes #1091)
|
|
|
|
|
|
added usage example
|
|
|
|
bug in example - changed +t_in=gpsweek to +t_in=gps_week
|
|
Fixes for webmerc projection (fixes #1078)
|
|
forbids +transpose (fixes #1091)
As identified in #1091, Helmert implementation in PROJ 5.0 and 5.1 is confusing.
It happens that by default it used the coordinate_frame convention, contrary to
the position_vector convention used traditionaly for +towgs84. The documentation
of Helmert was also wrongly specifying that the default convention was
position_vector.
This commit:
- bans the confusing +transpose parameter
- removes the concept of a default convention, since in practice both are
equally found, and requires +convention as soon as a rotational term parameter
is present.
For translation only, convention is ignored and optional, as having no effect.
- fixes all the identified uses of proj=helmert in code, doc and tests
This is obviously a breaking change:
- users will have to adapt their pipeline expressions
- in particular, init files that would use helmert must be adapted
However, as designed, the break will be explicit, and not silent.
|
|
This is intended to supersed https://github.com/OSGeo/proj.4/pull/1080
with a number of differences.
What is kept from #1080 is not forcing the ellipsoid_params to be the one
of a sphere. This is not required for correct coordinate computation and
avoid lying on the various distorsion parameters.
For better interoperability with EPSG, we also no longer force the
lam0 parameter to 0, because
https://www.epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::1024
has a provision for it, even if in practice they will always be zero
phi0 should always be zero and is not used by the formulas.
Another difference with the #1080 approach is that we do not force the
WGS84 ellipsoid. Perhaps someone will use webmerc for another planet,
even if that is a crazy idea...
|
|
|
|
|
|
|
|
|
|
Implement the Equal Earth projection (closes #1085)
|
|
|
|
|
|
As mentionned in #1071, it is often unclear how the offset of a vertical grid
is applied.
|
|
|
|
|
|
|
|
that it supports numeric factors (refs #1053)
|
|
|
|
|
|
Temporal gridshifts allow [h|v]gridshift operations to be used as step functions
in a pipeline. This is useful in transformations dealing with deformations caused
by earthquakes.
See the included documentation for details.
|
|
|
|
This had unexpected side-effects when building the HTML docs on Travis
compared to locally. The correct solution would be to set different
scaling depending on the output.
This reverts commit 325477ed0fac2c9233c2f6a2b7bb4125e04df24c.
|
|
|
|
|
|
|
|
Extended the use of the :option: directive to all currently written
operation doc pages. In the process several more default parameters were
added for easy inclusion in other doc pages.
Expanded the info tables for each operation with "domain", "alias",
"input type" and "output type".
Corrected various errors along the way. Mainly formatting errors and
references to invalid parameters such as +sym in hatano.
|
|
|
|
|
|
|
|
|
|
Airy updates
|
|
Add a dedicated proj=webmerc operation
|
|
|
|
|
|
|
|
|
|
|
|
Instead of listing the various projection options in a table we write
them as :option: tags instead. This makes it easier to write a more
elaborate description of the parameter. Additionally we can create
"master"-description of commonly used parameters such as +lon_0 and +k_0
and include them where necessary. This is handled in separate files, one
for each common parameters, that are stored in
docs/source/operations/options/.
|
|
operations
|
|
|
|
|
|
As suggested in [0], steps in a pipeline are now checked for compliance.
If the right side units in step n differ from the left side units in
step n+1 the pipeline can't be constructed and an error is raised.
[0] https://lists.osgeo.org/pipermail/grass-dev/2018-March/088123.html
|
|
|
