PROJ/docs/source/operations/projections, branch 7.0

Doc: add specific explanations for lat_ts for +proj=stere, also mentions +lat_0 and +k_0

2020-06-03T13:11:30+00:00

createFromProjString(): handle default parameters of '+krovak +type=crs', and handle +czech correctly (fixes #2199)

2020-04-28T09:37:04+00:00

Add note about orientation of control points in `chamb`

2020-03-12T10:03:55+00:00

Doc: use 'ellipsoidal' to refer to the ellipsoidal formulation (to be opposed to the spherical one)

2020-03-11T08:23:05+00:00

utm/ups: make sure to set errno to PJD_ERR_ELLIPSOID_USE_REQUIRED if es==0

2020-03-10T17:02:14+00:00

Remove occurences of deprecated PROJ.4 syntax (#2021)

2020-03-05T07:20:37+00:00

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Add missing projection property tables

2020-03-01T10:50:56+00:00

Doc: advertize lat_0 for proj=nsper

2020-02-21T12:36:27+00:00

Fix ingestion of +proj=cea with +k_0

2020-01-25T15:31:00+00:00

Fixes #1881

Digging into the implementation of proj=cea, it appears that
k_0 and lat_ts are intended to be exclusive ways of specifying the
same concept. EPSG only models the variant using lat_s.
So if k_0 is found and lat_ts is absent, compute the equivalent
value of lat_ts from k_0.

Note: k_0 should normally be in the [0,1] range. In case creative users
would use something outside, we raise an exception, even if the cea
implementation could potentially deal with any k_0 value. Hopefully
this is a (reasonable) limitation that will address nominal use cases.

isea docs: Rewrite intro and reference to reflect actual projection

2019-12-09T10:46:53+00:00

Previous version was describing oea by mistake. It is also a projection
by Snyder and the isea docs was based on the paper on the oea
projection. This commit fixes that.