diff options
35 files changed, 482 insertions, 2120 deletions
diff --git a/.travis.yml b/.travis.yml index 31ab75d0..e9eeb033 100644 --- a/.travis.yml +++ b/.travis.yml @@ -39,8 +39,8 @@ matrix: - BUILD_NAME=mingw32 - DETAILS="mingw32" -# allow_failures: -# - os: osx + allow_failures: + - env: BUILD_NAME=mingw32 before_install: ./travis/${BUILD_NAME}/before_install.sh 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) @@ -59,13 +59,14 @@ If this default path prefix is proper, then execute: ./configure +See the note below if you are building PROJ directly from the git repository. + If another path prefix is required, then execute: ./configure --prefix=/my/path In either case, the directory of the prefix path must exist and be writable by the installer. - After executing configure, execute: make @@ -80,6 +81,14 @@ Tests are run with The test suite requires that the proj-datumgrid package is installed in `PROJ_LIB`. +#### Building from the git repository + +If you are building from the git repository you have to first run + + ./autogen.sh + +which will generate a configure script that can be used as described above. + ### Building on Windows with NMAKE PROJ can be built with Microsoft Visual C/C++ using the `makefile.vc` 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 07c53630..3d141ae2 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 @@ -427,7 +427,7 @@ Various :returns: :c:type:`PJ_COORD` -.. c:function:: double proj_roundtrip(PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coo) +.. c:function:: double proj_roundtrip(PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coord) Measure internal consistency of a given transformation. The function performs :c:data:`n` round trip transformations starting in either @@ -440,7 +440,7 @@ Various :param `direction`: Starting direction of transformation :type `direction`: PJ_DIRECTION :param int n: Number of roundtrip transformations - :param PJ_OBS obs: Input coordinate + :param PJ_COORD coord: Input coordinate :returns: :c:type:`double` Distance between original coordinate and the \ resulting coordinate after :c:data:`n` transformation iterations. @@ -495,7 +495,7 @@ Various :returns: :c:type:`char*` Pointer to output buffer (same as :c:data:`s`) -.. c:function:: PJ_COORD proj_geocentric_latitude(const PJ *P, PJ_DIRECTION direction, PJ_COORD coo) +.. c:function:: PJ_COORD proj_geocentric_latitude(const PJ *P, PJ_DIRECTION direction, PJ_COORD coord) Convert from geographical latitude to geocentric latitude. @@ -503,8 +503,8 @@ Various :type `P`: const PJ* :param `direction`: Starting direction of transformation :type `direction`: PJ_DIRECTION - :param `coo`: Coordinate - :type `coo`: PJ_COORD + :param `coord`: Coordinate + :type `coord`: PJ_COORD :returns: :c:type:`PJ_COORD` Converted coordinate 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/CMakeLists.txt b/html/CMakeLists.txt deleted file mode 100644 index 2c0bdc7b..00000000 --- a/html/CMakeLists.txt +++ /dev/null @@ -1,12 +0,0 @@ -set(HTML_DOC_FILE faq.html - gen_parms.html - index.html - man_cs2cs.html - man_geod.html - man_pj_init.html - man_proj.html - proj_logo.png) - -install(FILES ${HTML_DOC_FILE} - DESTINATION ${DOCDIR} - PERMISSIONS WORLD_READ WORLD_WRITE) diff --git a/html/faq.html b/html/faq.html deleted file mode 100644 index 38f6fa3d..00000000 --- a/html/faq.html +++ /dev/null @@ -1,227 +0,0 @@ -<html> -<head> -<title>PROJ.4 - Frequently Asked Questions</title> -</head> -<body BGCOLOR="#FFFFFF"> -<h1>PROJ.4 - Frequently Asked Questions</h1> - -<!--------------------------------------------------------------------------> - -<h2><a name="proj_docs">Where can I find the list of projections and their arguments?</a></h2> - -There is no simple single location to find all the required information. The -PostScript/PDF documents listed on the <a href="index.html">main</a> PROJ.4 -page under documentation are the authoritative source but projections and -options are spread over several documents in a form more related to their -order of implementation than anything else.<pp> - -The <b>proj</b> command -itself can report the list of projections using the <tt>-lp,</tt> option, -the list of ellipsoids with the <tt>-le</tt> option, the list of units with -the <tt>-lu</tt> option, and the list of built-in datums with the <tt>-ld</tt> -option.<p> - -The <a href="http://www.remotesensing.org/geotiff/proj_list/">GeoTIFF -Projections Pages</a> include most of the common PROJ.4 projections, and -a definition of the projection specific options for each.<p> - -<!--------------------------------------------------------------------------> - -<h2><a name="nad2783">How do I do datum shifts between NAD27 and NAD83?</a></h2> - -While the <b>nad2nad</b> program can be used in some cases, the <b>cs2cs</b> -is now the preferred mechanism. The following example demonstrates using -the default shift parameters for NAD27 to NAD83:<p> - -<pre> -% cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83 --117 30 -</pre> -<p> - -producing:<p> - -<pre> -117d0'2.901"W 30d0'0.407"N 0.000 -</pre> - -<p> -In order for datum shifting to work properly the various grid shift files -must be available. See below. More details are available in the -<a href="gen_parms.html#nadgrids">General Parameters</a> document.<p> - -<!--------------------------------------------------------------------------> - -<h2><a name="datumshifting">How do I build/configure PROJ.4 to support datum shifting.</a></h2> - -After downloading and unpacking the PROJ.4 source, also download and unpack -the set of datum shift files. This would be a file like -<a href="ftp://ftp.remotesensing.org/pub/proj/proj-datumgrid-1.3.zip"> -ftp://ftp.remotesensing.org/pub/proj/proj-datumgrid-1.3.zip</a>. This -file should be unpacked <i>within</i> the <tt>proj/nad</tt> directory. -Then proceed with the configuration, build and install. This will ensure -that the build system knows about the grid shift files, and applies the -ascii to binary preprocessing step.<p> - -On Windows the extra <tt>nadshift</tt> target must be used. For instance -<tt>nmake /f makefile.vc nadshift</tt> in the <tt>proj/src</tt> directory. -<p> - -A default build and install on Unix will normally build knowledge of the -directory where the grid shift files are installed into the PROJ.4 library -(usually /usr/local/share/proj). On Windows the library is normally built -thinking that C:\PROJ\NAD is the installed directory for the grid shift files. -If the built in concept of the PROJ.4 data directory is incorrect, the PROJ_LIB -environment can be defined with the correct directory.<p> - -<!--------------------------------------------------------------------------> - -<h2><a name="nad2783_debug">How do I debug problems with NAD27/NAD83 datum shifting?</a></h2> - -<ol> -<li> Verify that you have the binary files (eg. /usr/local/share/proj/conus) -installed on your system. If not, see the previous question. -<p> -<li> Try a datum shifting operation in relative isolation, such as with the -cs2cs command listed above. Do you get reasonable results? If not it is -likely the grid shift files aren't being found. Perhaps you need to define -PROJ_LIB? <p> - -<li> The cs2cs command and the underlying pj_transform() API know how to -do a grid shift as part of a more complex coordinate transformation; however, -it is imperative that both the source and destination coordinate system be -defined with appropriate datum information. That means that implicitly or -explicitly there must be a +datum= clause, a +nadgrids= clause or -a +towgs84= clause. For instance "cs2cs +proj=latlong +datum=NAD27 +to -+proj=latlong +ellps=WGS84" won't work because defining the output coordinate -system as using the ellipse WGS84 isn't the same as defining it to use the -datum WGS84 (use +datum=WGS84). If either the input or output are not -identified as having a datum, the datum shifting (and ellipsoid change) step -is just quietly skipped!<p> - -<li> The PROJ_DEBUG environment can be defined (any value) to force extra -output from -the PROJ.4 library to stderr (the text console normally) with information on -what data files are being opened and in some cases why a transformation fails. -Note that PROJ_DEBUG support is not yet very mature in the PROJ.4 library.<p> - -<li> The "-v" flag to cs2cs can be useful in establishing more detail on -what parameters being used internally for a coordinate system. This will -include expanding the definition of +datum clause. <p> - -</ol> - -<!--------------------------------------------------------------------------> - -<h2><a name="epsg">How do I use EPSG coordinate system codes with PROJ.4?</a></h2> - -There is somewhat imperfect translation between 2d geographic and -projected coordinate system codes and PROJ.4 descriptions of the -coordinate system available in the <tt>epsg</tt> definition file that -normally lives in the <tt>proj/nad</tt> directory. If installed (it is -installed by default on Unix), it is possible to use EPSG numbers like this: - -<pre> -% cs2cs -v +init=epsg:26711 -# ---- From Coordinate System ---- -#Universal Transverse Mercator (UTM) -# Cyl, Sph -# zone= south -# +init=epsg:26711 +proj=utm +zone=11 +ellps=clrk66 +datum=NAD27 +units=m -# +no_defs +nadgrids=conus,ntv1_can.dat -#--- following specified but NOT used -# +ellps=clrk66 -# ---- To Coordinate System ---- -#Lat/long (Geodetic) -# -# +proj=latlong +datum=NAD27 +ellps=clrk66 +nadgrids=conus,ntv1_can.dat -</pre> - -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> - -<!--------------------------------------------------------------------------> - -<h2><a name="datum_37">How do I use 3 parameter and 7 parameter datum shifting</a></h2> - -Datum shifts can be approximated with 3 and 7 parameter transformations. -Their use is more fully described in the -<a href="gen_parms.html#towgs84">towgs84</a> discussions.<p> - - -<!--------------------------------------------------------------------------> - -<h2><a name="locale">Does PROJ.4 work in different international numeric locales?</a></h2> - -No. PROJ.4 makes extensive use of sprintf() and atof() internally to translate -numeric values. If a locale is in effect that modifies formatting of -numbers, altering the role of commas and periods in numbers, then PROJ.4 -will not work. This problem is common in some European locales.<p> - -On unix-like platforms, this problem can be avoided by forcing the use -of the default numeric locale by setting the LC_NUMERIC environment variable -to C. <p> - -eg. -<pre> -$ export LC_NUMERIC=C -$ proj ... -</pre> - -<!--------------------------------------------------------------------------> - -<h2><a name="sphere_as_wgs84">Changing Ellipsoid / Why can't I convert from WGS84 to Virtual Earth Mercator?</a></h2> - -The coordinate system definition for Virtual Earth Mercator is as follows, -which uses a sphere as the earth model for the mercator projection. - -<pre> -+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 - +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs -</pre> - -But, if you do something like: - -<pre> -cs2cs +proj=latlong +datum=WGS84 - +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 - +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs -</pre> - -to convert between WGS84 and mercator on the sphere there will be substantial -shifts in the Y mercator coordinates. This is because internally cs2cs is -having to adjust the lat/long coordinates from being on the sphere to being -on the WGS84 datum which has a quite differently shaped ellipsoid.<p> - -In this case, and many other cases using spherical projections, the desired -approach is to actually treat the lat/long locations on the sphere as if -they were on WGS84 without any adjustments when using them for converting -to other coordinate systems. The solution is to "trick" PROJ.4 into applying -no change to the lat/long values when going to (and through) WGS84. This -can be accomplished by asking PROJ to use a <i>null</i> grid shift file -for switching from your spherical lat/long coordinates to WGS84.<p> - -<pre> -cs2cs +proj=latlong +datum=WGS84 - +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 - +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs -</pre> - -Note the strategic addition of <tt>+nadgrids=@null</tt> to the spherical -projection definition.<p> - -Similar issues apply with many other datasets distributed with projections -based on a spherical earth model - such as many NASA datasets, and also -(I think) the Google Maps mercator projection.<p> - -<!--------------------------------------------------------------------------> - -<hr> - -Requests to add items to the frequently asked questions list -<a href="http://bugzilla.remotesensing.org/enter_bug.cgi?product=PROJ.4"> -can be entered</a> in bugzilla.<p> -</body> -</html> diff --git a/html/gen_parms.html b/html/gen_parms.html deleted file mode 100644 index 8cd8e161..00000000 --- a/html/gen_parms.html +++ /dev/null @@ -1,276 +0,0 @@ -<html> -<head> -<title>PROJ.4 - General Parameters</title> -</head> -<body BGCOLOR="#FFFFFF"> -<h1>PROJ.4 - General Parameters</h1> - -This document attempts to describe a variety of the PROJ.4 parameters -which can be applied to all, or many coordinate system definitions. This -document does not attempt to describe the parameters particular to particular -projection types. Some of these can be found in the GeoTIFF -<a href="http://www.remotesensing.org/geotiff/proj_list/">Projections -Transform List</a>. The definitive documentation for most parameters -is Gerald's original documentation available from the main PROJ.4 page. <p> - -<hr> -<h2><a name="false_easting_northing">False Easting/Northing</a></h2> - -Virtually all coordinate systems allow for the presence of a false easting -(+x_0) and northing (+y_0). Note that these values are always expressed in -meters even if the coordinate system is some other units. Some coordinate -systems (such as UTM) have implicit false easting and northing values.<p> - -<hr> -<h2><a name="pm">pm - Prime Meridian</a></h2> - -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 -name, or the longitude of the alternative prime meridian relative to -greenwich. <p> - -Currently prime meridian declarations are only utilized by the -pj_transform() API call, not the pj_inv() and pj_fwd() calls. Consequently -the user utility <b>cs2cs</b> does honour prime meridians but the <b>proj</b> -user utility ignores them. <p> - -The following predeclared prime meridian names are supported. These -can be listed using the cs2cs argument <b>-lm</b>.<p> -<pre> - greenwich 0dE - lisbon 9d07'54.862"W - paris 2d20'14.025"E - bogota 74d04'51.3"E - madrid 3d41'16.48"W - rome 12d27'8.4"E - bern 7d26'22.5"E - jakarta 106d48'27.79"E - ferro 17d40'W - brussels 4d22'4.71"E - stockholm 18d3'29.8"E - athens 23d42'58.815"E - oslo 10d43'22.5"E -</pre> - -Example of use. The location long=0, lat=0 in the greenwich based -lat/long coordinates is translated to lat/long coordinates with Madrid -as the prime meridian. <p> - -<pre> - cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid -0 0 <i>(input)</i> -3d41'16.48"E 0dN 0.000 <i>(output)</i> -</pre> - -<hr> -<h2><a name="towgs84">towgs84 - Datum transformation to WGS84</a></h2> - -Datum shifts can be approximated by 3 parameter spatial translations (in -geocentric space), or 7 parameter shifts (translation + rotation + scaling). -The parameters to describe this can be described using the <b>towgs84</b> -parameter.<p> - -In the three parameter case, the three arguments are the translations to the -geocentric location in meters.<p> - -For instance, the following demonstrates converting from the Greek GGRS87 -datum to WGS84.<p> - -<pre> -% cs2cs +proj=latlong +ellps=GRS80 +towgs84=-199.87,74.79,246.62 \ - +to +proj=latlong +datum=WGS84 -20 35 -20d0'5.467"E 35d0'9.575"N 8.570 -</pre> - -The EPSG database provides this example for transforming from WGS72 to WGS84 -using an approximated 7 parameter transformation.<p> -<pre> -% cs2cs +proj=latlong +ellps=WGS72 +towgs84=0,0,4.5,0,0,0.554,0.219 \ - +to +proj=latlong +datum=WGS84 -4 55 -4d0'0.554"E 55d0'0.09"N 3.223 -</pre> - -The seven parameter case uses <i>delta_x</i>, <i>delta_y</i>, <i>delta_z</i>, -<i>Rx - rotation X</i>, <i>Ry - rotation Y</i>, <i>Rz - rotation Z</i>, -<i>M_BF - Scaling</i>. The three translation parameters are in meters as -in the three parameter case. The rotational parameters are in seconds of -arc. The scaling is apparently the scale change in parts per million.<p> - -A more complete discussion of the 3 and 7 parameter transformations can be -found in the EPSG database (trf_method's 9603 and 9606). Within PROJ.4 -the following calculations are used to apply the <b>towgs84</b> transformation -(going to WGS84). The x, y and z coordinates are in geocentric coordinates. - -Three parameter transformation (simple offsets): - -<pre> - x[io] = x[io] + defn->datum_params[0]; - y[io] = y[io] + defn->datum_params[1]; - z[io] = z[io] + defn->datum_params[2]; -</pre> - -Seven parameter transformation (translation, rotation and scaling): - -<pre> - #define Dx_BF (defn->datum_params[0]) - #define Dy_BF (defn->datum_params[1]) - #define Dz_BF (defn->datum_params[2]) - #define Rx_BF (defn->datum_params[3]) - #define Ry_BF (defn->datum_params[4]) - #define Rz_BF (defn->datum_params[5]) - #define M_BF (defn->datum_params[6]) - - x_out = M_BF*( x[io] - Rz_BF*y[io] + Ry_BF*z[io]) + Dx_BF; - y_out = M_BF*( Rz_BF*x[io] + y[io] - Rx_BF*z[io]) + Dy_BF; - z_out = M_BF*(-Ry_BF*x[io] + Rx_BF*y[io] + z[io]) + Dz_BF; -</pre> - -Note that EPSG method 9607 (coordinate frame rotation) coefficients can be -converted to EPSG method 9606 (position vector 7-parameter) supported by -PROJ.4 by reversing the sign of the rotation vectors. The methods are -otherwise the same.<p> - -<hr> -<h2><a name="nadgrids">nadgrids - Grid Based Datum Adjustments</a></h2> - -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 interpolation between the containing four grid points.<p> - -PROJ.4 currently supports use of grid shift files for shifting between -datums and WGS84 under some circumstances. The grid shift table formats are -ctable (the binary format produced by the PROJ.4 nad2bin program), -NTv1 (the old Canadian format), and NTv2 (.gsb - the new Canadian and -Australian format).<p> - -Use of grid shifts is specified using the "nadgrids" keyword in a coordinate -system definition. For example:<p> - -<pre> -% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=ntv1_can.dat \ - +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF --111 50 -EOF -111d0'2.952"W 50d0'0.111"N 0.000 -</pre> - -In this case the /usr/local/share/proj/ntv1_can.dat grid shift file -was loaded, and used to get a grid shift value for the selected point. <p> - -It is possible to list multiple grid shift files, in which case each will be -tried in turn till one is found that contains the point being transformed.<p> - -<pre> -% cs2cs +proj=latlong +ellps=clrk66 \ - +nadgrids=conus,alaska,hawaii,stgeorge,stlrnc,stpaul \ - +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF --111 44 -EOF -111d0'2.788"W 43d59'59.725"N 0.000 -</pre> - -<h3>Skipping Missing Grids</h3> - -The special prefix <b>@</b> may be prefixed to a grid to make it optional. If -it not found, the search will continue to the next grid. Normally any -grid not found will cause an error. For instance, the following would -use the ntv2_0.gsb file if available, otherwise it would fallback to using -the ntv1_can.dat file. <p> - -<pre> -% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=@ntv2_0.gsb,ntv1_can.dat \ - +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF --111 50 -EOF -111d0'3.006"W 50d0'0.103"N 0.000 -</pre> - -<h3>The null Grid</h3> - -A special <b>null</b> grid shift file is shift with releases after 4.4.6 (not -inclusive). This file provides a zero shift for the whole world. It may -be listed at the end of a nadgrids file list if you want a zero shift to -be applied to points outside the valid region of all the other grids. -Normally if no grid is found that contains the point to be transformed an -error will occur.<p> - -<pre> -% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=conus,null \ - +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF --111 45 -EOF -111d0'3.006"W 50d0'0.103"N 0.000 -</pre> - -<pre> -% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=conus,null \ - +to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF --111 44 --111 55 -EOF -111d0'2.788"W 43d59'59.725"N 0.000 -111dW 55dN 0.000 -</pre> - -<h3>Downloading and Installing Grids</h3> - -The source distribution of PROJ.4 contains only the ntv1_can.dat file. To -get the set of US grid shift files it is necessary to download an additional -distribution of files from the PROJ.4 site, such as -<a href="ftp://ftp.remotesensing.org/pub/proj/proj-nad27-1.1.tar.gz"> -proj-nad27-1.1.tar.gz</a>. Overlay it on the PROJ.4 source distribution, -and re-configure, compile and install. The distributed ASCII .lla files -are converted into binary (platform specific) files that are installed. -On windows using the <tt>nmake /f makefile.vc nadshift</tt> command in -the <tt>proj\src</tt> directory to build and install these files. <p> - -It appears we can't redistribute the Canadian NTv2 grid shift file freely, -though it is better than the NTv1 file. However, end users can download it -for free from the NRCan web site at -<a href="http://www.geod.nrcan.gc.ca/software/ntv2_e.php"> -http://www.geod.nrcan.gc.ca/software/ntv2_e.php</a>. After -downloading it, just dump it in the data directory with the other -installed data files (usually /usr/local/share/proj). <p> - -<h3>Caveats</h3> - -<ol> - -<li> Where grids overlap (such as conus and ntv1_can.dat for instance) the -first found for a point will be used regardless of whether it is appropriate -or not. So, for instance, +nadgrids=ntv1_can.dat,conus would result in the -canadian data being used for some areas in the northern United States even -though the conus data is the approved data to use for the area. Careful -selection of files and file order is necessary. In some cases border spanning -datasets may need to be pre-segmented into Canadian and American points -so they can be properly grid shifted.<p> - -<li> There are additional grids for shifting between NAD83 and various -HPGN versions of the NAD83 datum. Use of these haven't been tried recently -so you may encounter problems. The FL.lla, WO.lla, MD.lla, TN.lla and WI.lla -are examples of high precision grid shifts. Take care!<p> - -<li> Additional detail on the grid shift being applied can be found by -setting the PROJ_DEBUG environment variable to a value. This will result -in output to stderr on what grid is used to shift points, the bounds of the -various grids loaded and so forth.<p> - -<li> PROJ.4 always assumes that grids contain a shift <b>to</b> NAD83 -(essentially WGS84). Other types of grids might or might not be usable.<p> - -</ol> - -</body> -</html> - - - - - - - diff --git a/html/index.html b/html/index.html deleted file mode 100644 index e56f5767..00000000 --- a/html/index.html +++ /dev/null @@ -1,13 +0,0 @@ -<HTML> -<HEAD> -<!-- Send users to the new location. --> -<TITLE>redirect</TITLE> -<META HTTP-EQUIV="refresh" -CONTENT="1;URL=http://trac.osgeo.org/proj"> -</HEAD> -<BODY> -This page has moved. You will be automatically redirected to its new location. -If you aren't forwarded to the new page, -<a href="http://trac.osgeo.org/proj">click here</a>. -</BODY> -</HTML> diff --git a/html/man_cs2cs.html b/html/man_cs2cs.html deleted file mode 100644 index 5454714b..00000000 --- a/html/man_cs2cs.html +++ /dev/null @@ -1,302 +0,0 @@ -Content-type: text/html; charset=UTF-8 - -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<HTML><HEAD><TITLE>Man page of CS2CS</TITLE> -</HEAD><BODY> -<H1>CS2CS</H1> -Section: User Commands (1)<BR>Updated: 2000/03/21 Rel. 4.4<BR><A HREF="#index">Index</A> -<A HREF="../index.html">Return to Main Contents</A><HR> - -<A NAME="lbAB"> </A> -<H2>NAME</H2> - -cs2cs - cartographic coordinate system filter -<A NAME="lbAC"> </A> -<H2>SYNOPSIS</H2> - -<B>cs2cs</B> - -[ -<B>-eEfIlrstvwW</B> - -[ -<I>args</I> - -] ] [ -<B>+opts[=arg]</B> - -] -<BR> - -<BR> [ <B>+to</B> [<B>+opts</B>[<B>=arg</B>]] ] -file[s] -<A NAME="lbAD"> </A> -<H2>DESCRIPTION</H2> - -<I>Cs2cs</I> - -performs transformation between the source and destination cartographic -coordinate system 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. -<P> - -The following control parameters can appear in any order: -<DL COMPACT> -<DT><B>-I</B> - -<DD> -method to specify inverse translation, convert from <B>+to</B> coordinate -system to the primary coordinate system defined. -<DT><B>-t</B><I>a</I> - -<DD> -<I>A</I> - -specifies a character employed as the first character to denote -a control line to be passed through without processing. -This option applicable to ascii input only. -(# is the default value). -<DT><B>-e</B><I> string</I> - -<DD> -<I>String</I> - -is an arbitrary string to be output if an error is detected during -data transformations. -The default value is: *\t*. -Note that if the -<B>-b,</B> - -<B>-i</B> - -or -<B>-o</B> - -options are employed, an error is returned as HUGE_VAL -value for both return values. -<DT><B>-E</B> - -<DD> -causes the input coordinates to be copied to the output line -prior to printing the converted values. -<DT><B>-l</B><I>[p|P|=|e|u|d]</I><B>id</B> - -<DD> -List projection identifiers with -<B>-l,</B> - -<B>-lp</B> - -or -<B>-lP (expanded)</B> - -that can be selected with -<B>+proj.</B> - -<B>-l=</B><I>id</I> - -gives expanded description of projection -<I>id.</I> - -List ellipsoid identifiers with -<B>-le,</B> - -that can be selected with -<B>+ellps,</B> - -<B>-lu</B> - -list of cartesian to meter conversion factors -that can be selected with -<B>+units</B> - -or -<B>-ld</B> - -list of datums that can be selected with -<B>+datum.</B> - -<DT><B>-r</B> - -<DD> -This options reverses the order of the -expected input from longitude-latitude or x-y to latitude-longitude or y-x. -<DT><B>-s</B> - -<DD> -This options reverses the order of the -output from x-y or longitude-latitude to y-x or latitude-longitude. -<DT><B>-f</B><I> format</I> - -<DD> -<I>Format</I> - -is a -<I>printf</I> - -format string to control the form of the output values. -For inverse projections, the output will be in degrees when this option -is employed. -If a format is specified for inverse projection the -output data will be in decimal degrees. -The default format is "%.2f" for forward projection and DMS -for inverse. -<DT><B>-[w|W]</B><I>n</I> - -<DD> -<I>N</I> - -is the number of significant fractional digits to employ for -seconds output (when the option is not specified, -<B>-w3</B> - -is assumed). -When -<B>-W</B> - -is employed the fields will be constant width and with leading zeroes. -<DT><B>-v</B> - -<DD> -causes a listing of cartographic control parameters tested for and -used by the program to be printed prior to input data. -</DL> -<P> - -The -<B>+args</B> - -run-line arguments are associated with cartographic parameters -and usage varies with projection and for a complete description see -<I>Cartographic Projection Procedures for the UNIX Environment---A User's Manual</I> - -and supplementary documentation for Release 4. -<P> - -The <I>cs2cs</I> program requires two coordinate system definitions. The -first (or primary is defined based on all projection parameters not -appearing after the <B>+to</B> argument. All projection parameters -appearing after the <B>+to</B> argument are considered the definition -of the second coordinate system. If there is no second coordinate system -defined, a geographic coordinate system based on the datum and ellipsoid of -the source coordinate system is assumed. Note that the source and destination -coordinate system can both be projections, both be geographic, or one of -each and may have the same or different datums. -<P> - -Additional projection control parameters may be contained in two -auxiliary control files: -the first is optionally referenced with the -<B>+init=</B><I>file:id</I> - -and the second is always processed after the name -of the projection has been established from either the run-line -or the contents of -<B>+init</B> - -file. -The environment parameter -<B>PROJ_LIB</B> - -establishes the default directory for a file reference without -an absolute path. This is also used for supporting files like -datum shift files. -<P> - -One or more -<I>files</I> - -(processed in left to right order) -specify the source of data to be transformed. -A - will specify the location of processing standard input. -If no files are specified, the input is assumed to be from -<I>stdin.</I> - -For input data the two data values must be in the -first two white space separated fields and -when both input and output are ASCII all trailing portions -of the input line are appended to the output line. -<P> - -Input geographic data -(longitude and latitude) must be in DMS or decimal degrees format and input -cartesian data must be in units consistent with the ellipsoid -major axis or sphere radius units. -Output geographic coordinates will normally be in DMS format (use -<B>-f %.12f </B> - -for decimal degrees with 12 decimal places), while -projected (cartesian) coordinates will be in linear (meter, feet) units. - -<A NAME="lbAE"> </A> -<H2>EXAMPLE</H2> - -The following script -<DL COMPACT><DT><DD> -<BR> <TT>cs2cs +proj=latlong +datum=NAD83 -<BR> +to +proj=utm +zone=10 +datum=NAD27 -r <<EOF -<BR> 45d15'33.1"<TT> </TT>111.5W<BR> -<BR> 45d15.551666667N<TT> </TT>-111d30<BR> -<BR> +45.25919444444<TT> </TT>111d30'000w<BR> -<BR> EOF</TT> -</DL> - -will transform the input NAD83 geographic coordinates into NAD27 coordinates -in the UTM projection with zone 10 selected. -The geographic values of this example are equivalent and meant -as examples of various forms of DMS input. -The x-y output data will appear as three lines of: -<DL COMPACT><DT><DD> -<BR> <TT>1402285.99 5076292.42 0.000 -</DL> - -</TT><A NAME="lbAF"> </A> -<H2>SEE ALSO</H2> - -<B><A HREF="../man1/proj.1.html">proj</A>(1),</B> - -<BR> - -<I>Cartographic Projection Procedures for the UNIX Environment---A User's Manual,</I> - -(Evenden, 1990, Open-file report 90-284). -<BR> - -<I>Map Projections Used by the U. S. Geological Survey</I> - -(Snyder, 1984, -USGS Bulletin 1532). -<BR> - -<I>Map Projections---A Working Manual</I> - -(Snyder, 1988, USGS Prof. Paper 1395). -<BR> - -<I>An Album of Map Projections</I> - -(Snyder & Voxland, 1989, USGS Prof. Paper 1453). -<A NAME="lbAG"> </A> -<H2>HOME PAGE</H2> - -<A HREF="https://github.com/OSGeo/proj.4/wiki">https://github.com/OSGeo/proj.4/wiki</A> -<P> - -<HR> -<A NAME="index"> </A><H2>Index</H2> -<DL> -<DT><A HREF="#lbAB">NAME</A><DD> -<DT><A HREF="#lbAC">SYNOPSIS</A><DD> -<DT><A HREF="#lbAD">DESCRIPTION</A><DD> -<DT><A HREF="#lbAE">EXAMPLE</A><DD> -<DT><A HREF="#lbAF">SEE ALSO</A><DD> -<DT><A HREF="#lbAG">HOME PAGE</A><DD> -</DL> -<HR> -This document was created by -<A HREF="/cgi-bin/man/man2html">man2html</A>, -using the manual pages.<BR> -Time: 20:43:10 GMT, February 18, 2016 -</BODY> -</HTML> diff --git a/html/man_geod.html b/html/man_geod.html deleted file mode 100644 index 8150b4d1..00000000 --- a/html/man_geod.html +++ /dev/null @@ -1,305 +0,0 @@ -<HTML><HEAD><TITLE>Manpage of GEOD</TITLE> -</HEAD><BODY> -<H1>GEOD</H1> -Section: User Commands (1)<BR>Updated: 2000/03/21 Rel. 4.4<BR><A HREF="#index">Index</A> -<A HREF="../index.html">Return to Main Contents</A><HR> - -<A NAME="lbAB"> </A> -<H2>NAME</H2> - -geod - direct geodesic computations -<BR> - -invgeod - inverse geodesic computations -<A NAME="lbAC"> </A> -<H2>SYNOPSIS</H2> - -<B>geod</B> - -<B>+ellps=<ellipse></B> - -[ -<B>-afFIlptwW</B> - -[ -<I>args</I> - -] ] [ -<B>+args</B> - -] -file[s] -<BR> - -<B>invgeod</B> - -<B>+ellps=<ellipse></B> - -[ -<B>-afFIlptwW</B> - -[ -<I>args</I> - -] ] [ -<B>+args</B> - -] -file[s] -<A NAME="lbAD"> </A> -<H2>DESCRIPTION</H2> - -<I>Geod</I> - -(direct) and -<I>invgeod</I> - -(inverse) -perform geodesic (``Great Circle'') computations for determining -latitude, longitude and back azimuth of a terminus point -given a initial point latitude, longitude, azimuth and distance (direct) or -the forward and back azimuths and distance between an initial and -terminus point latitudes and longitudes (inverse). -<P> - -The following runline control parameters can appear in any order: -<DL COMPACT> -<DT><B>-I</B> - -<DD> -Specifies that the inverse geodesic computation is to be performed. -May be used with execution of -<B>goed</B> - -as an alternative to -<B>invgeod</B> - -execution. -<DT><B>-a</B> - -<DD> -Latitude and longitudes of the initial and terminal points, -forward and back azimuths and distance are output. -<DT><B>-t</B><I>a</I> - -<DD> -<I>A</I> - -specifies a character employed as the first character to denote -a control line to be passed through without processing. -<DT><B>-le</B> - -<DD> -Gives a listing of all the ellipsoids that may be selected with the -<B>+ellps=</B> - -option. -<DT><B>-lu</B> - -<DD> -Gives a listing of all the units that may be selected with the -<B>+units=</B> - -option. -<DT><B>-[f|F]</B><I> format</I> - -<DD> -<I>Format</I> - -is a -<I>printf</I> - -format string to control the output form of the geographic coordinate values -(<B>f</B>) or distance value (<B>F</B>). -The default mode is DMS for geographic coordinates and "%.3f" for distance. -<DT><B>-[w|W]</B><I>n</I> - -<DD> -<I>N</I> - -is the number of significant fractional digits to employ for -seconds output (when the option is not specified, -<B>-w3</B> - -is assumed). -When -<B>-W</B> - -is employed the fields will be constant width with leading zeroes. -<DT><B>-p</B> - -<DD> -This option causes the azimuthal values to be output as unsigned -DMS numbers between 0 and 360 degrees. Also note -f. -</DL> -<P> - -The -<B>+args</B> - -run-line arguments are associated with geodetic parameters -for specifying the ellipsoidal or sphere to use. -See -<B>proj</B> - -documentation for full list of these parameters and contrl. -The options are processed in left to right order -from the run line. -Reentry of an option is ignored with the first occurrence assumed to -be the desired value. -<P> - -One or more -<I>files</I> - -(processed in left to right order) -specify the source of data to be transformed. -A - will specify the location of processing standard input. -If no files are specified, the input is assumed to be from -<I>stdin.</I> - -<P> - -For direct determinations input data must be in latitude, -longitude, azimuth and distance order and output will be -latitude, longitude and back azimuth of the terminus point. -Latitude, longitude of the initial and terminus point are -input for the inverse mode and respective forward and back -azimuth from the initial and terminus points are output along -with the distance between the points. -<P> - -Input geographic coordinates -(latitude and longitude) and azimuthal data must be in DMS format and input -distance data must be in units consistent with the ellipsoid -major axis or sphere radius units. -Output geographic coordinates will be in DMS -(if the -<B>-f</B> - -switch is not employed) to 0.001" -with trailing, zero-valued minute-second fields deleted. -Output distance data will be in the same units as the ellipsoid or -sphere radius. -<P> - -The Earth's ellipsoidal figure may be selected in the same -manner as program -<B>proj</B> - -by using -<B>+ellps=, +a=, +es=,</B> - -etc. -<P> - -<I>Geod</I> - -may also be used to determine intermediate points along either -a geodesic line between two points or along an arc of specified distance -from a geographic point. -In both cases an initial point must be specified with -<B>+lat_1=</B><I>lat</I> - -and -<B>+lon_1=</B><I>lon</I> - -parameters and either a terminus point -<B>+lat_2=</B><I>lat</I> - -and -<B>+lon_2=</B><I>lon</I> - -or a distance and azimuth from the initial point with -<B>+S=</B><I>distance</I> - -and -<B>+A=</B><I>azimuth</I> - -must be specified. -<P> - -If points along a geodesic are to be determined then either -<B>+n_S=</B><I>integer</I> - -specifying the number of intermediate points and/or -<B>+del_S=</B><I>distance</I> - -specifying the incremental distance between points must be specified. -<P> - -To determine points along an arc equidistant from the initial point both -<B>+del_A=</B><I>angle</I> - -and -<B>+n_A=</B><I>integer</I> - -must be specified which determine the respective angular increments -and number of points to be determined. - -<A NAME="lbAE"> </A> -<H2>EXAMPLE</H2> - -The following script determines the geodesic azimuths and distance in -U.S. stature miles from Boston, MA, to Portland, OR: -<DL COMPACT><DT><DD> -<BR> <TT>geod +ellps=clrk66 <<EOF -I +units=us-mi -<BR> 42d15'N 71d07'W 45d31'N 123d41'W -<BR> EOF</TT> -</DL> - -which gives the results: -<DL COMPACT><DT><DD> -<BR> <TT>-66d31'50.141" 75d39'13.083" 2587.504 -</DL> - -where the first two values are the -azimuth from Boston to Portland, the back azimuth from Portland to -Boston followed by the distance. -<P> - -An example of forward geodesic use is to use the Boston location and determine -Portland's location by azimuth and distance: -<DL COMPACT><DT><DD> -<BR> geod +ellps=clrk66 <<EOF +units=us-mi -<BR> 42d15'N 71d07'W -66d31'50.141" 2587.504 -<BR> EOF</TT> -</DL> - -which gives: -<DL COMPACT><DT><DD> -<BR> <TT>45d31'0.003"N 123d40'59.985"W 75d39'13.094"</TT> -</DL> - -Note: lack of precision in the distance value compromises -the precision of the Portland location. -<A NAME="lbAF"> </A> -<H2>SEE ALSO</H2> - -Thomas, P.D., 1970, -<I>Spheroidal Geodesics, Reference Systems & Local Geometry:</I> - -U.S. Naval Oceanographic Office, S-138. -<A NAME="lbAG"> </A> -<H2>HOME PAGE</H2> - -<A HREF="http://www.remotesensing.org/proj">http://www.remotesensing.org/proj</A> -<P> - -<HR> -<A NAME="index"> </A><H2>Index</H2> -<DL> -<DT><A HREF="#lbAB">NAME</A><DD> -<DT><A HREF="#lbAC">SYNOPSIS</A><DD> -<DT><A HREF="#lbAD">DESCRIPTION</A><DD> -<DT><A HREF="#lbAE">EXAMPLE</A><DD> -<DT><A HREF="#lbAF">SEE ALSO</A><DD> -<DT><A HREF="#lbAG">HOME PAGE</A><DD> -</DL> -<HR> -This document was created by -<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>, -using the manual pages.<BR> -Time: 13:14:56 GMT, October 14, 2005 -</BODY> -</HTML> diff --git a/html/man_pj_init.html b/html/man_pj_init.html deleted file mode 100644 index 25889942..00000000 --- a/html/man_pj_init.html +++ /dev/null @@ -1,157 +0,0 @@ -<HTML><HEAD><TITLE>Manpage of PJ_INIT</TITLE> -</HEAD><BODY> -<H1>PJ_INIT</H1> -Section: Misc. Reference Manual Pages (3U)<BR>Updated: 2001/04/05 Rel. 4.4<BR><A HREF="#index">Index</A> -<A HREF="../index.html">Return to Main Contents</A><HR> - - - -<A NAME="lbAB"> </A> -<H2>NAME</H2> - -pj_init - initialize cartographic projection -<BR> - -pj_init_plus - initialize cartographic projection -<BR> - -pj_fwd - forward cartographic projection -<BR> - -pj_inv - inverse cartographic projection -<BR> - -pj_transform - transform between coordinate systems -<BR> - -pj_free - de-initialize projection -<A NAME="lbAC"> </A> -<H2>SYNOPSIS</H2> - -<PRE> -#include <<A HREF="file:/usr/include/proj_api.h">proj_api.h</A>> - -projPJ pj_init(int argc, char **argv) - -projPJ pj_init_plus(const char *defn) - -projUV pj_fwd(projUV val, projPJ proj) - -projUV pj_inv(projUV val, projPJ proj) - -int pj_transform(projPJ src_cs, projPJ dst_cs, long point_count, - double *x, double *y, double *z) - -void pj_free(projPJ proj) - -</PRE><A NAME="lbAD"> </A> -<H2>DESCRIPTION</H2> - -Procedure <B>pj_init</B> selects and initializes a cartographic projection -with its argument control parameters. -<B>Argc</B> is the number of elements in the array of control strings -<B>argv</B> that each contain individual cartographic control keyword -assignments (<TT>+</TT> <B>proj</B> arguments). -The list must contain at least the <B>proj=</B><I>projection</I> and -Earth's radius or elliptical parameters. -If the initialization of the projection is successful a valid -address is returned otherwise a NULL value. -<P> -The <B>pj_init_plus</B> function operates similarly to <B>pj_init</B> but -takes a single string containing the definition, with each parameter -prefixed with a plus sign. For example "+proj=utm +zone=11 +ellps=WGS84". -<P> -Once initialization is performed either forward or inverse -projections can be performed with the returned value of <B>pj_init</B> -used as the argument <B>proj</B>. -The argument structure <B>projUV</B> values <B>u</B> and <B>v</B> contain -respective longitude and latitude or x and y. -Latitude and longitude are in radians. -If a projection operation fails, both elements of <B>projUV</B> are -set to HUGE_VAL (defined in <I>math.h</I>). -<P> -<B>Note:</B> all projections have a forward mode, but some do not have -an inverse projection. -If the projection does not have an inverse the projPJ structure element -<I>inv</I> will be NULL. -<P> -The <B>pj_transform</B> function may be used to transform points between -the two provided coordinate systems. In addition to converting between -cartographic projection coordinates and geographic coordinates, this function -also takes care of datum shifts if possible between the source and destination -coordinate system. Unlike <B>pj_fwd</B> and <B>pj_inv</B> it is also allowable -for the coordinate system definitions (<B>PJ *</B>) to be geographic coordinate -systems (defined as +proj=latlong). The <B>x</B>, <B>y</B> and <B>z</B> arrays -contain the input values of the points, and are replaced with the output -values. The function returns zero on success, or the error number (also in -pj_errno) on failure. -<P> -Memory associated with the projection may be freed with <B>pj_free</B>. -<A NAME="lbAE"> </A> -<H2>EXAMPLE</H2> - -The following program reads latitude and longitude values in decimal -degrees, performs Mercator projection with a Clarke 1866 ellipsoid and -a 33° latitude of true scale and prints the projected -cartesian values in meters: -<PRE> -<TT> -#include <<A HREF="file:/usr/include/proj_api.h">proj_api.h</A>> - -main(int argc, char **argv) { - char *args[] = { "proj=merc", "ellps=clrk66", "lat_ts=33" }; - projUV p; - projPJ pj; - - if (!(pj = pj_init(3, args))) - <A HREF="../man1/exit.1.html">exit</A>(1); - while (scanf("%lf %lf", &p.v, &p.u) == 2) { - p.u *= DEG_TO_RAD; - p.v *= DEG_TO_RAD; - p = pj_fwd(p, pj); - printf("%.2f\t%.2f\n", p.u, p.v); - } - exit(0); -} </TT> -<BR> -</PRE> - -<A NAME="lbAF"> </A> -<H2>LIBRARY</H2> - -libproj.a - library of projections and support procedures -<A NAME="lbAG"> </A> -<H2>SEE ALSO</H2> - -<B><A HREF="../man1U/proj.1U.html">proj</A>(1U),</B> - -<BR> - -<I>Cartographic Projection Procedures for the UNIX Environment---A User's Manual,</I> - -(Evenden, 1990, Open-file report 90-284). -<A NAME="lbAH"> </A> -<H2>HOME PAGE</H2> - -<A HREF="http://www.remotesensing.org/proj">http://www.remotesensing.org/proj</A> -<P> -<P> - -<HR> -<A NAME="index"> </A><H2>Index</H2> -<DL> -<DT><A HREF="#lbAB">NAME</A><DD> -<DT><A HREF="#lbAC">SYNOPSIS</A><DD> -<DT><A HREF="#lbAD">DESCRIPTION</A><DD> -<DT><A HREF="#lbAE">EXAMPLE</A><DD> -<DT><A HREF="#lbAF">LIBRARY</A><DD> -<DT><A HREF="#lbAG">SEE ALSO</A><DD> -<DT><A HREF="#lbAH">HOME PAGE</A><DD> -</DL> -<HR> -This document was created by -<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>, -using the manual pages.<BR> -Time: 13:14:22 GMT, October 14, 2005 -</BODY> -</HTML> diff --git a/html/man_proj.html b/html/man_proj.html deleted file mode 100644 index 74980a94..00000000 --- a/html/man_proj.html +++ /dev/null @@ -1,447 +0,0 @@ -Content-type: text/html; charset=UTF-8 - -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<HTML><HEAD><TITLE>Man page of PROJ</TITLE> -</HEAD><BODY> -<H1>PROJ</H1> -Section: User Commands (1)<BR>Updated: 2000/03/21 Rel. 4.4<BR><A HREF="#index">Index</A> -<A HREF="../index.html">Return to Main Contents</A><HR> - -<A NAME="lbAB"> </A> -<H2>NAME</H2> - -proj - forward cartographic projection filter -<BR> - -invproj - inverse cartographic projection filter -<A NAME="lbAC"> </A> -<H2>SYNOPSIS</H2> - -<B>proj</B> - -[ -<B>-bceEfiIlmorsStTvVwW</B> - -[ -<I>args</I> - -] ] [ -<B>+args</B> - -] -file[s] -<BR> - -<B>invproj</B> - -[ -<B>-bceEfiIlmorsStTwW</B> - -[ -<I>args</I> - -] ] [ -<B>+args</B> - -] -file[s] -<A NAME="lbAD"> </A> -<H2>DESCRIPTION</H2> - -<I>Proj</I> - -and -<I>invproj</I> - -perform respective forward and inverse transformation of cartographic data -to or from cartesian data with a wide range of selectable projection functions. -<P> - -The following control parameters can appear in any order: -<DL COMPACT> -<DT><B>-b</B> - -<DD> -Special option for binary coordinate data input and output -through standard input and standard output. -Data is assumed to be in system type -<I>double</I> - -floating point words. -This option is to be used when -<B>proj</B> - -is a -<I>son</I> - -process and allows bypassing formatting operations. -<DT><B>-i</B> - -<DD> -Selects binary input only (see -<B>-b option).</B> - -<DT><B>-I</B> - -<DD> -alternate method to specify inverse projection. -Redundant when used with -<B>invproj.</B> - -<DT><B>-o</B> - -<DD> -Selects binary output only (see -<B>-b option).</B> - -<DT><B>-t</B><I>a</I> - -<DD> -<I>A</I> - -specifies a character employed as the first character to denote -a control line to be passed through without processing. -This option applicable to ascii input only. -(# is the default value). -<DT><B>-e</B><I> string</I> - -<DD> -<I>String</I> - -is an arbitrary string to be output if an error is detected during -data transformations. -The default value is: *\t*. -Note that if the -<B>-b,</B> - -<B>-i</B> - -or -<B>-o</B> - -options are employed, an error is returned as HUGE_VAL -value for both return values. -<DT><B>-E</B> - -<DD> -causes the input coordinates to be copied to the output line -prior to printing the converted values. -<DT><B>-l</B><I>[p|P|=|e|u|d]</I><B>id</B> - -<DD> -List projection identifiers with -<B>-l,</B> - -<B>-lp</B> - -or -<B>-lP (expanded)</B> - -that can be selected with -<B>+proj.</B> - -<B>-l=</B><I>id</I> - -gives expanded description of projection -<I>id.</I> - -List ellipsoid identifiers with -<B>-le,</B> - -that can be selected with -<B>+ellps,</B> - -<B>-lu</B> - -list of cartesian to meter conversion factors -that can be selected with -<B>+units</B> - -or -<B>-ld</B> - -list of datums that can be selected with -<B>+datum.</B> - -<DT><B>-r</B> - -<DD> -This options reverses the order of the -expected input from longitude-latitude or x-y to latitude-longitude or y-x. -<DT><B>-s</B> - -<DD> -This options reverses the order of the -output from x-y or longitude-latitude to y-x or latitude-longitude. -<DT><B>-S</B> - -<DD> -Causes estimation of -<I>meridional</I> - -and -<I>parallel</I> - -scale factors, -<I>area</I> - -scale factor and -<I>angular distortion,</I> - -and -<I>maximum</I> - -and -<I>minimum</I> - -scale factors to be listed between <> for each input point. -For conformal projections meridional and parallel scales factors -will be equal and angular distortion zero. -Equal area projections will have an area factor of 1. -<DT><B>-m</B><I> mult</I> - -<DD> -The cartesian data may be scaled by the -<I>mult</I> - -parameter. -When processing data in a forward projection mode the -cartesian output values are multiplied by -<I>mult</I> - -otherwise the input cartesian values are divided by -<I>mult</I> - -before inverse projection. -If the first two characters of -<I>mult</I> - -are 1/ or 1: then the reciprocal value of -<I>mult</I> - -is employed. -<DT><B>-f</B><I> format</I> - -<DD> -<I>Format</I> - -is a -<I>printf</I> - -format string to control the form of the output values. -For inverse projections, the output will be in degrees when this option -is employed. -The default format is "%.2f" for forward projection and DMS -for inverse. -<DT><B>-[w|W]</B><I>n</I> - -<DD> -<I>N</I> - -is the number of significant fractional digits to employ for -seconds output (when the option is not specified, -<B>-w3</B> - -is assumed). -When -<B>-W</B> - -is employed the fields will be constant width and with leading zeroes. -<DT><B>-v</B> - -<DD> -causes a listing of cartographic control parameters tested for and -used by the program to be printed prior to input data. -Should not be used with the -<B>-T</B> - -option. -<DT><B>-V</B> - -<DD> -This option causes an expanded annotated listing of the characteristics -of the projected point. -<B>-v is implied with this option.</B> - -<DT><B>-T</B><I> ulow,uhi,vlow,vhi,res[,umax,vmax]</I> - -<DD> -This option creates a set of bivariate Chebyshev polynomial -coefficients that approximate the selected cartographic projection on -<I>stdout.</I> - -The values -<I>low</I> - -and -<I>hi</I> - -denote the range of the input where the -<I>u</I> - -or -<I>v</I> - -prefixes apply to respective longitude-x or latitude-y -depending upon whether a forward or inverse projection is selected. -<I>Res</I> - -is an integer number specifying the power of 10 precision of the -approximation. -For example, a -<I>res</I> - -of -3 specifies an approximation with an accuracy better than .001. -<I>Umax,</I> - -and -<I>vmax</I> - -specify maximum degree of the polynomials (default: 15). -See also: -<B><A HREF="../man1/fproj.1.html">fproj</A>(1).</B> - -</DL> -<P> - -The -<B>+args</B> - -run-line arguments are associated with cartographic parameters -and usage varies with projection and for a complete description see -<I>Cartographic Projection Procedures for the UNIX Environment---A User's Manual</I> - -and supplementary documentation for Release 4. -<P> - -Additional projection control parameters may be contained in two -auxiliary control files: -the first is optionally referenced with the -<B>+init=</B><I>file:id</I> - -and the second is always processed after the name -of the projection has been established from either the run-line -or the contents of -<B>+init</B> - -file. -The environment parameter -<B>PROJ_LIB</B> - -establishes the default directory for a file reference without -an absolute path. This is also used for supporting files like -datum shift files. -<P> - -One or more -<I>files</I> - -(processed in left to right order) -specify the source of data to be transformed. -A - will specify the location of processing standard input. -If no files are specified, the input is assumed to be from -<I>stdin.</I> - -For ASCII input data the two data values must be in the -first two white space separated fields and -when both input and output are ASCII all trailing portions -of the input line are appended to the output line. -<P> - -Input geographic data -(longitude and latitude) must be in DMS format and input -cartesian data must be in units consistent with the ellipsoid -major axis or sphere radius units. -Output geographic coordinates will be in DMS -(if the -<B>-w</B> - -switch is not employed) and precise to 0.001" -with trailing, zero-valued minute-second fields deleted. -<A NAME="lbAE"> </A> -<H2>EXAMPLE</H2> - -The following script -<DL COMPACT><DT><DD> -<BR> <TT>proj +proj=utm +lon_0=112w +ellps=clrk66 -r <<EOF -<BR> 45d15'33.1"<TT> </TT>111.5W<BR> -<BR> 45d15.551666667N<TT> </TT>-111d30<BR> -<BR> +45.25919444444<TT> </TT>111d30'000w<BR> -<BR> EOF</TT> -</DL> - -will perform UTM forward projection with a standard UTM -central meridian nearest longitude 112°W. -The geographic values of this example are equivalent and meant -as examples of various forms of DMS input. -The x-y output data will appear as three lines of: -<DL COMPACT><DT><DD> -<BR> <TT>460769.27<TT> </TT>5011648.45<BR> -</DL> - -</TT><A NAME="lbAF"> </A> -<H2>OTHER PROGRAMS</H2> - -<P> - -The <I>proj</I> program is limited to converting between geographic and -projection coordinates within one datum. -<P> - -The <I>cs2cs</I> program operates -similarly, but allows translation between any pair of definable coordinate -systems, including support for datum translation. -<P> - -The <I>geod</I> program provides the ability to compute geodesic (Great -Circle) computations. -<A NAME="lbAG"> </A> -<H2>SEE ALSO</H2> - -<B><A HREF="../man1/cs2cs.1.html">cs2cs</A>(1), <A HREF="../man1/geod.1.html">geod</A>(1), <A HREF="../man3/pj_init.3.html">pj_init</A>(3),</B> - -<BR> - -<I>Cartographic Projection Procedures for the UNIX Environment---A User's Manual,</I> - -(Evenden, 1990, Open-file report 90-284). -<BR> - -<I>Map Projections Used by the U. S. Geological Survey</I> - -(Snyder, 1984, -USGS Bulletin 1532). -<BR> - -<I>Map Projections---A Working Manual</I> - -(Snyder, 1988, USGS Prof. Paper 1395). -<BR> - -<I>An Album of Map Projections</I> - -(Snyder & Voxland, 1989, USGS Prof. Paper 1453). -<A NAME="lbAH"> </A> -<H2>HOME PAGE</H2> - -<A HREF="https://github.com/OSGeo/proj.4/wiki">https://github.com/OSGeo/proj.4/wiki</A> -<P> - -<HR> -<A NAME="index"> </A><H2>Index</H2> -<DL> -<DT><A HREF="#lbAB">NAME</A><DD> -<DT><A HREF="#lbAC">SYNOPSIS</A><DD> -<DT><A HREF="#lbAD">DESCRIPTION</A><DD> -<DT><A HREF="#lbAE">EXAMPLE</A><DD> -<DT><A HREF="#lbAF">OTHER PROGRAMS</A><DD> -<DT><A HREF="#lbAG">SEE ALSO</A><DD> -<DT><A HREF="#lbAH">HOME PAGE</A><DD> -</DL> -<HR> -This document was created by -<A HREF="/cgi-bin/man/man2html">man2html</A>, -using the manual pages.<BR> -Time: 20:44:57 GMT, February 18, 2016 -</BODY> -</HTML> diff --git a/html/proj_logo.png b/html/proj_logo.png Binary files differdeleted file mode 100644 index 92d5acb6..00000000 --- a/html/proj_logo.png +++ /dev/null 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; diff --git a/src/pj_transform.c b/src/pj_transform.c index c72df2e7..06a2dfb0 100644 --- a/src/pj_transform.c +++ b/src/pj_transform.c @@ -27,11 +27,23 @@ * DEALINGS IN THE SOFTWARE. *****************************************************************************/ -#include <projects.h> +#include "projects.h" #include <string.h> #include <math.h> #include "geocent.h" + +/* Apply transformation to observation - in forward or inverse direction */ +/* Copied from proj.h */ +enum PJ_DIRECTION { + PJ_FWD = 1, /* Forward */ + PJ_IDENT = 0, /* Do nothing */ + PJ_INV = -1 /* Inverse */ +}; +typedef enum PJ_DIRECTION PJ_DIRECTION; + + + static int pj_adjust_axis( projCtx ctx, const char *axis, int denormalize_flag, long point_count, int point_offset, double *x, double *y, double *z ); @@ -81,388 +93,470 @@ static const int transient_error[60] = { /* 40 to 49 */ 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, /* 50 to 59 */ 1, 0, 1, 0, 1, 1, 1, 1, 0, 0 }; -/************************************************************************/ -/* pj_transform() */ -/* */ -/* Currently this function doesn't recognise if two projections */ -/* are identical (to short circuit reprojection) because it is */ -/* difficult to compare PJ structures (since there are some */ -/* projection specific components). */ -/************************************************************************/ - -int pj_transform( PJ *srcdefn, PJ *dstdefn, long point_count, int point_offset, - double *x, double *y, double *z ) - -{ - long i; - srcdefn->ctx->last_errno = 0; - dstdefn->ctx->last_errno = 0; - - if( point_offset == 0 ) - point_offset = 1; /* -------------------------------------------------------------------- */ /* Transform unusual input coordinate axis orientation to */ /* standard form if needed. */ /* -------------------------------------------------------------------- */ - if( strcmp(srcdefn->axis,"enu") != 0 ) - { - int err; +static int adjust_axes (PJ *P, PJ_DIRECTION dir, long n, int dist, double *x, double *y, double *z) { + /* Nothing to do? */ + if (0==strcmp(P->axis,"enu")) + return 0; + + return pj_adjust_axis( P->ctx, P->axis, + dir==PJ_FWD ? 1: 0, n, dist, x, y, z ); +} + - err = pj_adjust_axis( srcdefn->ctx, srcdefn->axis, - 0, point_count, point_offset, x, y, z ); - if( err != 0 ) - return err; + +/* ----------------------------------------------------------------------- */ +/* Transform cartesian ("geocentric") source coordinates to lat/long, */ +/* if needed */ +/* ----------------------------------------------------------------------- */ +static int geographic_to_cartesian (PJ *P, PJ_DIRECTION dir, long n, int dist, double *x, double *y, double *z) { + int res; + long i; + double fac = P->to_meter; + + /* Nothing to do? */ + if (!P->is_geocent) + return 0; + + if ( z == NULL ) { + pj_ctx_set_errno( pj_get_ctx(P), PJD_ERR_GEOCENTRIC); + return PJD_ERR_GEOCENTRIC; + } + + if (PJ_FWD==dir) { + fac = P->fr_meter; + res = pj_geodetic_to_geocentric( P->a_orig, P->es_orig, n, dist, x, y, z ); + if (res) + return res; + } + + if (fac != 1.0) { + for( i = 0; i < n; i++ ) { + if( x[dist*i] != HUGE_VAL ) { + x[dist*i] *= fac; + y[dist*i] *= fac; + z[dist*i] *= fac; + } + } } + if (PJ_FWD==dir) + return 0; + return pj_geocentric_to_geodetic( + P->a_orig, P->es_orig, + n, dist, + x, y, z + ); +} + + + + + + + + + + /* -------------------------------------------------------------------- */ -/* Transform geocentric source coordinates to lat/long. */ +/* Transform destination points to projection coordinates, if */ +/* desired. */ +/* */ +/* Ought to fold this into projected_to_geographic */ /* -------------------------------------------------------------------- */ - if( srcdefn->is_geocent ) +static int geographic_to_projected (PJ *P, long n, int dist, double *x, double *y, double *z) { + long i; + + /* Nothing to do? */ + if (P->is_latlong) + return 0; + if (P->is_geocent) + return 0; + + if(P->fwd3d != NULL) { - int err; - if( z == NULL ) + /* Three dimensions must be defined */ + if ( z == NULL) { - pj_ctx_set_errno( pj_get_ctx(srcdefn), PJD_ERR_GEOCENTRIC); + pj_ctx_set_errno( pj_get_ctx(P), PJD_ERR_GEOCENTRIC); return PJD_ERR_GEOCENTRIC; } - if( srcdefn->to_meter != 1.0 ) + for( i = 0; i < n; i++ ) { - for( i = 0; i < point_count; i++ ) + XYZ projected_loc; + LPZ geodetic_loc; + + geodetic_loc.u = x[dist*i]; + geodetic_loc.v = y[dist*i]; + geodetic_loc.w = z[dist*i]; + + if (geodetic_loc.u == HUGE_VAL) + continue; + + projected_loc = pj_fwd3d( geodetic_loc, P); + if( P->ctx->last_errno != 0 ) { - if( x[point_offset*i] != HUGE_VAL ) + if( (P->ctx->last_errno != 33 /*EDOM*/ + && P->ctx->last_errno != 34 /*ERANGE*/ ) + && (P->ctx->last_errno > 0 + || P->ctx->last_errno < -44 || n == 1 + || transient_error[-P->ctx->last_errno] == 0 ) ) + return P->ctx->last_errno; + else { - x[point_offset*i] *= srcdefn->to_meter; - y[point_offset*i] *= srcdefn->to_meter; - z[point_offset*i] *= srcdefn->to_meter; + projected_loc.u = HUGE_VAL; + projected_loc.v = HUGE_VAL; + projected_loc.w = HUGE_VAL; } } - } - err = pj_geocentric_to_geodetic( srcdefn->a_orig, srcdefn->es_orig, - point_count, point_offset, - x, y, z ); - if( err != 0 ) - return err; + x[dist*i] = projected_loc.u; + y[dist*i] = projected_loc.v; + z[dist*i] = projected_loc.w; + } + return 0; } -/* -------------------------------------------------------------------- */ -/* Transform source points to lat/long, if they aren't */ -/* already. */ -/* -------------------------------------------------------------------- */ - else if( !srcdefn->is_latlong ) + for( i = 0; i <n; i++ ) { + XY projected_loc; + LP geodetic_loc; - /* Check first if projection is invertible. */ - if( (srcdefn->inv3d == NULL) && (srcdefn->inv == NULL)) - { - pj_ctx_set_errno( pj_get_ctx(srcdefn), -17 ); - pj_log( pj_get_ctx(srcdefn), PJ_LOG_ERROR, - "pj_transform(): source projection not invertable" ); - return -17; - } + geodetic_loc.u = x[dist*i]; + geodetic_loc.v = y[dist*i]; + + if( geodetic_loc.u == HUGE_VAL ) + continue; - /* If invertible - First try inv3d if defined */ - if (srcdefn->inv3d != NULL) + projected_loc = pj_fwd( geodetic_loc, P ); + if( P->ctx->last_errno != 0 ) { - /* Three dimensions must be defined */ - if ( z == NULL) + if( (P->ctx->last_errno != 33 /*EDOM*/ + && P->ctx->last_errno != 34 /*ERANGE*/ ) + && (P->ctx->last_errno > 0 + || P->ctx->last_errno < -44 || n == 1 + || transient_error[-P->ctx->last_errno] == 0 ) ) + return P->ctx->last_errno; + else { - pj_ctx_set_errno( pj_get_ctx(srcdefn), PJD_ERR_GEOCENTRIC); - return PJD_ERR_GEOCENTRIC; + projected_loc.u = HUGE_VAL; + projected_loc.v = HUGE_VAL; } + } - for (i=0; i < point_count; i++) - { - XYZ projected_loc; - XYZ geodetic_loc; + x[dist*i] = projected_loc.u; + y[dist*i] = projected_loc.v; + } + return 0; +} - projected_loc.u = x[point_offset*i]; - projected_loc.v = y[point_offset*i]; - projected_loc.w = z[point_offset*i]; - if (projected_loc.u == HUGE_VAL) - continue; - geodetic_loc = pj_inv3d(projected_loc, srcdefn); - if( srcdefn->ctx->last_errno != 0 ) - { - if( (srcdefn->ctx->last_errno != 33 /*EDOM*/ - && srcdefn->ctx->last_errno != 34 /*ERANGE*/ ) - && (srcdefn->ctx->last_errno > 0 - || srcdefn->ctx->last_errno < -44 || point_count == 1 - || transient_error[-srcdefn->ctx->last_errno] == 0 ) ) - return srcdefn->ctx->last_errno; - else - { - geodetic_loc.u = HUGE_VAL; - geodetic_loc.v = HUGE_VAL; - geodetic_loc.w = HUGE_VAL; - } - } - x[point_offset*i] = geodetic_loc.u; - y[point_offset*i] = geodetic_loc.v; - z[point_offset*i] = geodetic_loc.w; - } +/* ----------------------------------------------------------------------- */ +/* Transform projected source coordinates to lat/long, if needed */ +/* ----------------------------------------------------------------------- */ +static int projected_to_geographic (PJ *P, long n, int dist, double *x, double *y, double *z) { + long i; + + /* Nothing to do? */ + if (P->is_latlong) + return 0; + + /* Check first if projection is invertible. */ + if( (P->inv3d == NULL) && (P->inv == NULL)) + { + pj_ctx_set_errno( pj_get_ctx(P), -17 ); + pj_log( pj_get_ctx(P), PJ_LOG_ERROR, + "pj_transform(): source projection not invertable" ); + return -17; + } + /* If invertible - First try inv3d if defined */ + if (P->inv3d != NULL) + { + /* Three dimensions must be defined */ + if ( z == NULL) + { + pj_ctx_set_errno( pj_get_ctx(P), PJD_ERR_GEOCENTRIC); + return PJD_ERR_GEOCENTRIC; } - else + + for (i=0; i < n; i++) { - /* Fallback to the original PROJ.4 API 2d inversion - inv */ - for( i = 0; i < point_count; i++ ) - { - XY projected_loc; - LP geodetic_loc; + XYZ projected_loc; + XYZ geodetic_loc; - projected_loc.u = x[point_offset*i]; - projected_loc.v = y[point_offset*i]; + projected_loc.u = x[dist*i]; + projected_loc.v = y[dist*i]; + projected_loc.w = z[dist*i]; - if( projected_loc.u == HUGE_VAL ) - continue; + if (projected_loc.u == HUGE_VAL) + continue; - geodetic_loc = pj_inv( projected_loc, srcdefn ); - if( srcdefn->ctx->last_errno != 0 ) + geodetic_loc = pj_inv3d(projected_loc, P); + if( P->ctx->last_errno != 0 ) + { + if( (P->ctx->last_errno != 33 /*EDOM*/ + && P->ctx->last_errno != 34 /*ERANGE*/ ) + && (P->ctx->last_errno > 0 + || P->ctx->last_errno < -44 || n == 1 + || transient_error[-P->ctx->last_errno] == 0 ) ) + return P->ctx->last_errno; + else { - if( (srcdefn->ctx->last_errno != 33 /*EDOM*/ - && srcdefn->ctx->last_errno != 34 /*ERANGE*/ ) - && (srcdefn->ctx->last_errno > 0 - || srcdefn->ctx->last_errno < -44 || point_count == 1 - || transient_error[-srcdefn->ctx->last_errno] == 0 ) ) - return srcdefn->ctx->last_errno; - else - { - geodetic_loc.u = HUGE_VAL; - geodetic_loc.v = HUGE_VAL; - } + geodetic_loc.u = HUGE_VAL; + geodetic_loc.v = HUGE_VAL; + geodetic_loc.w = HUGE_VAL; } - - x[point_offset*i] = geodetic_loc.u; - y[point_offset*i] = geodetic_loc.v; } + + x[dist*i] = geodetic_loc.u; + y[dist*i] = geodetic_loc.v; + z[dist*i] = geodetic_loc.w; + } + return 0; } -/* -------------------------------------------------------------------- */ -/* But if they are already lat long, adjust for the prime */ -/* meridian if there is one in effect. */ -/* -------------------------------------------------------------------- */ - if ((srcdefn->is_geocent || srcdefn->is_latlong) && ( srcdefn->from_greenwich != 0.0 )) - { - for( i = 0; i < point_count; i++ ) + /* Fallback to the original PROJ.4 API 2d inversion - inv */ + for( i = 0; i < n; i++ ) { + XY projected_loc; + LP geodetic_loc; + + projected_loc.u = x[dist*i]; + projected_loc.v = y[dist*i]; + + if( projected_loc.u == HUGE_VAL ) + continue; + + geodetic_loc = pj_inv( projected_loc, P ); + if( P->ctx->last_errno != 0 ) { - if( x[point_offset*i] != HUGE_VAL ) - x[point_offset*i] += srcdefn->from_greenwich; + if( (P->ctx->last_errno != 33 /*EDOM*/ + && P->ctx->last_errno != 34 /*ERANGE*/ ) + && (P->ctx->last_errno > 0 + || P->ctx->last_errno < -44 || n == 1 + || transient_error[-P->ctx->last_errno] == 0 ) ) + return P->ctx->last_errno; + else + { + geodetic_loc.u = HUGE_VAL; + geodetic_loc.v = HUGE_VAL; + } } - } -/* -------------------------------------------------------------------- */ -/* Do we need to translate from geoid to ellipsoidal vertical */ -/* datum? */ -/* -------------------------------------------------------------------- */ - if( srcdefn->has_geoid_vgrids && z != NULL ) - { - if( pj_apply_vgridshift( srcdefn, "sgeoidgrids", - &(srcdefn->vgridlist_geoid), - &(srcdefn->vgridlist_geoid_count), - 0, point_count, point_offset, x, y, z ) != 0 ) - return pj_ctx_get_errno(srcdefn->ctx); + x[dist*i] = geodetic_loc.u; + y[dist*i] = geodetic_loc.v; } + return 0; +} -/* -------------------------------------------------------------------- */ -/* Convert datums if needed, and possible. */ -/* -------------------------------------------------------------------- */ - if( pj_datum_transform( srcdefn, dstdefn, point_count, point_offset, - x, y, z ) != 0 ) - { - if( srcdefn->ctx->last_errno != 0 ) - return srcdefn->ctx->last_errno; - else - return dstdefn->ctx->last_errno; - } -/* -------------------------------------------------------------------- */ -/* Do we need to translate from ellipsoidal to geoid vertical */ -/* datum? */ -/* -------------------------------------------------------------------- */ - if( dstdefn->has_geoid_vgrids && z != NULL ) - { - if( pj_apply_vgridshift( dstdefn, "sgeoidgrids", - &(dstdefn->vgridlist_geoid), - &(dstdefn->vgridlist_geoid_count), - 1, point_count, point_offset, x, y, z ) != 0 ) - return dstdefn->ctx->last_errno; - } /* -------------------------------------------------------------------- */ -/* But if they are staying lat long, adjust for the prime */ -/* meridian if there is one in effect. */ +/* Adjust for the prime meridian if needed. */ /* -------------------------------------------------------------------- */ - if ((dstdefn->is_geocent || dstdefn->is_latlong) && ( dstdefn->from_greenwich != 0.0 )) - { - for( i = 0; i < point_count; i++ ) - { - if( x[point_offset*i] != HUGE_VAL ) - x[point_offset*i] -= dstdefn->from_greenwich; - } +static int prime_meridian (PJ *P, PJ_DIRECTION dir, long n, int dist, double *x) { + int i; + double pm = P->from_greenwich; + + /* Nothing to do? */ + if (pm==0.0) + return 0; + if (!(P->is_geocent || P->is_latlong)) + return 0; + + if (dir==PJ_FWD) + pm = -pm; + + for (i = 0; i < n; i++) + if (x[dist*i] != HUGE_VAL) + x[dist*i] += pm; + + return 0; } + + /* -------------------------------------------------------------------- */ -/* Transform destination latlong to geocentric if required. */ +/* Adjust for vertical scale factor if needed */ /* -------------------------------------------------------------------- */ - if( dstdefn->is_geocent ) - { - if( z == NULL ) - { - pj_ctx_set_errno( dstdefn->ctx, PJD_ERR_GEOCENTRIC ); - return PJD_ERR_GEOCENTRIC; - } +static int height_unit (PJ *P, PJ_DIRECTION dir, long n, int dist, double *z) { + int i; + double fac = P->vto_meter; - pj_geodetic_to_geocentric( dstdefn->a_orig, dstdefn->es_orig, - point_count, point_offset, x, y, z ); + if (PJ_FWD==dir) + fac = P->vfr_meter; - if( dstdefn->fr_meter != 1.0 ) - { - for( i = 0; i < point_count; i++ ) - { - if( x[point_offset*i] != HUGE_VAL ) - { - x[point_offset*i] *= dstdefn->fr_meter; - y[point_offset*i] *= dstdefn->fr_meter; - z[point_offset*i] *= srcdefn->fr_meter; - } - } - } - } + /* Nothing to do? */ + if (fac==1.0) + return 0; + if (0==z) + return 0; -/* -------------------------------------------------------------------- */ -/* Transform destination points to projection coordinates, if */ -/* desired. */ -/* -------------------------------------------------------------------- */ - else if( !dstdefn->is_latlong ) - { + for (i = 0; i < n; i++) + if (z[dist*i] != HUGE_VAL ) + z[dist*i] *= fac; - if( dstdefn->fwd3d != NULL) - { - /* Three dimensions must be defined */ - if ( z == NULL) - { - pj_ctx_set_errno( pj_get_ctx(dstdefn), PJD_ERR_GEOCENTRIC); - return PJD_ERR_GEOCENTRIC; - } + return 0; +} - for( i = 0; i < point_count; i++ ) - { - XYZ projected_loc; - LPZ geodetic_loc; - geodetic_loc.u = x[point_offset*i]; - geodetic_loc.v = y[point_offset*i]; - geodetic_loc.w = z[point_offset*i]; - if (geodetic_loc.u == HUGE_VAL) - continue; +/* -------------------------------------------------------------------- */ +/* Transform to ellipsoidal heights if needed */ +/* -------------------------------------------------------------------- */ +static int geometric_to_orthometric (PJ *P, PJ_DIRECTION dir, long n, int dist, double *x, double *y, double *z) { + int err; + if (0==P->has_geoid_vgrids) + return 0; + if (z==0) + return PJD_ERR_GEOCENTRIC; + err = pj_apply_vgridshift (P, "sgeoidgrids", + &(P->vgridlist_geoid), + &(P->vgridlist_geoid_count), + dir==PJ_FWD ? 1 : 0, n, dist, x, y, z ); + if (err) + return pj_ctx_get_errno(P->ctx); + return 0; +} - projected_loc = pj_fwd3d( geodetic_loc, dstdefn); - if( dstdefn->ctx->last_errno != 0 ) - { - if( (dstdefn->ctx->last_errno != 33 /*EDOM*/ - && dstdefn->ctx->last_errno != 34 /*ERANGE*/ ) - && (dstdefn->ctx->last_errno > 0 - || dstdefn->ctx->last_errno < -44 || point_count == 1 - || transient_error[-dstdefn->ctx->last_errno] == 0 ) ) - return dstdefn->ctx->last_errno; - else - { - projected_loc.u = HUGE_VAL; - projected_loc.v = HUGE_VAL; - projected_loc.w = HUGE_VAL; - } - } - x[point_offset*i] = projected_loc.u; - y[point_offset*i] = projected_loc.v; - z[point_offset*i] = projected_loc.w; - } - } - else - { - for( i = 0; i < point_count; i++ ) - { - XY projected_loc; - LP geodetic_loc; +/* -------------------------------------------------------------------- */ +/* Convert datums if needed, and possible. */ +/* -------------------------------------------------------------------- */ +static int datum_transform (PJ *P, PJ *Q, long n, int dist, double *x, double *y, double *z) { + if (0==pj_datum_transform (P, Q, n, dist, x, y, z)) + return 0; + if (P->ctx->last_errno) + return P->ctx->last_errno; + return Q->ctx->last_errno; +} - geodetic_loc.u = x[point_offset*i]; - geodetic_loc.v = y[point_offset*i]; - if( geodetic_loc.u == HUGE_VAL ) - continue; - projected_loc = pj_fwd( geodetic_loc, dstdefn ); - if( dstdefn->ctx->last_errno != 0 ) - { - if( (dstdefn->ctx->last_errno != 33 /*EDOM*/ - && dstdefn->ctx->last_errno != 34 /*ERANGE*/ ) - && (dstdefn->ctx->last_errno > 0 - || dstdefn->ctx->last_errno < -44 || point_count == 1 - || transient_error[-dstdefn->ctx->last_errno] == 0 ) ) - return dstdefn->ctx->last_errno; - else - { - projected_loc.u = HUGE_VAL; - projected_loc.v = HUGE_VAL; - } - } - x[point_offset*i] = projected_loc.u; - y[point_offset*i] = projected_loc.v; - } - } - } /* -------------------------------------------------------------------- */ /* If a wrapping center other than 0 is provided, rewrap around */ /* the suggested center (for latlong coordinate systems only). */ /* -------------------------------------------------------------------- */ - else if( dstdefn->is_latlong && dstdefn->is_long_wrap_set ) - { - for( i = 0; i < point_count; i++ ) - { - double val = x[point_offset*i]; - if( val == HUGE_VAL ) - continue; +static int long_wrap (PJ *P, long n, int dist, double *x) { + long i; - /* Get fast in ] -2 PI, 2 PI [ range */ - val = fmod(val, M_TWOPI); - while( val < dstdefn->long_wrap_center - M_PI ) - val += M_TWOPI; - while( val > dstdefn->long_wrap_center + M_PI ) - val -= M_TWOPI; - x[point_offset*i] = val; - } - } + /* Nothing to do? */ + if (P->is_geocent) + return 0; + if (!P->is_long_wrap_set) + return 0; + if (!P->is_latlong) + return 0; -/* -------------------------------------------------------------------- */ -/* Transform normalized axes into unusual output coordinate axis */ -/* orientation if needed. */ -/* -------------------------------------------------------------------- */ - if( strcmp(dstdefn->axis,"enu") != 0 ) - { - int err; + for (i = 0; i < n; i++ ) { + double val = x[dist*i]; + if (val == HUGE_VAL) + continue; - err = pj_adjust_axis( dstdefn->ctx, dstdefn->axis, - 1, point_count, point_offset, x, y, z ); - if( err != 0 ) - return err; + /* Get fast in ] -2 PI, 2 PI [ range */ + val = fmod(val, M_TWOPI); + while( val < P->long_wrap_center - M_PI ) + val += M_TWOPI; + while( val > P->long_wrap_center + M_PI ) + val -= M_TWOPI; + x[dist*i] = val; } + return 0; +} + + + +/************************************************************************/ +/* pj_transform() */ +/* */ +/* Currently this function doesn't recognise if two projections */ +/* are identical (to short circuit reprojection) because it is */ +/* difficult to compare PJ structures (since there are some */ +/* projection specific components). */ +/************************************************************************/ + +int pj_transform( + PJ *srcdefn, PJ *dstdefn, + long point_count, int point_offset, + double *x, double *y, double *z +){ + int err; + + srcdefn->ctx->last_errno = 0; + dstdefn->ctx->last_errno = 0; + + if( point_offset == 0 ) + point_offset = 1; + + /* Bring input to "normal form": longitude, latitude, ellipsoidal height */ + + err = adjust_axes (srcdefn, PJ_INV, point_count, point_offset, x, y, z); + if (err) + return err; + err = geographic_to_cartesian (srcdefn, PJ_INV, point_count, point_offset, x, y, z); + if (err) + return err; + err = projected_to_geographic (srcdefn, point_count, point_offset, x, y, z); + if (err) + return err; + err = prime_meridian (srcdefn, PJ_INV, point_count, point_offset, x); + if (err) + return err; + err = height_unit (srcdefn, PJ_INV, point_count, point_offset, z); + if (err) + return err; + err = geometric_to_orthometric (srcdefn, PJ_INV, point_count, point_offset, x, y, z); + if (err) + return err; + + /* At the center of the process we do the datum shift (if needed) */ + + err = datum_transform(srcdefn, dstdefn, point_count, point_offset, x, y, z ); + if (err) + return err; + + /* Now get out on the other side: Bring "normal form" to output form */ + + err = geometric_to_orthometric (dstdefn, PJ_FWD, point_count, point_offset, x, y, z); + if (err) + return err; + err = height_unit (dstdefn, PJ_FWD, point_count, point_offset, z); + if (err) + return err; + err = prime_meridian (dstdefn, PJ_FWD, point_count, point_offset, x); + if (err) + return err; + err = geographic_to_cartesian (dstdefn, PJ_FWD, point_count, point_offset, x, y, z); + if (err) + return err; + err = geographic_to_projected (dstdefn, point_count, point_offset, x, y, z); + if (err) + return err; + err = long_wrap (dstdefn, point_count, point_offset, x); + if (err) + return err; + err = adjust_axes (dstdefn, PJ_FWD, point_count, point_offset, x, y, z); + if (err) + return err; return 0; } + + /************************************************************************/ /* pj_geodetic_to_geocentric() */ /************************************************************************/ @@ -324,7 +324,7 @@ size_t proj_trans_generic ( PJ_COORD proj_coord (double x, double y, double z, double t); /* Measure internal consistency - in forward or inverse direction */ -double proj_roundtrip (PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coo); +double proj_roundtrip (PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coord); /* Geodesic distance between two points with angular 2D coordinates */ double proj_lp_dist (const PJ *P, PJ_COORD a, PJ_COORD b); @@ -374,7 +374,7 @@ double proj_torad (double angle_in_degrees); double proj_todeg (double angle_in_radians); /* Geographical to geocentric latitude - another of the "simple, but useful" */ -PJ_COORD proj_geocentric_latitude (const PJ *P, PJ_DIRECTION direction, PJ_COORD coo); +PJ_COORD proj_geocentric_latitude (const PJ *P, PJ_DIRECTION direction, PJ_COORD coord); double proj_dmstor(const char *is, char **rs); char* proj_rtodms(char *s, double r, int pos, int neg); diff --git a/src/proj_4D_api.c b/src/proj_4D_api.c index fb20978b..f0ea7083 100644 --- a/src/proj_4D_api.c +++ b/src/proj_4D_api.c @@ -113,7 +113,7 @@ double proj_xyz_dist (PJ_COORD a, PJ_COORD b) { /* Measure numerical deviation after n roundtrips fwd-inv (or inv-fwd) */ -double proj_roundtrip (PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coo) { +double proj_roundtrip (PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coord) { int i; PJ_COORD t, org; @@ -126,9 +126,9 @@ double proj_roundtrip (PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coo) { } /* in the first half-step, we generate the output value */ - org = *coo; - *coo = proj_trans (P, direction, org); - t = *coo; + org = *coord; + *coord = proj_trans (P, direction, org); + t = *coord; /* now we take n-1 full steps in inverse direction: We are */ /* out of phase due to the half step already taken */ @@ -148,26 +148,26 @@ double proj_roundtrip (PJ *P, PJ_DIRECTION direction, int n, PJ_COORD *coo) { /**************************************************************************************/ -PJ_COORD proj_trans (PJ *P, PJ_DIRECTION direction, PJ_COORD coo) { +PJ_COORD proj_trans (PJ *P, PJ_DIRECTION direction, PJ_COORD coord) { /*************************************************************************************** -Apply the transformation P to the coordinate coo, preferring the 4D interfaces if +Apply the transformation P to the coordinate coord, preferring the 4D interfaces if available. See also pj_approx_2D_trans and pj_approx_3D_trans in pj_internal.c, which work similarly, but prefers the 2D resp. 3D interfaces if available. ***************************************************************************************/ if (0==P) - return coo; + return coord; if (P->inverted) direction = -direction; switch (direction) { case PJ_FWD: - return pj_fwd4d (coo, P); + return pj_fwd4d (coord, P); case PJ_INV: - return pj_inv4d (coo, P); + return pj_inv4d (coord, P); case PJ_IDENT: - return coo; + return coord; default: break; } @@ -357,7 +357,7 @@ size_t proj_trans_generic ( /*************************************************************************************/ -PJ_COORD proj_geocentric_latitude (const PJ *P, PJ_DIRECTION direction, PJ_COORD coo) { +PJ_COORD proj_geocentric_latitude (const PJ *P, PJ_DIRECTION direction, PJ_COORD coord) { /************************************************************************************** Convert geographical latitude to geocentric (or the other way round if direction = PJ_INV) @@ -373,13 +373,13 @@ PJ_COORD proj_geocentric_latitude (const PJ *P, PJ_DIRECTION direction, PJ_COORD consequently, the input is copied directly to the output. **************************************************************************************/ const double limit = M_HALFPI - 1e-9; - PJ_COORD res = coo; - if ((coo.lp.phi > limit) || (coo.lp.phi < -limit) || (P->es==0)) + PJ_COORD res = coord; + if ((coord.lp.phi > limit) || (coord.lp.phi < -limit) || (P->es==0)) return res; if (direction==PJ_FWD) - res.lp.phi = atan (P->one_es * tan (coo.lp.phi) ); + res.lp.phi = atan (P->one_es * tan (coord.lp.phi) ); else - res.lp.phi = atan (P->rone_es * tan (coo.lp.phi) ); + res.lp.phi = atan (P->rone_es * tan (coord.lp.phi) ); return res; } diff --git a/src/proj_internal.h b/src/proj_internal.h index 071510c7..e72ce578 100644 --- a/src/proj_internal.h +++ b/src/proj_internal.h @@ -33,7 +33,7 @@ #endif #include <math.h> /* For M_PI */ -#include <proj.h> +#include "proj.h" #ifdef PROJECTS_H #error proj_internal.h must be included before projects.h @@ -73,8 +73,6 @@ enum pj_io_units { enum pj_io_units pj_left (PJ *P); enum pj_io_units pj_right (PJ *P); -PJ_COORD proj_trans (PJ *P, PJ_DIRECTION direction, PJ_COORD obs); - PJ_COORD proj_coord_error (void); void proj_context_errno_set (PJ_CONTEXT *ctx, int err); |
