diff options
21 files changed, 59 insertions, 59 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 59cb14be..8d0d6c7b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -181,4 +181,4 @@ improperly contributing code to the source repository: The _code contribution_ section of this CONTRIBUTING file is inspired by [PDAL's](https://github.com/PDAL/PDAL/blob/master/CONTRIBUTING.md) and the _legalese_ section is -modified from [GDAL contributer guidelines](https://trac.osgeo.org/gdal/wiki/rfc3_commiters) +modified from [GDAL commiter guidelines](https://trac.osgeo.org/gdal/wiki/rfc3_commiters) diff --git a/docs/source/contributing.rst b/docs/source/contributing.rst index 5e198ae7..5f55ed9a 100644 --- a/docs/source/contributing.rst +++ b/docs/source/contributing.rst @@ -84,8 +84,8 @@ Note that not all feature requests are accepted. Write documentation ------------------- -PROJ is in dire need of better documentation. Any contributiions of -documentation are greatly appreaciated. The PROJ documentation is +PROJ is in dire need of better documentation. Any contributions of +documentation are greatly appreciated. The PROJ documentation is available on `proj4.org <ttp://proj4.org>`__. The website is generated with `Sphinx <http://www.sphinx-doc.org/en/stable/>`__. Contributions to the documentation should be made as `Pull @@ -157,7 +157,7 @@ The general rule is to keep whitespace in whatever form it is in the file you are currently editing. If the file has a mix of tabs and space please convert the tabs to space in a separate commit before making any other changes. This makes it a lot easier to see the changes in diffs -when evaulating the changed code. New files should use spaces as +when evaluating the changed code. New files should use spaces as whitespace. File names @@ -237,6 +237,6 @@ Acknowledgements The *code contribution* section of this CONTRIBUTING file is inspired by `PDAL's <https://github.com/PDAL/PDAL/blob/master/CONTRIBUTING.md>`__ -and the *legalese* section is modified from `GDAL contributer +and the *legalese* section is modified from `GDAL commiter guidelines <https://trac.osgeo.org/gdal/wiki/rfc3_commiters>`__ diff --git a/docs/source/development/migration.rst b/docs/source/development/migration.rst index eb509bcf..1ab0a91d 100644 --- a/docs/source/development/migration.rst +++ b/docs/source/development/migration.rst @@ -144,7 +144,7 @@ example with the old API the source system is described as ``+proj=latlon +ellps=clrk66`` and the destination system is described as ``+proj=merc +ellps=clrk66 +lat_ts=33``. Since the Mercator projection accepts geodetic coordinates as its input, the description of the source in this case -is superflous. We use that to our advantage in the new API and simply state +is superfluous. We use that to our advantage in the new API and simply state the destination. This is simple at a glance, but is actually a big conceptual change. We are now focused on the path between two systems instead of what the source and destination systems are. diff --git a/docs/source/development/reference/datatypes.rst b/docs/source/development/reference/datatypes.rst index 7f2c4b41..7ed2da49 100644 --- a/docs/source/development/reference/datatypes.rst +++ b/docs/source/development/reference/datatypes.rst @@ -8,7 +8,7 @@ This section describes the numerous data types in use in PROJ.4. As a rule of thumb PROJ.4 data types are prefixed with ``PJ_``, or in one particular case, is simply called :c:type:`PJ`. A few notable exceptions can be traced back to the very early days of PROJ.4 when the ``PJ_`` prefix was not -consistenly used. +consistently used. Transformation objects -------------------------------------------------------------------------------- @@ -234,7 +234,7 @@ domain. .. c:type:: PJ_XYZT - Generic spatiotemporal coordinate. Usefull for e.g. cartesian coordinates with + Generic spatiotemporal coordinate. Useful for e.g. cartesian coordinates with an attached time-stamp. .. code-block:: C diff --git a/docs/source/development/reference/functions.rst b/docs/source/development/reference/functions.rst index 38ddbde3..18149139 100644 --- a/docs/source/development/reference/functions.rst +++ b/docs/source/development/reference/functions.rst @@ -15,7 +15,7 @@ Threading contexts .. c:function:: void proj_context_destroy(PJ_CONTEXT *ctx) - Deallacote a threading-context. + Deallocate a threading-context. :param PJ_CONTEXT* ctx: Threading context. @@ -182,15 +182,15 @@ Coordinate transformation :param double* y: Array of y-coordinates :param double* z: Array of z-coordinates :param double* t: Array of t-coordinates - :param size_t sx: Step lenght, in bytes, between consecutive elements of the corresponding array + :param size_t sx: Step length, in bytes, between consecutive elements of the corresponding array :param size_t nx: Number of elements in the corresponding array - :param size_t sy: Step lenght, in bytes, between consecutive elements of the corresponding array + :param size_t sy: Step length, in bytes, between consecutive elements of the corresponding array :param size_t nv: Number of elements in the corresponding array - :param size_t sz: Step lenght, in bytes, between consecutive elements of the corresponding array + :param size_t sz: Step length, in bytes, between consecutive elements of the corresponding array :param size_t nz: Number of elements in the corresponding array - :param size_t st: Step lenght, in bytes, between consecutive elements of the corresponding array + :param size_t st: Step length, in bytes, between consecutive elements of the corresponding array :param size_t nt: Number of elements in the corresponding array - :returns: Number of transformations succesfully completed + :returns: Number of transformations successfully completed @@ -201,7 +201,7 @@ Coordinate transformation :param PJ* P: :param `direction`: Transformation direction :type `direction`: PJ_DIRECTION - :param size_t n: Number of cordinates in :c:data:`coord` + :param size_t n: Number of coordinates in :c:data:`coord` :returns: :c:type:`size_t` 0 if all observations are transformed without error, otherwise returns error number diff --git a/docs/source/operations/conversions/unitconvert.rst b/docs/source/operations/conversions/unitconvert.rst index 73e517bd..50ac832c 100644 --- a/docs/source/operations/conversions/unitconvert.rst +++ b/docs/source/operations/conversions/unitconvert.rst @@ -34,7 +34,7 @@ in Vermont:: +step +proj=tmerc +lat_0=42.5 +lon_0=-72.5 +k=0.999964286 +x_0=500000.00001016 +y_0=0 +step +proj=unitconvert +xy_in=m +xy_out=us-ft -Often when working with GNNS data the timestamps are presented in GPS-weeks, +Often when working with GNSS data the timestamps are presented in GPS-weeks, but when the data transformed with the `helmert` operation timestamps are expected to be in units of decimalyears. This can be fixed with `unitconvert`:: @@ -103,7 +103,7 @@ Time units In the table below all time units supported by PROJ is listed. +--------------+-----------------------------+ -| mjd | Modfied Julian date | +| mjd | Modified Julian date | +--------------+-----------------------------+ | decimalyear | Decimal year | +--------------+-----------------------------+ diff --git a/docs/source/operations/pipeline.rst b/docs/source/operations/pipeline.rst index 18637712..d7694041 100644 --- a/docs/source/operations/pipeline.rst +++ b/docs/source/operations/pipeline.rst @@ -41,8 +41,8 @@ been swapped: Here the first step is applying the :ref:`merc` projection and the second step is applying the :ref:`axisswap` conversion. Note that the `+ellps=GRS80` is specified -before the first occurence of `+step`. This means that the GRS80 ellipsoid is used -in both steps, since any parameter stated before the first occurence of `+step` is +before the first occurrence of `+step`. This means that the GRS80 ellipsoid is used +in both steps, since any parameter stated before the first occurrence of `+step` is treated as a global parameter and is transferred to each individual steps. diff --git a/docs/source/operations/projections/tpers.rst b/docs/source/operations/projections/tpers.rst index 345a5faa..13d49cd7 100644 --- a/docs/source/operations/projections/tpers.rst +++ b/docs/source/operations/projections/tpers.rst @@ -32,7 +32,7 @@ Tilted perspective Tilted Perspective is similar to :ref:`nsper` (``nsper``) in that it simulates a -perspective view from a hight. Where ``nsper`` projects onto a plane tangent to +perspective view from a height. Where ``nsper`` projects onto a plane tangent to the surface, Tilted Perspective orients the plane towards the direction of the view. Thus, extra parameters azi and tilt are required beyond `nsper``'s ``h``. As with ``nsper``, ``lat_0`` & ``lon_0`` are also required diff --git a/docs/source/operations/transformations/deformation.rst b/docs/source/operations/transformations/deformation.rst index 2489f18e..4ae56f54 100644 --- a/docs/source/operations/transformations/deformation.rst +++ b/docs/source/operations/transformations/deformation.rst @@ -28,7 +28,7 @@ The deformation operation is used to adjust coordinates for intraplate deformati Usually the transformation parameters for regional plate-fixed reference frames such as the ETRS89 does not take intraplate deformation into account. It is assumed that tectonic plate of the region is rigid. Often times this is true, but near the plate -boundary and in areas with post-glacial uplift the assumption breaks. Tntraplate +boundary and in areas with post-glacial uplift the assumption breaks. Intraplate deformations can be modelled and then applied to the coordinates so that they represent the physical world better. In PROJ this is done with the deformation operation. @@ -43,10 +43,10 @@ Example In [Häkli2016]_ coordinate transformation including a deformation model is described. The paper describes how coordinates from the global ITRFxx frames are transformed to the -local Nordic realisations of ERTS89. Scandinavia is an area with significant post-glacial +local Nordic realisations of ETRS89. Scandinavia is an area with significant post-glacial rebound. The deformations from the post-glacial uplift is not accounted for in the -offcial ETRS89 transformations so in order to get accurate transformations in the Nordic -countries it is necesarry to apply the deformation model. The transformation from ITRF2008 +official ETRS89 transformations so in order to get accurate transformations in the Nordic +countries it is necessary to apply the deformation model. The transformation from ITRF2008 to the Danish realisation of ETRS89 is in PROJ described as:: proj = pipeline ellps = GRS80 @@ -121,7 +121,7 @@ Corrections are done in cartesian space. Coordinates of the gridded model are in ENU (east, north, up) space because it would otherwise require an enormous 3 dimensional grid to handle the corrections in cartesian space. Keeping the correction in lat/long space reduces the complexity of the grid -significantly. Consequentyly though, the input coordinates needs to be converted to +significantly. Consequently though, the input coordinates needs to be converted to lat/long space when searching for corrections in the grid. This is done with *cart* operation. The converted grid corrections can then be applied to the input coordinates in cartesian space. The conversion from ENU space to cartesian space is done in the diff --git a/docs/source/operations/transformations/helmert.rst b/docs/source/operations/transformations/helmert.rst index 03e5db15..8c862866 100644 --- a/docs/source/operations/transformations/helmert.rst +++ b/docs/source/operations/transformations/helmert.rst @@ -25,7 +25,7 @@ anoether by means of 3-, 4-and 7-parameter shifts, or one of their 6-, 8- and +----------------+--------------------------------------------------------------------+ | `rx` | X-axis rotation in the 3D Helmert [arc seconds]. *Optional*. | +----------------+--------------------------------------------------------------------+ -| `ry` | Y-axis rotatoin in the 3D Helmert [arc seconds]. *Optional*. | +| `ry` | Y-axis rotation in the 3D Helmert [arc seconds]. *Optional*. | +----------------+--------------------------------------------------------------------+ | `rz` | Z-axis rotation in the 3D Helmert [arc seconds]. *Optional*. | +----------------+--------------------------------------------------------------------+ @@ -65,13 +65,13 @@ kinematic transformations from global reference frames to local static frames. All of the parameters described in the table above are marked as optional. This is true as long as at least one parameter is defined in the setup of the transformation. The behaviour of the transformation depends on which parameters are used in the setup. -For instance, if a rate of change paramater is specified a kinematic version of the +For instance, if a rate of change parameter is specified a kinematic version of the transformation is used. The kinematic transformations require an observation time of the coordinate, as well as a central epoch for the transformation. The latter is usually documented alongside the rest of the transformation parameters for a given transformation. -The central eopch is controlled with the parameter `t_epoch`. The observation +The central epoch is controlled with the parameter `t_epoch`. The observation time can either by stated as part of the coordinate when using PROJ's 4D-functionality or it can be controlled in the transformation setup by the parameter `t_obs`. When `t_obs` is specified, all transformed coordinates are @@ -131,7 +131,7 @@ The simplest version of the Helmert transform is the 2D case. In the 2-dimension case only the horizontal coordinates are changed. The coordinates can be translated, rotated and scale. Translation is controlled with the `x` and `y` parameters. The rotation is determined by `theta` and the scale is controlled with -the `s` paramaters. +the `s` parameters. .. note:: @@ -338,9 +338,9 @@ Applying :eq:`propagation` we get the kinematic version of the approximated The Helmert transformation can be applied without using the rotation parameters, -in which case it becomes a simlpe translation of the origin of the coordinate +in which case it becomes a simple translation of the origin of the coordinate system. When using the Helmert in this version equation :eq:`general-helmert` -simplies to: +simplifies to: .. math:: :label: 3param @@ -364,7 +364,7 @@ simplies to: \end{align} That after application of :eq:`propagation` has the following kinematic -countpart: +counterpart: .. math:: :label: 6param diff --git a/docs/source/operations/transformations/hgridshift.rst b/docs/source/operations/transformations/hgridshift.rst index 7f3c9895..63fa5122 100644 --- a/docs/source/operations/transformations/hgridshift.rst +++ b/docs/source/operations/transformations/hgridshift.rst @@ -31,7 +31,7 @@ of the continental US, Alaska and Canada is loaded at the same time:: The ``@`` in the above example states that the grid is optional, in case the grid is not found in the PROJ search path. The list of grids is prioritized so that -grids in the start of the list takes presedence over the grids in the back of the +grids in the start of the list takes precedence over the grids in the back of the list. PROJ supports CTable2, NTv1 and NTv2 files for horizontal grid corrections. Details diff --git a/docs/source/operations/transformations/vgridshift.rst b/docs/source/operations/transformations/vgridshift.rst index e9f78310..c583b273 100644 --- a/docs/source/operations/transformations/vgridshift.rst +++ b/docs/source/operations/transformations/vgridshift.rst @@ -26,14 +26,14 @@ reference from the ellipsoid to the global geoid model, EGM96:: More than one grid can be loaded at the same time, for instance in the case where a better geoid model than the global is available for a certain area. Here the -gridshift is set up so that the local DVR90 geoid model takes presedence over +gridshift is set up so that the local DVR90 geoid model takes precedence over the global model:: +vgridshift +grids=@dvr90.gtx,egm96_16.gtx The ``@`` in the above example states that the grid is optional, in case the grid is not found in the PROJ search path. The list of grids is prioritized so that -grids in the start of the list takes presedence over the grids in the back of the +grids in the start of the list takes precedence over the grids in the back of the list. PROJ supports the GTX file format for vertical grid corrections. Details diff --git a/docs/source/resource_files.rst b/docs/source/resource_files.rst index f39604a2..7a961a1a 100644 --- a/docs/source/resource_files.rst +++ b/docs/source/resource_files.rst @@ -350,12 +350,12 @@ Init files are used for preconfiguring proj-strings for often used transformations, such as those found in the EPSG database. Most init files contain transformations from a given coordinate reference system to WGS84. This makes it easy to transformations between any two coordinate reference systems with -``cs2cs``. Init files can however contain any proj-string and don't necesarily +``cs2cs``. Init files can however contain any proj-string and don't necessarily have to follow the *cs2cs* paradigm where WGS84 is used as a pivot datum. The ITRF init file is a good example of that. A number of init files come pre-bundled with PROJ but it is also possible to -add your own custom init files. PROJ looks for the init files in the directoty +add your own custom init files. PROJ looks for the init files in the directory listed in the ``PROJ_LIB`` environment variable. The format of init files made up of a identifier in angled brackets and a @@ -401,7 +401,7 @@ the ellipsoid as in the following example where the Hayford ellipsoid is used instead of the predefined GRS80 ellipsoid. It is also possible to add additional parameters not specified in the init file, -for instance by adding an obervation epoch when transforming from ITRF2000 to +for instance by adding an observation epoch when transforming from ITRF2000 to ITRF2005: :: diff --git a/docs/source/usage/apps/cct.rst b/docs/source/usage/apps/cct.rst index e6f94526..014e7732 100644 --- a/docs/source/usage/apps/cct.rst +++ b/docs/source/usage/apps/cct.rst @@ -15,7 +15,7 @@ program, performs transformation coordinate systems on a set of input points. The coordinate system transformation can include translation between projected and geographic coordinates as well as the application of datum shifts. -cct is an acromyn meaning *Coordinate Conversion and Transformation*. +cct is an acronym meaning *Coordinate Conversion and Transformation*. The acronym refers to definitions given in the OGC 08-015r2/ISO-19111 standard "Geographical Information -- Spatial Referencing by Coordinates", @@ -33,7 +33,7 @@ professor of Geodesy at the University of Copenhagen, mentor and advisor for a generation of Danish geodesists, colleague and collaborator for two generations of global geodesists, Secretary General for the International Association of Geodesy, IAG (1995--2007), fellow of the -Amercan Geophysical Union (1991), recipient of the IAG Levallois Medal +American Geophysical Union (1991), recipient of the IAG Levallois Medal (2007), the European Geosciences Union Vening Meinesz Medal (2008), and of numerous other honours. @@ -43,7 +43,7 @@ the development of geodesy -- both through his scientific contributions, comprising more than 250 publications, and by his mentoring and teaching of the next generations of geodesists. -As Christian was an avid Fortran programmer, and a keen Unix connoiseur, +As Christian was an avid Fortran programmer, and a keen Unix connoisseur, he would have enjoyed to know that his initials would be used to name a modest Unix style transformation filter, hinting at the tireless aspect of his personality, which was certainly one of the reasons he accomplished diff --git a/docs/source/usage/environmentvars.rst b/docs/source/usage/environmentvars.rst index e1d63543..24954158 100644 --- a/docs/source/usage/environmentvars.rst +++ b/docs/source/usage/environmentvars.rst @@ -4,7 +4,7 @@ Environment variables ================================================================================ -PROJ can be crontrolled by setting environment variables. Most users will +PROJ can be controlled by setting environment variables. Most users will have a use for the :envvar:`PROJ_LIB`. On UNIX systems environment variables can be set for a shell-session with:: diff --git a/docs/source/usage/projections.rst b/docs/source/usage/projections.rst index 871bc161..f5f46f46 100644 --- a/docs/source/usage/projections.rst +++ b/docs/source/usage/projections.rst @@ -93,7 +93,7 @@ Prime Meridian A prime meridian may be declared indicating the offset between the prime meridian of the declared coordinate system and that of greenwich. A prime -meridian is clared using the "pm" parameter, and may be assigned a symbolic +meridian is declared using the "pm" parameter, and may be assigned a symbolic name, or the longitude of the alternative prime meridian relative to greenwich. Currently prime meridian declarations are only utilized by the diff --git a/docs/source/usage/quickstart.rst b/docs/source/usage/quickstart.rst index 077e970c..89ac2172 100644 --- a/docs/source/usage/quickstart.rst +++ b/docs/source/usage/quickstart.rst @@ -33,7 +33,7 @@ utility ``proj`` we can convert the geodetic coordinates to projected space: $ proj +proj=merc +lat_ts=56.5 +ellps=GRS80 If called as above ``proj`` will be in interactive mode, letting you type the -input data manually and getting a responce presented on screen. ``proj`` +input data manually and getting a response presented on screen. ``proj`` works as any UNIX filter though, which means that you can also pipe data to the utility, for instance by using the ``echo`` command: @@ -44,7 +44,7 @@ the utility, for instance by using the ``echo`` command: PROJ also comes bundled with the ``cs2cs`` utility which is used to transform -from onecoordinate reference system to another. Say we want to convert +from one coordinate reference system to another. Say we want to convert the above Mercator coordinates to UTM, we can do that with ``cs2cs``: :: @@ -52,10 +52,10 @@ the above Mercator coordinates to UTM, we can do that with ``cs2cs``: $ echo 3399483.80 752085.60 | cs2cs +proj=merc +lat_ts=56.5 +ellps=GRS80 +to +proj=utm +zone=32 6103992.36 1924052.47 0.00 -Notice the ``+to`` parameter that seperates the source and destination +Notice the ``+to`` parameter that separates the source and destination projection definitions. -If you happen to know the EPSG identifiers for the two cordinates reference +If you happen to know the EPSG identifiers for the two coordinates reference systems you are transforming between you can use those with ``cs2cs``: :: diff --git a/docs/source/usage/transformation.rst b/docs/source/usage/transformation.rst index fd1f2f94..bd32bcd9 100644 --- a/docs/source/usage/transformation.rst +++ b/docs/source/usage/transformation.rst @@ -6,11 +6,11 @@ Geodetic transformation PROJ can do everything from the most simple projection to very complex transformations across many reference frames. While originally developed as a -tool for cartographic projections, PROJ has over time evolved into a powerfull +tool for cartographic projections, PROJ has over time evolved into a powerful generic coordinate transformation engine that makes it possible to do both large scale cartographic projections as well as coordinate transformation at a geodetic high precision level. This chapter delves into the details of how -geodetec transformations of varying complexity can be performed. +geodetic transformations of varying complexity can be performed. In PROJ, two frameworks for geodetic transformations exists, the *cs2cs* framework and the *transformation pipelines* framework. The first is the original, @@ -69,7 +69,7 @@ solutions for a wide spectrum of geodetic tasks. As a first example, let us take a look at the iconic *geodetic → Cartesian → Helmert → geodetic* case (steps 2 to 4 in the example in -the itroduction). In PROJ it can be implemented as +the introduction). In PROJ it can be implemented as :: @@ -161,11 +161,11 @@ specified in the input proj-string. The most common is ``+towgs84``, which is us define a 3- or 7-parameter Helmert shift from the input reference frame to WGS84. Exactly which realization of WGS84 is not specified, hence a fair amount of uncertainty is introduced in this step of the transformation. With the +nadgrids -parameter a non-lineaer planar correction derived from interpolation in a +parameter a non-linear planar correction derived from interpolation in a correction grid can be applied. Originally this was implemented as a means to -transform coordinates between the american datums NAD27 and NAD83, but corrections -can be applied for any datum for which a correction grid exists. The inverse -transform for the horizontal grid shift is "dumb", in the sense that the +transform coordinates between the North American datums NAD27 and NAD83, but +corrections can be applied for any datum for which a correction grid exists. The +inverse transform for the horizontal grid shift is "dumb", in the sense that the correction grid is applied verbatim without taking into account that the inverse operation is non-linear. Similar to the horizontal grid correction, ``+geoidgrids`` can be used to perform grid corrections in the vertical component. @@ -203,7 +203,7 @@ using an approximated 7 parameter transformation. Grid Based Datum Adjustments +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -In many places (notably North America and Austrialia) national geodetic +In many places (notably North America and Australia) national geodetic organizations provide grid shift files for converting between different datums, such as NAD27 to NAD83. These grid shift files include a shift to be applied at each grid location. Actually grid shifts are normally computed based on an diff --git a/html/faq.html b/html/faq.html index 38f6fa3d..0bea1472 100644 --- a/html/faq.html +++ b/html/faq.html @@ -140,7 +140,7 @@ installed by default on Unix), it is possible to use EPSG numbers like this: The <tt>proj/nad/epsg</tt> file can be browsed and searched in a text editor for coordinate systems. There are known to be problems with some coordinate systems, and any coordinate systems with odd axes, a non-greenwich prime -meridian or other quirkyness are unlikely to work properly. Caveat Emptor!<p> +meridian or other quirkiness are unlikely to work properly. Caveat Emptor!<p> <!--------------------------------------------------------------------------> diff --git a/src/PJ_qsc.c b/src/PJ_qsc.c index 36dabeb9..0f5d2299 100644 --- a/src/PJ_qsc.c +++ b/src/PJ_qsc.c @@ -14,7 +14,7 @@ * is described in * [LK12] * M. Lambers and A. Kolb, "Ellipsoidal Cube Maps for Accurate Rendering of - * Planetary-Scale Terrain Data", Proc. Pacfic Graphics (Short Papers), Sep. + * Planetary-Scale Terrain Data", Proc. Pacific Graphics (Short Papers), Sep. * 2012 * * You have to choose one of the following projection centers, diff --git a/src/pj_inv.c b/src/pj_inv.c index 4ea88b69..9918c59d 100644 --- a/src/pj_inv.c +++ b/src/pj_inv.c @@ -115,9 +115,9 @@ static PJ_COORD pj_inv_prepare (PJ *P, PJ_COORD coo) { return coo; /* Classic proj.4 functions expect plane coordinates in units of the semimajor axis */ - /* Multiplying by ra, rather than dividing by a because the CALCOFI projection */ + /* Multiplying by ra, rather than dividing by a because the CalCOFI projection */ /* stomps on a and hence (apparently) depends on this to roundtrip correctly */ - /* (CALCOFI avoids further scaling by stomping - but a better solution is possible) */ + /* (CalCOFI avoids further scaling by stomping - but a better solution is possible) */ coo.xyz.x *= P->ra; coo.xyz.y *= P->ra; return coo; |