| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Also define merc (resp. tmerc) as the conformal projection in which the
equator (resp. a chosen meridan} projects to a straight line at constant
scale.
|
|
This addresses item 1 in issue #2387
Things to note:
* I made "editorial" changes to the text. The virtues and vices of
Mercator are a hot topic. So check these out. (I judged that the
text I replaced to be pretty misleading.)
* I include the radius of the sphere/ellipsoid in the formulas (and I
did this also for my mods for tmerc documentation). Surely this is
better than leaving the reader to figure out how this is introduced.
* I include the "old-style" (ca 18th century) formulas and the newer
ones in terms of hyperbolic functions. The former may be the familiar
ones, but the latter are better for computation (more succinct, more
accurate, faster, preserve parity).
* For the inverse ellipsoidal transformation, I just say that the
formula for psi is inverted iteratively. This is probably sufficient,
but it could be expanded later.
|
|
opposed to the spherical one)
Instead of 'elliptical'.
Was suggested by @cffk in https://github.com/OSGeo/PROJ/pull/2030#issuecomment-596132341
An elliptical projection is a projection whose global shape fits inside an
ellipsoid, like Mollweide. At least according to
https://www.merriam-webster.com/dictionary/elliptical%20projection
and
https://en.wikipedia.org/wiki/Mollweide_projection
|
|
image to caption
|
|
|
|
|
|
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.
|
|
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/.
|
|
|
