diff options
| author | Mike Taves <mwtoews@gmail.com> | 2021-05-06 10:37:06 +1200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-05-06 10:37:06 +1200 |
| commit | 22654ce7c0acaab875c9427592a42093ac75e8cd (patch) | |
| tree | 229597a5a184b02ba831b5e923574a008de06782 | |
| parent | 45a88fe245ae040b6f19696dfd928fb2f03f51d9 (diff) | |
| download | PROJ-22654ce7c0acaab875c9427592a42093ac75e8cd.tar.gz PROJ-22654ce7c0acaab875c9427592a42093ac75e8cd.zip | |
DOC: configure and add spelling wordlist; fix typos, apply Sphinx syntax (#2707)
56 files changed, 712 insertions, 250 deletions
@@ -601,7 +601,7 @@ 2010-03-16 Frank Warmerdam <warmerdam@pobox.com> * src/pj_transform.c, src/pj_init.c, src/projects.h, src/pj_gridlist.c, - src/pj_apply_gridshit.c: rework the translation of nadgrids parameters + src/pj_apply_gridshift.c: rework the translation of nadgrids parameters into a list of gridshift files to avoid use of static "lastnadgrids" information which screws up multithreading. Changes the PJ structure. @@ -131,7 +131,7 @@ tweaks in the underlying API. Bug fixes --------- - o Do not restrict longitude to [-90;90] range in spherical transver Mercator + o Do not restrict longitude to [-90;90] range in spherical transverse Mercator forward projection (#2471) o createOperations(): fix Compound to Geog3D/Projected3D CRS with non-metre ellipsoidal height (#2500) @@ -407,7 +407,7 @@ tweaks in the underlying API. o Update to EPSG 9.8.12, ESRI 10.8.1 and import scope and remarks for conversion (#2238) (#2267) - o Map the Behrman projection to cae when converting ESRI CRSes (#1986) + o Map the Behrmann projection to cae when converting ESRI CRSes (#1986) o Support conversion of Flat_Polar_Quartic projection method (#1987) diff --git a/docs/source/apps/cct.rst b/docs/source/apps/cct.rst index b49a0e72..700261fa 100644 --- a/docs/source/apps/cct.rst +++ b/docs/source/apps/cct.rst @@ -25,7 +25,7 @@ by :c:func:`proj_create`, provided it expresses a coordinate operation - a proj-string, - a WKT string, - an object code (like "EPSG:1671" "urn:ogc:def:coordinateOperation:EPSG::1671"), - - an object name. e.g "ITRF2014 to ETRF2014 (1)". In that case as + - an object name. e.g. "ITRF2014 to ETRF2014 (1)". In that case as uniqueness is not guaranteed, heuristics are applied to determine the appropriate best match. - a OGC URN combining references for concatenated operations (e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618") diff --git a/docs/source/apps/projinfo.rst b/docs/source/apps/projinfo.rst index 15fa4dd2..230c7abb 100644 --- a/docs/source/apps/projinfo.rst +++ b/docs/source/apps/projinfo.rst @@ -134,7 +134,7 @@ The following control parameters can appear in any order: Specify how the area of use of coordinate operations found in the database are compared to the area of use specified explicitly with :option:`--area` or :option:`--bbox`, or derived implicitly from the area of use of the source and target CRS. - By default, projinfo will only keep coordinate operations whose are of use + By default, :program:`projinfo` will only keep coordinate operations whose are of use is strictly within the area of interest (``contains`` strategy). If using the ``intersects`` strategy, the spatial test is relaxed, and any coordinate operation whose area of use at least partly intersects the @@ -184,7 +184,7 @@ The following control parameters can appear in any order: Determine if intermediate (pivot) CRS can be used when researching coordinate operation between 2 CRS. A typical example is the WGS84 pivot. By default, - projinfo will consider any potential pivot if there is no direct transformation + :program:`projinfo` will consider any potential pivot if there is no direct transformation ( ``if_no_direct_transformation``). If using the ``never`` strategy, only direct transformations between the source and target CRS will be used. If using the ``always`` strategy, intermediate CRS will be considered @@ -239,8 +239,8 @@ The following control parameters can appear in any order: .. option:: --main-db-path path - Specify the name and path of the database to be used by projinfo. The - default is proj.db in the PROJ resource directories. + Specify the name and path of the database to be used by :program:`projinfo`. + The default is :file:`proj.db` in the PROJ resource directories. .. option:: --aux-db-path path diff --git a/docs/source/apps/projsync.rst b/docs/source/apps/projsync.rst index db3ff16d..247bd2e8 100644 --- a/docs/source/apps/projsync.rst +++ b/docs/source/apps/projsync.rst @@ -39,13 +39,13 @@ The following control parameters can appear in any order: .. option:: --endpoint URL - Defines the URL where to download the master ``files.geojson`` file and then + Defines the URL where to download the master :file:`files.geojson` file and then the resource files. Defaults to the value set in :ref:`proj-ini` .. option:: --local-geojson-file FILENAME Defines the filename for the master GeoJSON files that references resources. - Defaults to ${endpoint}/files.geojson + Defaults to ``${endpoint}/files.geojson`` .. option:: --user-writable-directory diff --git a/docs/source/community/code_contributions.rst b/docs/source/community/code_contributions.rst index 7f8c88fa..5acaad87 100644 --- a/docs/source/community/code_contributions.rst +++ b/docs/source/community/code_contributions.rst @@ -139,7 +139,7 @@ Build under scan-build: If CSA finds errors, they will be emitted during the build. And in which case, at the end of the build process, scan-build will emit a warning message indicating errors have been found and how to display the error report. This -is with someling like +is with something like :: diff --git a/docs/source/community/rfc/rfc-2.rst b/docs/source/community/rfc/rfc-2.rst index 4cea339d..7da1bc4f 100644 --- a/docs/source/community/rfc/rfc-2.rst +++ b/docs/source/community/rfc/rfc-2.rst @@ -157,7 +157,7 @@ all classes, except the CoordinateOperation class that point to CRS for sourceCRS and targetCRS members, whereas DerivedCRS point to a Conversion instance (which derives from CoordinateOperation). This issue was detected in the ISO-19111 standard. The solution adopted here is to use std::weak_ptr -in the CoordinateOperation class to avoid the cycle. This design artifact is +in the CoordinateOperation class to avoid the cycle. This design artefact is transparent to users. Another important design point is that all ISO19111 objects are immutable after @@ -215,12 +215,12 @@ On the algorithmic side, a somewhat involved logic is the CoordinateOperationFactory::createOperations() in `coordinateoperation.cpp`_ that takes a pair of source and target CRS and returns a set of possible `coordinate operations`_ (either single operations like a Conversion or a -Transformation, or concatenated operations). It uses the intrinsinc structure +Transformation, or concatenated operations). It uses the intrinsic structure of those objects to create the coordinate operation pipeline. That is, if going from a ProjectedCRS to another one, by doing first the inverse conversion from the source ProjectedCRS to its base GeographicCRS, then finding the appropriate transformation(s) from this base GeographicCRS to the base -GeographicCRS of the target CRS, and then appyling the conversion from this +GeographicCRS of the target CRS, and then applying the conversion from this base GeographicCRS to the target ProjectedCRS. At each step, it queries the database to find if one or several transformations are available. The resulting coordinate operations are filtered, and sorted, with user provided hints: @@ -238,7 +238,7 @@ resulting coordinate operations are filtered, and sorted, with user provided hin compared. By default, only transformations whose area of use is fully contained in the desired area of use are selected. It is also possible to relax this test by specifying that only an intersection test must be used. - - whether `PROJ transformation grid`_ names should be susbstituted to the + - whether `PROJ transformation grid`_ names should be substituted to the official names, when a match is found in the `grid_alternatives` table of the database. Defaults to true - whether the availability of those grids should be used to filter and sort @@ -636,7 +636,7 @@ Impacted files -------------- New files (excluding makefile.am, CMakeLists.txt and other build infrastructure -artifacts): +artefacts): * include/proj/: Public installed C++ headers - `common.hpp`_: declarations of osgeo::proj::common namespace. @@ -853,7 +853,7 @@ Doxygen. .. _`Spaghetti inheritance diagram`: http://even.rouault.free.fr/proj_cpp_api/html/inherits.html A basic integration of the Doxygen XML output into the general PROJ -documentation (using reStructuredText format) has been done with the the +documentation (using reStructuredText format) has been done with the Sphinx extension `Breathe`_, producing: * `One section with the C++ API`_ diff --git a/docs/source/community/rfc/rfc-3.rst b/docs/source/community/rfc/rfc-3.rst index ae4bff95..439f22d1 100644 --- a/docs/source/community/rfc/rfc-3.rst +++ b/docs/source/community/rfc/rfc-3.rst @@ -50,7 +50,7 @@ Background PROJ has traditionally been written in C89. Until recently, no formal requirements of e.g. build systems has been defined and formally accepted by -the project. :ref:RFC2 <rfc2>` formally introduces dependencies on C++11 and +the project. :ref:`RFC2 <rfc2>` formally introduces dependencies on C++11 and SQLite 3.7. In this RFC a rolling update of version or standard requirements is described. @@ -94,7 +94,7 @@ PROJ uses C89 and C++11. For C, that means that the used standard is three iterations behind the most recent standard. C++ is two iterations behind. Following the rules in this RFC the required C standard used in PROJ is at allowed to be two iterations behind the most recent standard. That means that a -change to C99 is possible, as long as the PROJ PSC aknowledges such a change. +change to C99 is possible, as long as the PROJ PSC acknowledges such a change. When a new standard for either C or C++ is released PROJ should consider changing its requirement to the next standard in the line. For C++ that means a diff --git a/docs/source/community/rfc/rfc-4.rst b/docs/source/community/rfc/rfc-4.rst index 738dd4bb..9673c898 100644 --- a/docs/source/community/rfc/rfc-4.rst +++ b/docs/source/community/rfc/rfc-4.rst @@ -89,7 +89,7 @@ can build with rather ancient libcurl for similar functionality, we can aim for libcurl >= 7.29.0 (as being available in RHEL 7). An alternate pluggable network interface can also be set by the user in case -suppot for libcurl was not built in, or if for the desired context of use, the +support for libcurl was not built in, or if for the desired context of use, the user wishes to provide the network implementation (a typical use case could be QGIS that would use its QT-based networking facilities to solve issues with SSL, proxy, authentication, etc.) @@ -223,7 +223,7 @@ to limit the number of HTTP GET requests and minimize latency caused by network access. This is very similar to the behavior of the GDAL `/vsicurl/ <https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access>`_ I/O layer. The plan is to mostly copy GDAL's vsicurl implementation inside PROJ, with -needed adjustmeents and proper namespacing of it. +needed adjustments and proper namespacing of it. A retry strategy (typically a delay with an exponential back-off and some random jitter) will be added to account for intermittent network or server-side failure. @@ -403,7 +403,7 @@ and ${LOCALAPPDATA} on Windows builds. Exact details to be sorted out, but https://github.com/ActiveState/appdirs/blob/a54ea98feed0a7593475b94de3a359e9e1fe8fdb/appdirs.py#L45-L97 can be a good reference. -As this database might be accesse by several threads or processes at the same +As this database might be accessed by several threads or processes at the same time, the code accessing to it will carefully honour SQLite3 errors regarding to locks, to do appropriate retries if another thread/process is currently locking the database. Accesses requiring a modification of the database will @@ -602,7 +602,7 @@ Weak points: * Multi-samples variables are located in different sections of the files (correspond to TIFF PlanarConfiguration = Separate) -* No natural way of having hiearchical / multigrids. They must be encoded as +* No natural way of having hierarchical / multigrids. They must be encoded as separate variables * georeferencing in netCDF is somewhat less standardized than TIFF/GeoTIFF. @@ -704,7 +704,7 @@ document. Tooling +++++++ -A script will be deveoped to accept a list of individual grids to combine +A script will be developed to accept a list of individual grids to combine together into a single file. A ntv2_to_gtiff.py convenience script will be created to convert NTv2 grids, diff --git a/docs/source/community/rfc/rfc-5.rst b/docs/source/community/rfc/rfc-5.rst index 6e9bf5b7..44811d58 100644 --- a/docs/source/community/rfc/rfc-5.rst +++ b/docs/source/community/rfc/rfc-5.rst @@ -22,7 +22,7 @@ as https://github.com/OSGeo/proj-datumgrid converted in GeoTIFF files. In the current state, we could have a somewhat inconsistency between users relying on the proj-datumgrid, proj-datumgrid-[world,northamerica,oceania,europe] packages of mostly NTv2 and GTX files, and what is shipped through the CDN. Maintaining -two repositories is also a maintaince burden in the long term. +two repositories is also a maintenance burden in the long term. It is thus desirable to have a single source of truth, and we propose it to be based on the GeoTIFF grids. @@ -44,14 +44,14 @@ Summary of work planned by this RFC and related decisions - Each file will be named according to the following pattern ``${agency_name}_${filename}[.ext]``. For example fr_ign_ntf_r93.tif This convention should allow packagers, if the need arise, to be able to - split the monolothic package in smaller ones, based on criterion related to + split the monolithic package in smaller ones, based on criterion related to the country. The agency name is the one you can see from the directory names at https://github.com/OSGeo/PROJ-data/. ``${agency_name}`` itself is structure like ``${two_letter_country_code_of_agency_nationality}_${some_abbreviation}`` (with the exception of eur_nkg, for the Nordic Geodetic Commission which - isn't affiliated to a single country but to some european countries, and + isn't affiliated to a single country but to some European countries, and follows the general scheme) - https://github.com/OSGeo/proj-datumgrid and related packages will only be diff --git a/docs/source/conf.py b/docs/source/conf.py index 9a176217..8c81487f 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -46,6 +46,11 @@ templates_path = ['_templates'] # BibTeX configuration bibtex_bibfiles = ['references.bib'] +# Spelling configuration +spelling_lang = tokenizer_lang = 'en_GB' +spelling_show_suggestions = False +spelling_ignore_importable_modules = False + # The suffix(es) of source filenames. # You can specify multiple suffix as a list of string: # source_suffix = ['.rst', '.md'] diff --git a/docs/source/development/index.rst b/docs/source/development/index.rst index f985279f..2d544189 100644 --- a/docs/source/development/index.rst +++ b/docs/source/development/index.rst @@ -27,7 +27,7 @@ are maintained in a `separate git repository <https://github.com/OSGeo/proj-datu .. attention:: - The ``projects.h`` header and the functions related to it is considered + The :file:`projects.h` header and the functions related to it is considered deprecated from version 5.0.0 and onwards. The header has been removed PROJ in version 6.0.0 released February 1st 2019. @@ -38,7 +38,7 @@ are maintained in a `separate git repository <https://github.com/OSGeo/proj-datu .. attention:: - The ``proj_api.h`` header and the functions related to it is + The :file:`proj_api.h` header and the functions related to it is considered deprecated from version 5.0.0 and onwards. The header has been removed in version 8.0.0 released March 1st 2021. diff --git a/docs/source/development/migration.rst b/docs/source/development/migration.rst index 29c56b4b..4c0113e5 100644 --- a/docs/source/development/migration.rst +++ b/docs/source/development/migration.rst @@ -109,58 +109,58 @@ Function mapping from old to new API +---------------------------------------+-------------------------------------------------+ | Old API functions | New API functions | +=======================================+=================================================+ -| pj_fwd | :c:func:`proj_trans` | +| ``pj_fwd`` | :c:func:`proj_trans` | +---------------------------------------+-------------------------------------------------+ -| pj_inv | :c:func:`proj_trans` | +| ``pj_inv`` | :c:func:`proj_trans` | +---------------------------------------+-------------------------------------------------+ -| pj_fwd3 | :c:func:`proj_trans` | +| ``pj_fwd3`` | :c:func:`proj_trans` | +---------------------------------------+-------------------------------------------------+ -| pj_inv3 | :c:func:`proj_trans` | +| ``pj_inv3`` | :c:func:`proj_trans` | +---------------------------------------+-------------------------------------------------+ -| pj_transform | :c:func:`proj_create_crs_to_crs` | +| ``pj_transform`` | :c:func:`proj_create_crs_to_crs` | | | or :c:func:`proj_create_crs_to_crs_from_pj` + | | | (:c:func:`proj_normalize_for_visualization` +) | | | :c:func:`proj_trans`, | | | :c:func:`proj_trans_array` or | | | :c:func:`proj_trans_generic` | +---------------------------------------+-------------------------------------------------+ -| pj_init | :c:func:`proj_create` / | +| ``pj_init`` | :c:func:`proj_create` / | | | :c:func:`proj_create_crs_to_crs` | +---------------------------------------+-------------------------------------------------+ -| pj_init | :c:func:`proj_create` / | +| ``pj_init`` | :c:func:`proj_create` / | | | :c:func:`proj_create_crs_to_crs` | +---------------------------------------+-------------------------------------------------+ -| pj_free | :c:func:`proj_destroy` | +| ``pj_free`` | :c:func:`proj_destroy` | +---------------------------------------+-------------------------------------------------+ -| pj_is_latlong | :c:func:`proj_get_type` | +| ``pj_is_latlong`` | :c:func:`proj_get_type` | +---------------------------------------+-------------------------------------------------+ -| pj_is_geocent | :c:func:`proj_get_type` | +| ``pj_is_geocent`` | :c:func:`proj_get_type` | +---------------------------------------+-------------------------------------------------+ -| pj_get_def | :c:func:`proj_pj_info` | +| ``pj_get_def`` | :c:func:`proj_pj_info` | +---------------------------------------+-------------------------------------------------+ -| pj_latlong_from_proj | *No direct equivalent*, but can be accomplished | +| ``pj_latlong_from_proj`` | *No direct equivalent*, but can be accomplished | | | by chaining :c:func:`proj_create`, | | | :c:func:`proj_crs_get_horizontal_datum` and | | | :c:func:`proj_create_geographic_crs_from_datum` | +---------------------------------------+-------------------------------------------------+ -| pj_set_finder | :c:func:`proj_context_set_file_finder` | +| ``pj_set_finder`` | :c:func:`proj_context_set_file_finder` | +---------------------------------------+-------------------------------------------------+ -| pj_set_searchpath | :c:func:`proj_context_set_search_paths` | +| ``pj_set_searchpath`` | :c:func:`proj_context_set_search_paths` | +---------------------------------------+-------------------------------------------------+ -| pj_deallocate_grids | *No equivalent* | +| ``pj_deallocate_grids`` | *No equivalent* | +---------------------------------------+-------------------------------------------------+ -| pj_strerrno | *No equivalent* | +| ``pj_strerrno`` | *No equivalent* | +---------------------------------------+-------------------------------------------------+ -| pj_get_errno_ref | :c:func:`proj_errno` | +| ``pj_get_errno_ref`` | :c:func:`proj_errno` | +---------------------------------------+-------------------------------------------------+ -| pj_get_release | :c:func:`proj_info` | +| ``pj_get_release`` | :c:func:`proj_info` | +---------------------------------------+-------------------------------------------------+ Backward incompatibilities ############################################################################### -Access to the proj_api.h is still possible but requires to define the +Access to the :file:`proj_api.h` is still possible but requires to define the ``ACCEPT_USE_OF_DEPRECATED_PROJ_API_H`` macro. The emulation of the now deprecated ``+init=epsg:XXXX`` syntax in PROJ 6 is not @@ -234,9 +234,9 @@ how to use it. First note that in order to go from system A to system B, the old starts by doing an **inverse** transformation from system A to WGS84, then does a **forward** transformation from WGS84 to system B. -With ``cs2cs`` being the command line interface to the old API, and ``cct`` being the same -for the new, this example of doing the same thing in both world views will should give -an idea of the differences: +With :program:`cs2cs` being the command line interface to the old API, and +:program:`cct` being the same for the new, this example of doing the same +thing in both world views will should give an idea of the differences: :: @@ -348,39 +348,40 @@ Function mapping from old to new API +---------------------------------------+---------------------------------------+ | Old API functions | New API functions | +=======================================+=======================================+ -| pj_fwd | :c:func:`proj_trans` | +| ``pj_fwd`` | :c:func:`proj_trans` | +---------------------------------------+---------------------------------------+ -| pj_inv | :c:func:`proj_trans` | +| ``pj_inv`` | :c:func:`proj_trans` | +---------------------------------------+---------------------------------------+ -| pj_fwd3 | :c:func:`proj_trans` | +| ``pj_fwd3`` | :c:func:`proj_trans` | +---------------------------------------+---------------------------------------+ -| pj_inv3 | :c:func:`proj_trans` | +| ``pj_inv3`` | :c:func:`proj_trans` | +---------------------------------------+---------------------------------------+ -| pj_transform | proj_trans_array or proj_trans_generic| +| ``pj_transform`` | :c:func:`proj_trans_array` or | +| | :c:func:`proj_trans_generic` | +---------------------------------------+---------------------------------------+ -| pj_init | :c:func:`proj_create` | +| ``pj_init`` | :c:func:`proj_create` | +---------------------------------------+---------------------------------------+ -| pj_init_plus | :c:func:`proj_create` | +| ``pj_init_plus`` | :c:func:`proj_create` | +---------------------------------------+---------------------------------------+ -| pj_free | :c:func:`proj_destroy` | +| ``pj_free`` | :c:func:`proj_destroy` | +---------------------------------------+---------------------------------------+ -| pj_is_latlong | :c:func:`proj_angular_output` | +| ``pj_is_latlong`` | :c:func:`proj_angular_output` | +---------------------------------------+---------------------------------------+ -| pj_is_geocent | :c:func:`proj_angular_output` | +| ``pj_is_geocent`` | :c:func:`proj_angular_output` | +---------------------------------------+---------------------------------------+ -| pj_get_def | :c:func:`proj_pj_info` | +| ``pj_get_def`` | :c:func:`proj_pj_info` | +---------------------------------------+---------------------------------------+ -| pj_latlong_from_proj | *No equivalent* | +| ``pj_latlong_from_proj`` | *No equivalent* | +---------------------------------------+---------------------------------------+ -| pj_set_finder | *No equivalent* | +| ``pj_set_finder`` | *No equivalent* | +---------------------------------------+---------------------------------------+ -| pj_set_searchpath | *No equivalent* | +| ``pj_set_searchpath`` | *No equivalent* | +---------------------------------------+---------------------------------------+ -| pj_deallocate_grids | *No equivalent* | +| ``pj_deallocate_grids`` | *No equivalent* | +---------------------------------------+---------------------------------------+ -| pj_strerrno | *No equivalent* | +| ``pj_strerrno`` | *No equivalent* | +---------------------------------------+---------------------------------------+ -| pj_get_errno_ref | :c:func:`proj_errno` | +| ``pj_get_errno_ref`` | :c:func:`proj_errno` | +---------------------------------------+---------------------------------------+ -| pj_get_release | :c:func:`proj_info` | +| ``pj_get_release`` | :c:func:`proj_info` | +---------------------------------------+---------------------------------------+ diff --git a/docs/source/development/quickstart.rst b/docs/source/development/quickstart.rst index d53d98fd..eefd5ac3 100644 --- a/docs/source/development/quickstart.rst +++ b/docs/source/development/quickstart.rst @@ -12,8 +12,8 @@ be seen at the end of the section. See the following sections for more in-depth descriptions of different parts of the PROJ API or consult the :doc:`API reference <reference/index>` for specifics. -Before the PROJ API can be used it is necessary to include the ``proj.h`` header -file. Here ``stdio.h`` is also included so we can print some text to the screen: +Before the PROJ API can be used it is necessary to include the :file:`proj.h` header +file. Here :file:`stdio.h` is also included so we can print some text to the screen: .. literalinclude:: ../../../examples/pj_obs_api_mini_demo.c :language: c @@ -45,7 +45,7 @@ a string that describes the target CRS and an optional description of the area o use. The strings for the source or target CRS may be PROJ strings (``+proj=longlat +datum=WGS84``), CRS identified by their code (``EPSG:4326`` or ``urn:ogc:def:crs:EPSG::4326``) or -by a well-known text (WKT) string ( +by a well-known text (WKT) string: :: GEOGCRS["WGS 84", @@ -67,7 +67,6 @@ by a well-known text (WKT) string ( BBOX[-90,-180,90,180]], ID["EPSG",4326]] -). The use of PROJ strings to describe a CRS is considered as legacy (one of the main weakness of PROJ strings is their inability to describe a geodetic datum, other than the few ones hardcoded in the ``+datum`` parameter). @@ -115,7 +114,7 @@ projected CRS. PROJ uses its own data structures for handling coordinates. Here we use a :c:type:`PJ_COORD` which is easily assigned with the function :c:func:`proj_coord`. -When using +proj=longlat, the order of coordinates is longitude, latitude, +When using ``+proj=longlat``, the order of coordinates is longitude, latitude, and values are expressed in degrees. If you used instead a EPSG geographic CRS, like EPSG:4326 (WGS84), it would be latitude, longitude. diff --git a/docs/source/development/reference/datatypes.rst b/docs/source/development/reference/datatypes.rst index b4d3f5c1..e7b5cca0 100644 --- a/docs/source/development/reference/datatypes.rst +++ b/docs/source/development/reference/datatypes.rst @@ -571,7 +571,7 @@ List structures .. c:member:: const char *ell - Elliptical parameter, e.g. `rf=298.257` or `b=6356772.2`. + Elliptical parameter, e.g. ``rf=298.257`` or ``b=6356772.2``. .. c:member:: const char *name @@ -670,8 +670,9 @@ Info structures Search path for PROJ. List of directories separated by semicolons (Windows) or colons (non-Windows), e.g. - "C:\\Users\\doctorwho;C:\\OSGeo4W64\\share\\proj". - Grids and init files are looked for in directories in the search path. + ``C:\\Users\\doctorwho;C:\\OSGeo4W64\\share\\proj``. + Grids and :ref:`init files <init_files>` are looked for in + directories in the search path. .. c:type:: PJ_PROJ_INFO @@ -694,7 +695,7 @@ Info structures .. c:member:: const char *PJ_PROJ_INFO.id Short ID of the operation the :c:type:`PJ` object is based on, that is, - what comes afther the ``+proj=`` in a proj-string, e.g. "*merc*". + what comes after the ``+proj=`` in a proj-string, e.g. "*merc*". .. c:member:: const char *PJ_PROJ_INFO.description @@ -757,7 +758,7 @@ Info structures .. c:member:: int PJ_GRID_INFO.n_lat - Number of grid cells in the latitudianl direction. + Number of grid cells in the latitudinal direction. .. c:member:: double PJ_GRID_INFO.cs_lon @@ -793,7 +794,7 @@ Info structures .. c:member:: char PJ_INIT_INFO.version[32] - Version number of init-file, e.g. "*9.0.0*" + Version number of init file, e.g. "*9.0.0*" .. c:member:: char PJ_INIT_INFO.origin[32] @@ -801,7 +802,7 @@ Info structures .. c:member:: char PJ_INIT_INFO.lastupdate - Date of last update of the init-file. + Date of last update of the init file. .. _error_codes: @@ -860,16 +861,16 @@ Errors in class PROJ_ERR_COORD_TRANSFM .. c:macro:: PROJ_ERR_COORD_TRANSFM_INVALID_COORD - Invalid input coordinate. e.g a latitude > 90°. + Invalid input coordinate. e.g. a latitude > 90°. .. c:macro:: PROJ_ERR_COORD_TRANSFM_OUTSIDE_PROJECTION_DOMAIN - Coordinate is outside of the projection domain. e.g approximate mercator with \|longitude - lon_0\| > 90°, - or iterative convergence method failed. + Coordinate is outside of the projection domain. e.g. approximate mercator + with \|longitude - lon_0\| > 90°, or iterative convergence method failed. .. c:macro:: PROJ_ERR_COORD_TRANSFM_NO_OPERATION - No operation found, e.g if no match the required accuracy, or if ballpark transformations + No operation found, e.g. if no match the required accuracy, or if ballpark transformations were asked to not be used and they would be only such candidate. .. c:macro:: PROJ_ERR_COORD_TRANSFM_OUTSIDE_GRID diff --git a/docs/source/development/reference/functions.rst b/docs/source/development/reference/functions.rst index edb61b08..29b52149 100644 --- a/docs/source/development/reference/functions.rst +++ b/docs/source/development/reference/functions.rst @@ -33,7 +33,7 @@ Transformation setup ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The objects returned by the functions defined in this section have minimal -interaction with the the functions of the +interaction with the functions of the `C API for ISO-19111 functionality`_, and vice versa. See its introduction paragraph for more details. @@ -686,7 +686,7 @@ Distances :param PJ_COORD b: Coordinate of second point :returns: `PJ_COORD` where the first value is the distance between :c:data:`a` and :c:data:`b` in meters, the second value is the forward azimuth - and the thir value is the reverse azimuth. The fourth coordinate + and the third value is the reverse azimuth. The fourth coordinate value is unused. @@ -930,7 +930,7 @@ The PJ* objects returned by :c:func:`proj_create_from_wkt`, :c:func:`proj_create_from_database` and other functions in that section will have generally minimal interaction with the functions declared in the previous sections (calling those functions on those objects -will either return an error or default/non-sensical values). The exception is +will either return an error or default/nonsensical values). The exception is for ISO19111 objects of type CoordinateOperation that can be exported as a valid PROJ pipeline. In this case, objects will work for example with :c:func:`proj_trans_generic`. diff --git a/docs/source/development/reference/macros.rst b/docs/source/development/reference/macros.rst index 131b8e72..c25aeed2 100644 --- a/docs/source/development/reference/macros.rst +++ b/docs/source/development/reference/macros.rst @@ -6,15 +6,15 @@ Macros .. c:macro:: PROJ_VERSION_MAJOR - Major version number, e.g 8 for PROJ 8.0.1 + Major version number, e.g. 8 for PROJ 8.0.1 .. c:macro:: PROJ_VERSION_MINOR - Minor version number, e.g 0 for PROJ 8.0.1 + Minor version number, e.g. 0 for PROJ 8.0.1 .. c:macro:: PROJ_VERSION_PATCH - Patch version number, e.g 1 for PROJ 8.0.1 + Patch version number, e.g. 1 for PROJ 8.0.1 .. c:macro:: PROJ_COMPUTE_VERSION(maj,min,patch) diff --git a/docs/source/faq.rst b/docs/source/faq.rst index 5a6763bc..c34d6235 100644 --- a/docs/source/faq.rst +++ b/docs/source/faq.rst @@ -39,13 +39,15 @@ ETRS89/UTM32N (EPSG:25832) and ETRS89/DKTM1 (EPSG:4093): $ ./projinfo -s EPSG:25832 -t EPSG:4093 -o PROJ Candidate operations found: 1 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, Inverse of UTM zone 32N + DKTM1, 0 m, World PROJ string: - +proj=pipeline +step +inv +proj=utm +zone=32 +ellps=GRS80 - +step +proj=tmerc +lat_0=0 +lon_0=9 +k=0.99998 +x_0=200000 +y_0=-5000000 +ellps=GRS80 + +proj=pipeline + +step +inv +proj=utm +zone=32 +ellps=GRS80 + +step +proj=tmerc +lat_0=0 +lon_0=9 +k=0.99998 +x_0=200000 +y_0=-5000000 + +ellps=GRS80 See the :program:`projinfo` :ref:`documentation <projinfo>` for more info on how to use it. @@ -125,7 +127,7 @@ input ordered as latitude/longitude (typically with the EPSG dataset), however, internally PROJ expects an longitude/latitude ordering for all projections. This is generally hidden for users but in a few cases it is exposed at the surface level of PROJ, most prominently in the :program:`proj` utility which expects -longitude/latitude ordering of input date (unless :program:`proj -r` is used). +longitude/latitude ordering of input date (unless :option:`proj -r` is used). In case of doubt about the axis order of a specific CRS :program:`projinfo` is able to provide an answer. Simply look up the CRS and examine the axis specification @@ -181,7 +183,7 @@ was simply known as PROJ. Eventually a new version was released, known as PROJ.2 in order to distinguish between the two versions. Later on both PROJ.3 and PROJ.4 was released. By the time PROJ.4 was released the software had matured enough that a new major version release wasn't an -immediate necesity. PROJ.4 was around for more than 25 years before it +immediate necessity. PROJ.4 was around for more than 25 years before it again became time for an update. This left the project in a bit of a conundrum regarding the name. For the majority of the life-time of the product it was known as PROJ.4, but with the release of version 5 the name was no longer aligned with the version number. As a consequence, it was diff --git a/docs/source/geodesic.rst b/docs/source/geodesic.rst index 11bb5e5c..69b95830 100644 --- a/docs/source/geodesic.rst +++ b/docs/source/geodesic.rst @@ -51,12 +51,8 @@ PROJ incorporates `C library for Geodesics <https://geographiclib.sourceforge.io>`_. This library provides routines to solve the direct and inverse geodesic problems. Full double precision accuracy is maintained provided that -:math:`\lvert f\rvert<\frac1{50}`. Refer -to the - - `application programming interface - <https://geographiclib.sourceforge.io/1.49/C/geodesic_8h.html>`_ - +:math:`\lvert f\rvert<\frac1{50}`. Refer to the `application programming interface +<https://geographiclib.sourceforge.io/1.49/C/geodesic_8h.html>`_ for full documentation. A brief summary of the routines is given in geodesic(3). diff --git a/docs/source/glossary.rst b/docs/source/glossary.rst index 4c1507a4..147645ad 100644 --- a/docs/source/glossary.rst +++ b/docs/source/glossary.rst @@ -11,7 +11,7 @@ Glossary For a transformation between two geographic CRS, a ballpark transformation is a coordinate operation that only takes into account potential difference of axis orders (long-lat vs lat-long), - units (degree vs grads) and prime meridian (Greewich vs Paris/Rome/other + units (degree vs grads) and prime meridian (Greenwich vs Paris/Rome/other historic prime meridians). It does not attempt any datum shift, hence the "ballpark" qualifier in its name. Its accuracy is unknown, and could lead in some cases to errors of a few hundreds of metres. diff --git a/docs/source/install.rst b/docs/source/install.rst index b382662e..95db56df 100644 --- a/docs/source/install.rst +++ b/docs/source/install.rst @@ -101,14 +101,14 @@ On Debian and similar systems (e.g. Ubuntu) the APT package manager is used:: Fedora ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -On Fedora the dnf package manager is used:: +On Fedora the :program:`dnf` package manager is used:: sudo dnf install proj Red Hat ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -On Red Hat based system packages are installed with yum:: +On Red Hat based system packages are installed with :program:`yum`:: sudo yum install proj diff --git a/docs/source/news.rst b/docs/source/news.rst index 20670b1b..a1570783 100644 --- a/docs/source/news.rst +++ b/docs/source/news.rst @@ -128,7 +128,7 @@ Updates Bug fixes --------- -* Do not restrict longitude to [-90;90] range in spherical transver Mercator +* Do not restrict longitude to [-90;90] range in spherical transverse Mercator forward projection (`#2471 <https://github.com/OSGeo/PROJ/issues/2471>`_) * :cpp:func:`createOperations()`: fix Compound to Geog3D/Projected3D CRS with non-metre ellipsoidal height (`#2500 <https://github.com/OSGeo/PROJ/issues/2500>`_) @@ -351,7 +351,7 @@ Updates * Update to EPSG 9.8.12, ESRI 10.8.1 and import scope and remarks for conversion (`#2238 <https://github.com/OSGeo/PROJ/issues/2238>`_) (#2267) - * Map the Behrman projection to ``cae`` when converting ESRI CRSes (`#1986 <https://github.com/OSGeo/PROJ/issues/1986>`_) + * Map the Behrmann projection to ``cae`` when converting ESRI CRSes (`#1986 <https://github.com/OSGeo/PROJ/issues/1986>`_) * Support conversion of Flat_Polar_Quartic projection method (`#1987 <https://github.com/OSGeo/PROJ/issues/1987>`_) @@ -410,7 +410,7 @@ Updates * Follow PDAL's CMake RPATH strategy (`#2009 <https://github.com/OSGeo/PROJ/issues/2009>`_) - * WKT import/export: add support for WKT1_ESRI VERTCS synta (`#2024 <https://github.com/OSGeo/PROJ/issues/2024>`_) + * WKT import/export: add support for WKT1_ESRI VERTCS syntax (`#2024 <https://github.com/OSGeo/PROJ/issues/2024>`_) * :program:`projinfo`: add a ``--hide-ballpark`` option (`#2127 <https://github.com/OSGeo/PROJ/issues/2127>`_) diff --git a/docs/source/operations/conversions/geoc.rst b/docs/source/operations/conversions/geoc.rst index a9be2dfb..6ee32ea6 100644 --- a/docs/source/operations/conversions/geoc.rst +++ b/docs/source/operations/conversions/geoc.rst @@ -36,7 +36,7 @@ the body centre to the considered point. .. note:: - This conversion must be distinguished fom the :ref:`cart` + This conversion must be distinguished from the :ref:`cart` which converts geodetic coordinates to geocentric coordinates in the cartesian domain. diff --git a/docs/source/operations/operations_computation.rst b/docs/source/operations/operations_computation.rst index 0d78feae..0bc57ff0 100644 --- a/docs/source/operations/operations_computation.rst +++ b/docs/source/operations/operations_computation.rst @@ -69,7 +69,7 @@ Geographic CRS to Geographic CRS, with known identifiers With the above example of two geographic CRS, that have an identified identifier, (:program:`projinfo` internally resolves NAD27 to EPSG:4267 and NAD83 to EPSG:4269) the algorithm will first search -in the coordinate operation related tables of the ``proj.db`` if there are records +in the coordinate operation related tables of the :file:`proj.db` if there are records that list direct transformations between the source and the target CRS. The transformations typically involve :ref:`Helmert <helmert>`-style operations or datum shift based on grids (more esoteric operations are possible). @@ -161,7 +161,7 @@ Geodetic/geographic CRS to Geodetic/geographic CRS, without known identifiers In a number of situations, the source and/or target CRS do not have an identifier (WKT without identifier, PROJ string, ..) -The first step is to try to find in the ``proj.db`` a CRS of the same nature of +The first step is to try to find in the :file:`proj.db` a CRS of the same nature of the CRS to identify and whose name exactly matches the one provided to the :c:func:`createOperations` method. If there is exactly one match and that the CRS are "computationally" equivalent, then use the code of the CRS for further computations. @@ -238,7 +238,7 @@ are equivalent for most purposes. Candidate operations found: 1 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, axis order change (geographic3D horizontal) + RGF93 to ETRS89 (1) + Conversion from ETRS89 (geog2D) to ETRS89 (geocentric), 0 m, France @@ -338,7 +338,7 @@ following results for the AGD84 to GDA2020 coordinate operations lookup: Candidate operations found: 4 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, AGD84 to GDA94 (5) + GDA94 to GDA2020 (1), 0.11 m, Australia - AGD84 @@ -357,7 +357,7 @@ following results for the AGD84 to GDA2020 coordinate operations lookup: +step +proj=axisswap +order=2,1 ------------------------------------- - Operation n°2: + Operation No. 2: unknown id, AGD84 to GDA94 (2) + GDA94 to GDA2020 (1), 1.01 m, Australia - AGD84 @@ -378,7 +378,7 @@ following results for the AGD84 to GDA2020 coordinate operations lookup: +step +proj=axisswap +order=2,1 ------------------------------------- - Operation n°3: + Operation No. 3: unknown id, AGD84 to GDA94 (5) + GDA94 to GDA2020 (2), 0.15 m, unknown domain of validity @@ -391,7 +391,7 @@ following results for the AGD84 to GDA2020 coordinate operations lookup: +step +proj=axisswap +order=2,1 ------------------------------------- - Operation n°4: + Operation No. 4: unknown id, AGD84 to GDA94 (5) + GDA94 to GDA2020 (3), 0.15 m, unknown domain of validity @@ -424,7 +424,7 @@ If one forces the datum hub to be considered to be EPSG:4326, ones gets: Candidate operations found: 2 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, AGD84 to WGS 84 (7) + Inverse of GDA2020 to WGS 84 (2), 4 m, Australia - AGD84 @@ -442,7 +442,7 @@ If one forces the datum hub to be considered to be EPSG:4326, ones gets: +step +proj=axisswap +order=2,1 ------------------------------------- - Operation n°2: + Operation No. 2: unknown id, AGD84 to WGS 84 (9) + Inverse of GDA2020 to WGS 84 (2), 4 m, Australia - AGD84 @@ -500,7 +500,7 @@ particular case. Such transformations are done in 2 steps: Candidate operations found: 1 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, Inverse of UTM zone 31N + Inverse of RGF93 to WGS 84 (1), 1 m, France @@ -531,7 +531,7 @@ between those: $ projinfo -s "NAVD88 height" -t "NAD83(2011)" -o PROJ --spatial-test intersects Candidate operations found: 11 ------------------------------------- - Operation n°1: + Operation No. 1: INVERSE(DERIVED_FROM(EPSG)):9229, Inverse of NAD83(2011) to NAVD88 height (3), 0.015 m, USA - CONUS - onshore @@ -560,7 +560,7 @@ This is implemented by the ``createOperationsVertToVert`` method Candidate operations found: 3 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, Inverse of NGVD29 height (ftUS) to NGVD29 depth (ftUS) + NGVD29 height (ftUS) to NGVD29 height (m) + NGVD29 height (m) to NAVD88 height (3), 0.02 m, USA - CONUS east of 89°W - onshore @@ -568,7 +568,7 @@ This is implemented by the ``createOperationsVertToVert`` method +proj=pipeline +step +proj=axisswap +order=1,2,-3 +step +proj=unitconvert +z_in=us-ft +z_out=m +step +proj=vgridshift +grids=vertcone.gtx +multiplier=0.001 ------------------------------------- - Operation n°2: + Operation No. 2: unknown id, Inverse of NGVD29 height (ftUS) to NGVD29 depth (ftUS) + NGVD29 height (ftUS) to NGVD29 height (m) + NGVD29 height (m) to NAVD88 height (2), 0.02 m, USA - CONUS 89°W-107°W - onshore @@ -576,7 +576,7 @@ This is implemented by the ``createOperationsVertToVert`` method +proj=pipeline +step +proj=axisswap +order=1,2,-3 +step +proj=unitconvert +z_in=us-ft +z_out=m +step +proj=vgridshift +grids=vertconc.gtx +multiplier=0.001 ------------------------------------- - Operation n°3: + Operation No. 3: unknown id, Inverse of NGVD29 height (ftUS) to NGVD29 depth (ftUS) + NGVD29 height (ftUS) to NGVD29 height (m) + NGVD29 height (m) to NAVD88 height (1), 0.02 m, USA - CONUS west of 107°W - onshore @@ -761,7 +761,7 @@ Example: Candidate operations found: 1 ------------------------------------- - Operation n°1: + Operation No. 1: unknown id, Inverse of unknown + Transformation from unknown to WGS84 + Inverse of ETRS89 to WGS 84 (1), unknown accuracy, Europe - ETRS89 diff --git a/docs/source/operations/pipeline.rst b/docs/source/operations/pipeline.rst index 90112c05..97b58e3e 100644 --- a/docs/source/operations/pipeline.rst +++ b/docs/source/operations/pipeline.rst @@ -57,7 +57,7 @@ Rules for pipelines Will result in an error. -**2. Pipelines can only be nested if the nested pipeline is defined in an init-file.** +**2. Pipelines can only be nested if the nested pipeline is defined in an init file.** :: diff --git a/docs/source/operations/projections/cc.rst b/docs/source/operations/projections/cc.rst index 81ea17db..c6f3927a 100644 --- a/docs/source/operations/projections/cc.rst +++ b/docs/source/operations/projections/cc.rst @@ -31,7 +31,7 @@ Central Cylindrical Parameters ################################################################################ -.. note:: All parameters are optional for the Central Cylindricla projection. +.. note:: All parameters are optional for the Central Cylindrical projection. .. include:: ../options/lon_0.rst diff --git a/docs/source/operations/projections/gall.rst b/docs/source/operations/projections/gall.rst index c5f05478..8114815a 100644 --- a/docs/source/operations/projections/gall.rst +++ b/docs/source/operations/projections/gall.rst @@ -43,12 +43,12 @@ The Gall projection is neither conformal nor equal-area, but has a blend of vari Unlike the Mercator, the Gall shows the poles as lines running across the top and bottom of the map. -Example using Gall Stereographical :: +Example using Gall Stereographic :: $ echo 9 51 | proj +proj=gall +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +units=m 708432.90 5193386.36 -Example using Gall Stereographical (Central meridian 90°W) :: +Example using Gall Stereographic (Central meridian 90°W) :: $ echo 9 51 | proj +proj=gall +lon_0=90w +x_0=0 +y_0=0 +ellps=WGS84 +units=m 7792761.91 5193386.36 @@ -72,7 +72,7 @@ Parameters Mathematical definition ####################### -The formulas describing the Gall Stereographical are all taken from :cite:`Snyder1993`. +The formulas describing the Gall Stereographic are all taken from :cite:`Snyder1993`. Spherical form ************** diff --git a/docs/source/operations/projections/gnom.rst b/docs/source/operations/projections/gnom.rst index c9fc4bcf..c18ab4e7 100644 --- a/docs/source/operations/projections/gnom.rst +++ b/docs/source/operations/projections/gnom.rst @@ -31,7 +31,7 @@ Gnomonic Parameters ################################################################################ -.. note:: All parameters are optional for the Gnomomic projection. +.. note:: All parameters are optional for the Gnomonic projection. .. include:: ../options/lon_0.rst diff --git a/docs/source/operations/projections/lcc.rst b/docs/source/operations/projections/lcc.rst index 8002fa31..bf15d76a 100644 --- a/docs/source/operations/projections/lcc.rst +++ b/docs/source/operations/projections/lcc.rst @@ -23,7 +23,7 @@ justifies adding this otherwise non-standard projection. | **Available forms** | Forward and inverse, spherical and ellipsoidal .| | | One or two standard parallels (1SP and 2SP). | | | "LCC 2SP Michigan" form can be used by setting | -| | `+k_0` parameter to specify elliposid scale. | +| | ``+k_0`` parameter to specify ellipsoid scale. | +---------------------+----------------------------------------------------------+ | **Defined area** | Best for regions predominantly east–west in extent and | | | located in the middle north or south latitudes. | diff --git a/docs/source/operations/projections/merc.rst b/docs/source/operations/projections/merc.rst index 2107b7b2..6eae9d36 100644 --- a/docs/source/operations/projections/merc.rst +++ b/docs/source/operations/projections/merc.rst @@ -181,7 +181,7 @@ This is obtained by taking the :math:`\sinh` of the equation for using :math:`\tau = \tau'/(1 - e^2)` as an initial guess and with the needed derivative given by -..math:: +.. math:: \frac{d\tau'}{d\tau} = \frac{1 - e^2}{1 + (1 - e^2)\tau^2} \sqrt{1 + \tau'^2} \sqrt{1 + \tau^2} diff --git a/docs/source/operations/projections/tmerc.rst b/docs/source/operations/projections/tmerc.rst index 3a18904f..576ad327 100644 --- a/docs/source/operations/projections/tmerc.rst +++ b/docs/source/operations/projections/tmerc.rst @@ -156,7 +156,7 @@ Spherical form ************** Because the full (ellipsoidal) projection includes the spherical -projection as one of the components, we present the spherial form first +projection as one of the components, we present the spherical form first with the coordinates tagged with primes, :math:`\phi'`, :math:`\lambda'`, :math:`\zeta' = \xi' + i\eta'`, :math:`x'`, :math:`y'`, so that they can be distinguished from the corresponding diff --git a/docs/source/operations/projections/tobmerc.rst b/docs/source/operations/projections/tobmerc.rst index 69a4855d..7bc5cb95 100644 --- a/docs/source/operations/projections/tobmerc.rst +++ b/docs/source/operations/projections/tobmerc.rst @@ -40,7 +40,7 @@ The inappropriate use of the Mercator projection has declined but still occasionally occurs. One method of contrasting the Mercator projection is to present an alternative in the form of an equal area projection. The map projection derived here is thus not simply a pretty Christmas tree ornament: -it is instead a complement to Mercator's conformal navigation anamorphose +it is instead a complement to Mercator's conformal navigation anamorphosis and can be displayed as an alternative. The equations for the new map projection preserve the latitudinal stretching of the Mercator while adjusting the longitudinal spacing. This allows placement of the new map diff --git a/docs/source/operations/projections/utm.rst b/docs/source/operations/projections/utm.rst index 6b957472..2367cbad 100644 --- a/docs/source/operations/projections/utm.rst +++ b/docs/source/operations/projections/utm.rst @@ -47,7 +47,7 @@ Convert geodetic coordinate to UTM Zone 32 on the northern hemisphere:: $ echo 12 56 | proj +proj=utm +zone=32 687071.44 6210141.33 -Convert geodetic coordinate to UTM Zone 59 on the souther hemisphere:: +Convert geodetic coordinate to UTM Zone 59 on the southern hemisphere:: $ echo 174 -44 | proj +proj=utm +zone=59 +south 740526.32 5123750.87 diff --git a/docs/source/operations/transformations/xyzgridshift.rst b/docs/source/operations/transformations/xyzgridshift.rst index 6a3a40f0..e76b3a63 100644 --- a/docs/source/operations/transformations/xyzgridshift.rst +++ b/docs/source/operations/transformations/xyzgridshift.rst @@ -38,7 +38,7 @@ method in the forward direction, and direct read in the reverse direction. Example ------------------------------------------------------------------------------- -NTF to RGF93 transformation using gr3df97a.tif grid +NTF to RGF93 transformation using :file:`gr3df97a.tif` grid :: @@ -83,7 +83,7 @@ Optional If output_crs is specified, the grid is referenced in the geographic CRS corresponding to the output geocentric CRS. This is for example the case for the French - gr3df97a.tif grid converting from NTF to RGF93, but referenced against RGF93. + :file:`gr3df97a.tif` grid converting from NTF to RGF93, but referenced against RGF93. Thus in the forward direction (NTF->RGF93), an iterative method is used to find the appropriate shift. diff --git a/docs/source/resource_files.rst b/docs/source/resource_files.rst index 0f902d8d..d3b4d5f6 100644 --- a/docs/source/resource_files.rst +++ b/docs/source/resource_files.rst @@ -10,8 +10,8 @@ contain preconfigured proj-strings for various coordinate reference systems and the `defaults` file contains default values for parameters of select projections. -In addition to the bundled init-files the PROJ project also distributes a number -of packages containing transformation grids and additional init-files not included +In addition to the bundled init files the PROJ project also distributes a number +of packages containing transformation grids and additional init files not included in the main PROJ package. .. _resource_file_paths: @@ -20,7 +20,7 @@ Where are PROJ resource files looked for ? ------------------------------------------------------------------------------- PROJ will attempt to locate its resource files - database, transformation grids -or init-files - from several directories. +or init files - from several directories. The following paths are checked in order: - For resource files that have an explicit relative or absolute path, @@ -39,29 +39,30 @@ The following paths are checked in order: The PROJ user writable directory, which is : - * on Windows, ${LOCALAPPDATA}/proj - * on MacOSX, ${HOME}/Library/Application Support/proj - * on other platforms (Linux), ${XDG_DATA_HOME}/proj if :envvar:`XDG_DATA_HOME` - is defined. Else ${HOME}/.local/share/proj + * on Windows, ``${LOCALAPPDATA}/proj`` + * on macOS, ``${HOME}/Library/Application Support/proj`` + * on other platforms (Linux), ``${XDG_DATA_HOME}/proj`` if + :envvar:`XDG_DATA_HOME` is defined. Else ``${HOME}/.local/share/proj`` - Path(s) set with by the environment variable :envvar:`PROJ_LIB`. - On Linux/MacOSX/Unix, use ``:`` to separate paths. On Windows, ``;`` + On Linux/macOS/Unix, use ``:`` to separate paths. On Windows, ``;`` - .. versionadded:: 7.0 - The *../share/proj/* and its contents are found automatically + The :file:`../share/proj/` and its contents are found automatically at run-time if the installation respects the build structure. That is, the - binaries and proj.dll/libproj.so are installed under *../bin/* or *../lib/*, - and resource files are in *../share/proj/*. + binaries and :file:`proj.dll`/:file:`libproj.so` are installed under + :file:`../bin/` or :file:`../lib/`, and resource files are in + :file:`../share/proj/`. - A path built into PROJ as its resource installation directory (whose value is - $(pkgdatadir) for builds using the Makefile build system or - ${CMAKE_INSTALL_PREFIX}/${DATADIR} for CMake builds). Note, however, + ``$(pkgdatadir)`` for builds using the Makefile build system or + ``${CMAKE_INSTALL_PREFIX}/${DATADIR}`` for CMake builds). Note, however, that since this is a hard-wired path setting, it only works if the whole PROJ installation is not moved somewhere else. - .. note:: if PROJ is built with the PROJ_LIB_ENV_VAR_TRIED_LAST CMake option / - --enable-proj-lib-env-var-tried-last configure switch, then this + .. note:: if PROJ is built with the ``PROJ_LIB_ENV_VAR_TRIED_LAST`` CMake option / + ``--enable-proj-lib-env-var-tried-last`` configure switch, then this hard-wired path will be tried before looking at the environment variable :envvar:`PROJ_LIB`. @@ -74,7 +75,7 @@ attempt to use remote grids stored on CDN (Content Delivery Network) storage. .. _proj-db: -proj.db +:file:`proj.db` ------------------------------------------------------------------------------- A proj installation includes a SQLite database of transformation information @@ -83,13 +84,13 @@ print an error if the database can't be found. .. _proj-ini: -proj.ini +:file:`proj.ini` ------------------------------------------------------------------------------- .. versionadded:: 7.0 -proj.ini is a text configuration file, mostly dedicated at setting up network -related parameters. +:file:`proj.ini` is a text configuration file, mostly dedicated at setting up +network related parameters. Its default content is: @@ -152,9 +153,9 @@ proj-datumgrid .. note:: The packages described below can be used with PROJ 7 and later but are - primarily meant to be used with PROJ 6 and earlier versions. The proj-datumgrid - series of packages are not maintained anymore and are only kept available for - legacy purposes. + primarily meant to be used with PROJ 6 and earlier versions. + The ``proj-datumgrid`` series of packages are not maintained anymore and + are only kept available for legacy purposes. For a functioning build of PROJ prior to version 7, installation of the `proj-datumgrid <https://github.com/OSGeo/proj-datumgrid>`_ is needed. If you @@ -170,8 +171,8 @@ legacy reasons. Without this package, the test suite fails miserably. Regional packages +++++++++++++++++ -In addition to the default *proj-datumgrid* package regional packages are also -distributed. These include grids and init-files that are valid within the given +In addition to the default ``proj-datumgrid`` package regional packages are also +distributed. These include grids and init files that are valid within the given region. The packages are divided into geographical regions in order to keep the needed disk space by PROJ at a minimum. Some users may have a use for resource files covering several regions in which case they can download more than one. @@ -200,8 +201,8 @@ includes grids that have global extent, e.g. the global geoid model EGM08. -latest packages ++++++++++++++++ -All packages above come in different versions, e.g proj-datumgrid-1.8 or -proj-datumgrid-europe-1.4. The `-latest` packages are symbolic links to the +All packages above come in different versions, e.g., ``proj-datumgrid-1.8`` or +``proj-datumgrid-europe-1.4``. The ``-latest`` packages are symbolic links to the latest version of a given package. That means that the link https://download.osgeo.org/proj/proj-datumgrid-north-america-latest.zip is equivalent to https://download.osgeo.org/proj/proj-datumgrid-north-america-1.2.zip @@ -269,7 +270,7 @@ Spain HTDP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -This section describes the use of the `crs2crs2grid.py` script and the HTDP +This section describes the use of the :file:`crs2crs2grid.py` script and the HTDP (Horizontal Time Dependent Positioning) grid shift modelling program from NGS/NOAA to produce PROJ compatible grid shift files for fine grade conversions between various NAD83 epochs and WGS84. Traditionally PROJ has @@ -286,23 +287,24 @@ Getting and building HTDP The HTDP modelling program is written in FORTRAN. The source and documentation can be found on the HTDP page at http://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml -On linux systems it will be necessary to install `gfortran` or some FORTRAN -compiler. For ubuntu something like the following should work. +On Linux systems it will be necessary to install GFortran or some Fortran +compiler. For Ubuntu something like the following should work. :: apt-get install gfortran -To compile the program do something like the following to produce the binary "htdp" from the source code. +To compile the program do something like the following to produce the binary +:program:`htdp` from the source code. :: gfortran htdp.for -o htdp -Getting crs2crs2grid.py +Getting :file:`crs2crs2grid.py` ................................................................................ -The `crs2crs2grid.py` script can be found at +The :file:`crs2crs2grid.py` script can be found at https://github.com/OSGeo/gdal/tree/master/gdal/swig/python/samples/crs2crs2grid.py The script depends on having the GDAL Python bindings operational; if they are not you @@ -336,16 +338,16 @@ Usage crs2crs2grid.py 29 2002.0 8 2002.0 -o nad83_2002.ct2 -The goal of `crs2crs2grid.py` is to produce a grid shift file for a designated -region. The region is defined using the `-griddef` switch. When missing a +The goal of :file:`crs2crs2grid.py` is to produce a grid shift file for a designated +region. The region is defined using the ``-griddef`` switch. When missing a continental US region is used. The script creates a set of sample points for -the grid definition, runs the "htdp" program against it and then parses the +the grid definition, runs :program:`htdp` against it and then parses the resulting points and computes a point by point shift to encode into the final -grid shift file. By default it is assumed the `htdp` program will be in the +grid shift file. By default it is assumed that :program:`htdp` is in the executable path. If not, please provide the path to the executable using the -`-htdp` switch. +``-htdp`` switch. -The `htdp` program supports transformations between many CRSes and for each (or +The :program:`htdp` program supports transformations between many CRSes and for each (or most?) of them you need to provide a date at which the CRS is fixed. The full set of CRS Ids available in the HTDP program are: @@ -406,13 +408,13 @@ 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 transform between any two coordinate reference systems with -``cs2cs``. Init files can however contain any proj-string and don't necessarily +:program:`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 directory -listed in the ``PROJ_LIB`` environment variable. +listed in the :envvar:`PROJ_LIB` environment variable. The format of init files is an identifier in angled brackets and a proj-string: diff --git a/docs/source/specifications/geodetictiffgrids.rst b/docs/source/specifications/geodetictiffgrids.rst index 086690b2..402ce304 100644 --- a/docs/source/specifications/geodetictiffgrids.rst +++ b/docs/source/specifications/geodetictiffgrids.rst @@ -73,7 +73,7 @@ is an easy way to inspect such grid files: .. note:: Regarding anti-meridian handling, a variety of possibilities exist. - We do not attempt to standardize this and filesh hosted on the CDN will use + We do not attempt to standardize this and files hosted on the CDN will use a georeferencing close to the original data producer. For example, NOAA vertical grids that apply to Conterminous USA might even have a top-left longitude beyond 180 (for consistency with Alaska grids, whose origin is < 180) @@ -406,7 +406,7 @@ is an easy way to inspect such grid files: Will be ignored by PROJ (this information can be inferred by the grids extent) * The ``parent_grid_name`` metadata item should be present if this is a - subgrid and its value should be equal to the paren's ``grid_name`` + subgrid and its value should be equal to the parent's ``grid_name`` Will be ignored by PROJ (this information can be inferred by the grids extent) * The ``number_of_nested_grids`` metadata item should be present if there are @@ -569,7 +569,7 @@ tag set to 0. If a low-resolution grid is available, it should be put before subgrids of higher-resolution in the chain of IFD linking. On reading, PROJ will use the -value from the highest-resoluted grid that contains the point of interest. +value from the highest-resolution grid that contains the point of interest. For efficient reading from the network, files hosted on the CDN will use a layout similar to the one described in the `low level paragraph of the Cloud Optimized GeoTIFF diff --git a/docs/source/spelling_wordlist.txt b/docs/source/spelling_wordlist.txt new file mode 100644 index 00000000..9a3143d7 --- /dev/null +++ b/docs/source/spelling_wordlist.txt @@ -0,0 +1,455 @@ +# Core library and programs +PROJ +proj +libproj +projinfo +projsync +geod +gie +cct +cs2cs + +# Short English +db +de +etc +ok +pre +st +nd +rd +th + +# Expanded English +accuracies +advertized +authorized +authorizes +Authorizing +Behavior +behavior +behaviors +catalog +Center +center +centered +centerline +centers +centimeter +centimetric +centralizes +customized +characterized +decimeter +favorable +favorite +formalization +formalized +generalization +generalized +homology +honored +initialization +initialize +initialized +initializing +instantiation +interpretable +Kilometer +materializes +Millimeter +millimeters +millimetric +minimize +modeling +nanometers +normalized +Optimization +optimization +optimizations +optimized +organization +organizations +organized +parametrize +piecewise +prioritized +realized +realization +realizations +recognize +recognized +selectable +serialization +serialized +specialized +standardize +standardized +synchronizing +synthetize +synthetized +timespan +unrecognized +utilized +utilizing +visualization + +# CRS-related abbreviations +bbox +calcofi +conus +crs +cs +dms +ENU +ETRS +EPSG +epsg +IGNF +lcc +lcca +laea +lat +latlon +latlong +lats +lon +lonlat +longlat +misrsom +nad +NTv +ogc +omerc +OSGeo +osgeo +srs +tmerc +towgs +utm +wgs +wkt + +# Names +Aitoff +aitoff +Albers +Apian +apian +Badekas +Bertin +bertin +Boaga +Boggs +boggs +Bonne +bonne +cartesian +Cassini +Chamberlin +Chebyshev +clarke +Collignon +Craster +Delaunay +der +Denoyer +Eckert +euler +Eumorphic +Evenden +Fahey +fahey +Fairgrieve +Flamsteed +Foucaut +Goode +goode +Greifendorff +Grinten +Guyou +Hartebeesthoek +Hatano +Hayford +Helmert +helmert +Horner +horner +Hotine +Karney +Kavraisky +Krovak +krovak +Krüger +Laborde +Larrivée +Larrivee +Laskowski +mercator +Mollweide +Molodensky +molodensky +Nicolosi +Ortelius +Putnins +Raphson +Roussilhe +Sanson +Schreiber +Soldner +Tissot +Tobler +Tscherning +Urmaev +Vincenty +Vitkovsky +Warmerdam +Werenskiold +Werner +Winkel + +# Terminology +Affine +affine +aseismic +anamorphosis +antimeridian +aposphere +Authalic +Azimuthal +azimuthal +barycentric +biaxial +bilinear +cadastral +Carrée +carrée +centrographic +Conformal +conformal +conformant +datums +dataset +datasets +dodecahedron +easting +Epicycloidal +Equirectangular +equirectangular +Geoid +geoid +geodesist +geodesists +Geospatial +geospatial +georeferencing +gimbal +Gnomonic +graticule +graticules +gridded +HEALPix +healpix +Homolosine +homolosine +Icosahedral +icosahedron +inhomogeneous +intraplate +Isostatic +isostatic +invertible +kinematically +Landsat +Loximuthal +mapmaking +maximimize +Meridional +meridional +Microradian +Northing +northing +northings +Oblated +parameterising +planetocentric +planetographic +polewards +Polyconic +prolate +proleptic +Pseudoazimuthal +Pseudoconical +pseudoconical +Pseudocylindrical +pseudocylindrical +Quadrilateralized +Quartic +Quincuncial +rasters +rHEALPix +rhealpix +rhumb +roundtrip +Semimajor +semimajor +Semiminor +sexagesimal +Southing +southing +spatiotemporal +Stereographic +stereographic +supersession +tangency +topocentric +triangulations +triaxial +Trimetric +Tripel +unitless +unrotated +Webmercator +westing + +# Locations +Amersfoort +athens +bern +bogota +brussels +europe +greenwich +jakarta +lisbon +madrid +oslo +paris +Potsdam +Pulkovo +rome +stockholm + +# Technology jargon +analyzer +api +argc +args +argv +autoconf +Autotools +autotools +basename +boolean +CMake +cmake +codespace +compoundCRS +Conda +conda +const +constexpr +cpp +cppcheck +csv +CTable +CTest +ctx +cURL +datatype +datatypes +datumgrid +decimalyear +decimalyears +defmodel +encodings +endian +errno +formatter +Fortran +frontend +gcc +geodata +geoidgrids +geojson +GFortran +gridshift +gridshifts +gridshifting +gtx +hardcoded +hgridshift +Homebrew +hpp +html +http +https +init +interoperability +io +JSON +jsonschema +libc +libcurl +libgeotiff +libnetcdf +libsqlite +libtiff +macOS +Makefile +MSVC +multiline +mutex +nadgrids +namespace +namespaces +namespacing +NaN +netCDF +nmake +nodata +noop +northing +nullptr +obj +org +pj +printf +pthreads +quadtree +reStructuredText +runtime +shapefile +Solaris +sourceCRS +sql +sqlite +src +std +stderr +stdin +Struct +struct +structs +Subclassed +subdirectories +subgrid +subgrids +sublicense +subtype +targetCRS +tif +tinshift +typedef +unreferenced +url +util +vcpkg +verticalCRS +vgridshift +xyzgridshift +wget +whitespace +writable +www +yyyymmdd diff --git a/docs/source/usage/differences.rst b/docs/source/usage/differences.rst index 11bab0b5..3bc2f54d 100644 --- a/docs/source/usage/differences.rst +++ b/docs/source/usage/differences.rst @@ -62,10 +62,10 @@ the old behavior. Version 6.0.0 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Removal of proj_def.dat ------------------------ +Removal of :file:`proj_def.dat` +------------------------------- -Before PROJ 6, the ``proj_def.dat`` was used to provide general and per-projection +Before PROJ 6, the :file:`proj_def.dat` was used to provide general and per-projection parameters, when ``+no_defs`` was not specified. It has now been removed. In case, no ellipsoid or datum specification is provided in the PROJ string, the default ellipsoid is GRS80 (was WGS84 in previous PROJ versions). @@ -121,8 +121,8 @@ Version 6.3.0 projinfo -------- -Before PROJ 6.3.0, WKT1:GDAL was implicitly calling --boundcrs-to-wgs84, to -add a TOWGS84[] node in some cases. This is no longer the case. +Before PROJ 6.3.0, WKT1:GDAL was implicitly calling ``--boundcrs-to-wgs84``, to +add a ``TOWGS84[]`` node in some cases. This is no longer the case. Version 7.0.0 diff --git a/docs/source/usage/environmentvars.rst b/docs/source/usage/environmentvars.rst index 0717a9fa..26765071 100644 --- a/docs/source/usage/environmentvars.rst +++ b/docs/source/usage/environmentvars.rst @@ -23,7 +23,7 @@ On windows systems environment variables can be set in the command line with:: > set VAR="some variable" -```VAR`` will be available for the entire session, unless it is unset. This is +``VAR`` will be available for the entire session, unless it is unset. This is done by setting the variable with no content:: > set VAR= @@ -42,7 +42,7 @@ done by setting the variable with no content:: installation root) and the current folder. You can also set the location of the resource files using - :func:`proj_context_set_search_paths` in the `proj.h` API header. + :func:`proj_context_set_search_paths` in the :file:`proj.h` API header. .. versionchanged:: 6.1.0 @@ -54,7 +54,7 @@ done by setting the variable with no content:: .. envvar:: PROJ_DEBUG Set the debug level of PROJ. The default debug level is zero, which results - in no debug output when using PROJ. A number from 1-3, whit 3 being the most + in no debug output when using PROJ. A number from 1-3, with 3 being the most verbose setting. .. envvar:: PROJ_NETWORK @@ -70,8 +70,8 @@ done by setting the variable with no content:: .. versionadded:: 7.0.0 - Define the endpoint of the CDN storage. Normally defined through the proj.ini - configuration file locale in :envvar:`PROJ_LIB`. + Define the endpoint of the CDN storage. Normally defined through the + :file:`proj.ini` configuration file locale in :envvar:`PROJ_LIB`. Alternatively, the :c:func:`proj_context_set_url_endpoint` function can be used. @@ -79,6 +79,6 @@ done by setting the variable with no content:: .. versionadded:: 7.2.0 - Define a custum path to the CA Bundle file. This can be useful if `curl` + Define a custom path to the CA Bundle file. This can be useful if `curl` and :envvar:`PROJ_NETWORK` are enabled. Alternatively, the :c:func:`proj_curl_set_ca_bundle_path` function can be used. diff --git a/docs/source/usage/network.rst b/docs/source/usage/network.rst index c89a5960..37a32d34 100644 --- a/docs/source/usage/network.rst +++ b/docs/source/usage/network.rst @@ -34,9 +34,9 @@ the user authorizes network access. Authorizing network access can be done in multiple ways: - enabling / uncommenting the ``network = on`` line of :ref:`proj-ini` - - definiting the :envvar:`PROJ_NETWORK` environment variable to ON + - defining the :envvar:`PROJ_NETWORK` environment variable to ON - or using the :cpp:func:`proj_context_set_enable_network` with a - ``enabled`` = TRUE value. + ``enabled = TRUE`` value. .. note:: @@ -59,7 +59,7 @@ Caching ------- To avoid repeated access to network, a local cache of downloaded chunks of grids -is implemented as SQLite3 database, ``cache.db``, stored in the +is implemented as SQLite3 database, :file:`cache.db`, stored in the :ref:`PROJ user writable directory <user_writable_directory>`. This local caching is enabled by default (can be changed in :ref:`proj-ini` or diff --git a/docs/source/usage/projections.rst b/docs/source/usage/projections.rst index 464451c9..1f2e504f 100644 --- a/docs/source/usage/projections.rst +++ b/docs/source/usage/projections.rst @@ -42,23 +42,23 @@ Units +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Horizontal units can be specified using the ``+units`` keyword with a symbolic -name for a unit (ie. ``us-ft``). Alternatively the translation to meters can be -specified with the ``+to_meter`` keyword (ie. 0.304800609601219 for US feet). The -``-lu`` argument to ``cs2cs`` or ``proj`` can be used to list symbolic unit names. -The default unit for projected coordinates is the meter. +name for a unit (i.e. ``us-ft``). Alternatively the translation to meters can be +specified with the ``+to_meter`` keyword (i.e. 0.304800609601219 for US feet). The +``-lu`` argument to :program:`cs2cs` or :program:`proj` can be used to list +symbolic unit names. The default unit for projected coordinates is the meter. A few special projections deviate from this behavior, most notably the latlong pseudo-projection that returns degrees. Vertical (Z) units can be specified using the ``+vunits`` keyword with a -symbolic name for a unit (ie. ``us-ft``). Alternatively the translation to -meters can be specified with the ``+vto_meter`` keyword (ie. 0.304800609601219 -for US feet). The ``-lu`` argument to ``cs2cs`` or ``proj`` can be used to list -symbolic unit names. If no vertical units are specified, the vertical units will -default to be the same as the horizontal coordinates. +symbolic name for a unit (i.e. ``us-ft``). Alternatively the translation to +meters can be specified with the ``+vto_meter`` keyword (i.e. 0.304800609601219 +for US feet). The ``-lu`` argument to :program:`cs2cs` or :program:`proj` can +be used to list symbolic unit names. If no vertical units are specified, the +vertical units will default to be the same as the horizontal coordinates. .. note:: - ``proj`` do not handle vertical units at all and hence the ``+vto_meter`` - argument will be ignored. + :program:`proj` does not handle vertical units at all and hence the + ``+vto_meter`` argument will be ignored. Scaling of output units can be done by applying the ``+k_0`` argument. The returned coordinates are scaled by the value assigned with the ``+k_0`` @@ -97,8 +97,8 @@ name, or the longitude of the alternative prime meridian relative to greenwich. 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 ``cs2cs`` does honour prime meridians but the -``proj`` user utility ignores them. +Consequently the user utility :program:`cs2cs` does honour prime meridians but +the :program:`proj` user utility ignores them. The following predeclared prime meridian names are supported. These can be listed using with ``cs2cs -lm``. @@ -157,7 +157,7 @@ They can be combined in +axis in forms like: .. note:: - The ``+axis`` argument does not work with the ``proj`` command line + The ``+axis`` argument does not work with the :program:`proj` command line utility. diff --git a/docs/source/usage/quickstart.rst b/docs/source/usage/quickstart.rst index 89ac2172..85e7aa95 100644 --- a/docs/source/usage/quickstart.rst +++ b/docs/source/usage/quickstart.rst @@ -26,16 +26,16 @@ projection in PROJ is identified by a shorthand such as ``merc`` in the above example. By using the above projection definition as parameters for the command line -utility ``proj`` we can convert the geodetic coordinates to projected space: +utility :program:`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 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: +If called as above :program:`proj` will be in interactive mode, letting you +type the input data manually and getting a response presented on screen. +:program:`proj` works as any UNIX filter though, which means that you can also +pipe data to the utility, for instance by using the :program:`echo` command: :: @@ -43,9 +43,10 @@ the utility, for instance by using the ``echo`` command: 3399483.80 752085.60 -PROJ also comes bundled with the ``cs2cs`` utility which is used to transform -from one coordinate reference system to another. Say we want to convert -the above Mercator coordinates to UTM, we can do that with ``cs2cs``: +PROJ also comes bundled with the :program:`cs2cs` utility which is used to +transform from one coordinate reference system to another. Say we want to +convert the above Mercator coordinates to UTM, we can do that with +:program:`cs2cs`: :: @@ -56,7 +57,7 @@ Notice the ``+to`` parameter that separates the source and destination projection definitions. If you happen to know the EPSG identifiers for the two coordinates reference -systems you are transforming between you can use those with ``cs2cs``: +systems you are transforming between you can use those with :program:`cs2cs`: :: diff --git a/docs/source/usage/transformation.rst b/docs/source/usage/transformation.rst index 1f29126e..785ca65e 100644 --- a/docs/source/usage/transformation.rst +++ b/docs/source/usage/transformation.rst @@ -187,7 +187,7 @@ In contrast to the *transformation pipeline* framework, transformations with the *cs2cs* framework in PROJ 4 and 5 were expressed as two separate proj-strings. One proj-string *to* WGS84 and one *from* WGS84. Together they form the mapping from the source coordinate reference system to the destination coordinate reference system. -When used with the ``cs2cs`` the source and destination CRS's are separated by the +When used with the :program:`cs2cs` the source and destination CRS's are separated by the special ``+to`` parameter. The following example demonstrates converting from the Greek GGRS87 datum @@ -249,8 +249,8 @@ at each grid location. Actually grid shifts are normally computed based on an interpolation between the containing four grid points. PROJ supports use of grid files for shifting between various reference frames. -The grid shift table formats are ctable, NTv1 (the old Canadian format), and NTv2 (``.gsb`` - the new -Canadian and Australian format). +The grid shift table formats are CTable, NTv1 (the old Canadian format), and NTv2 +(:file:`.gsb` - the new Canadian and Australian format). The text in this section is based on the *cs2cs* framework. Gridshifting is off course also possible with the *pipeline* framework. The major difference between the @@ -258,7 +258,7 @@ two is that the *cs2cs* framework is limited to grid mappings to WGS84, whereas *transformation pipelines* it is possible to perform grid shifts between any two reference frames, as long as a grid exists. -Use of grid shifts with ``cs2cs`` is specified using the ``+nadgrids`` +Use of grid shifts with :program:`cs2cs` is specified using the ``+nadgrids`` keyword in a coordinate system definition. For example: :: @@ -269,7 +269,7 @@ keyword in a coordinate system definition. For example: EOF 111d0'2.952"W 50d0'0.111"N 0.000 -In this case the ``/usr/local/share/proj/ntv1_can.dat`` grid shift file was +In this case the :file:`/usr/local/share/proj/ntv1_can.dat` grid shift file was loaded, and used to get a grid shift value for the selected point. It is possible to list multiple grid shift files, in which case each will be @@ -291,8 +291,8 @@ Skipping Missing Grids The special prefix ``@`` 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. +:file:`ntv2_0.gsb` file if available, otherwise it would +fallback to using the :file:`ntv1_can.dat` file. :: @@ -305,7 +305,7 @@ fallback to using the ``ntv1_can.dat`` file. The null Grid ................................................................................ -A special ``null`` grid shift file is distributed with PROJ. +A special :file:`null` grid shift file is distributed with PROJ. 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 @@ -332,7 +332,7 @@ For more information see the chapter on :ref:`transformation_grids`. Caveats ................................................................................ -* Where grids overlap (such as conus and ntv1_can.dat for instance) the first +* Where grids overlap (such as conus and :file:`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 diff --git a/include/proj/io.hpp b/include/proj/io.hpp index 2f935a0c..672032d0 100644 --- a/include/proj/io.hpp +++ b/include/proj/io.hpp @@ -661,7 +661,7 @@ class PROJ_GCC_DLL IPROJStringExportable { * <li>For PROJStringFormatter::Convention::PROJ_4, format a string * compatible with the OGRSpatialReference::exportToProj4() of GDAL * <=2.3. It is only compatible of a few CRS objects. The PROJ string - * will also contain a +type=crs parameter to disambiguish the nature of + * will also contain a +type=crs parameter to disambiguate the nature of * the string from a CoordinateOperation. * <ul> * <li>For a crs::GeographicCRS, returns a proj=longlat string, with @@ -741,7 +741,7 @@ PROJ_DLL util::BaseObjectNNPtr createFromUserInput(const std::string &text, // --------------------------------------------------------------------------- -/** \brief Parse a WKT string into the appropriate suclass of util::BaseObject. +/** \brief Parse a WKT string into the appropriate subclass of util::BaseObject. */ class PROJ_GCC_DLL WKTParser { public: @@ -784,7 +784,7 @@ class PROJ_GCC_DLL WKTParser { // --------------------------------------------------------------------------- -/** \brief Parse a PROJ string into the appropriate suclass of util::BaseObject. +/** \brief Parse a PROJ string into the appropriate subclass of util::BaseObject. */ class PROJ_GCC_DLL PROJStringParser { public: diff --git a/src/iso19111/c_api.cpp b/src/iso19111/c_api.cpp index 3476402f..10b65ac1 100644 --- a/src/iso19111/c_api.cpp +++ b/src/iso19111/c_api.cpp @@ -268,7 +268,7 @@ PJ_OBJ_LIST::~PJ_OBJ_LIST() = default; // --------------------------------------------------------------------------- /** \brief Set if the database must be closed after each C API call where it - * has been openeded, and automatically re-openeded when needed. + * has been opened, and automatically re-opened when needed. * * The default value is FALSE, that is the database remains open until the * context is destroyed. @@ -7292,7 +7292,7 @@ int proj_coordoperation_get_param( * difference terms might be zero if the transformation only includes * translation * parameters. In that case, value_count could be set to 3. - * @param emit_error_if_incompatible Boolean to inicate if an error must be + * @param emit_error_if_incompatible Boolean to indicate if an error must be * logged if coordoperation is not compatible with a WKT1 TOWGS84 * representation. * @return TRUE in case of success, or FALSE if coordoperation is not @@ -7765,7 +7765,7 @@ void proj_operation_factory_context_set_use_proj_alternative_grid_names( * The current implementation is limited to researching one intermediate * step. * - * By default, with the IF_NO_DIRECT_TRANSFORMATION stratgey, all potential + * By default, with the IF_NO_DIRECT_TRANSFORMATION strategy, all potential * C candidates will be used if there is no direct transformation. * * @param ctx PROJ context, or NULL for default context diff --git a/src/iso19111/coordinatesystem.cpp b/src/iso19111/coordinatesystem.cpp index 2bfe30e6..498e3035 100644 --- a/src/iso19111/coordinatesystem.cpp +++ b/src/iso19111/coordinatesystem.cpp @@ -1108,7 +1108,7 @@ CartesianCSNNPtr CartesianCS::createSouthPoleEastingNorthNorthingNorth( /** \brief Instantiate a CartesianCS with the three geocentric axes. * - * @param unit Liinear unit of the axes. + * @param unit Linear unit of the axes. * @return a new CartesianCS. */ CartesianCSNNPtr diff --git a/src/iso19111/factory.cpp b/src/iso19111/factory.cpp index 3c93803e..c34ef220 100644 --- a/src/iso19111/factory.cpp +++ b/src/iso19111/factory.cpp @@ -1618,7 +1618,7 @@ AuthorityFactory::AuthorityFactory(const DatabaseContextNNPtr &context, * where createFromCoordinateReferenceSystemCodes(const std::string&,const std::string&,const std::string&,const std::string&) const * is called. * - * @param context Contexte. + * @param context Context. * @param authorityName Authority name. * @return new AuthorityFactory. */ @@ -3806,7 +3806,7 @@ AuthorityFactory::createFromCoordinateReferenceSystemCodes( * The list is ordered with preferred operations first. No attempt is made * at inferring operations that are not explicitly in the database (see * createFromCRSCodesWithIntermediates() for that), and only - * source -> target operations are searched (ie if target -> source is present, + * source -> target operations are searched (i.e. if target -> source is present, * you need to call this method with the arguments reversed, and apply the * reverse transformations). * @@ -4211,7 +4211,7 @@ static bool useIrrelevantPivot(const operation::CoordinateOperationNNPtr &op, * * Deprecated operations are rejected. * - * The method will take care of considering all potential combinations (ie + * The method will take care of considering all potential combinations (i.e. * contrary to createFromCoordinateReferenceSystemCodes(), you do not need to * call it with sourceCRS and targetCRS switched) * @@ -5810,7 +5810,7 @@ std::list<AuthorityFactory::UnitInfo> AuthorityFactory::getUnitList() const { * @param source Source of the alias. Can help in case of ambiguities. * Or empty otherwise. * @param tryEquivalentNameSpelling whether the comparison of aliasedName with - * the alt_name column of the alis_name table should be done with using + * the alt_name column of the alias_name table should be done with using * metadata::Identifier::isEquivalentName() rather than strict string * comparison; * @param outTableName Table name in which the official name has been found. diff --git a/src/iso19111/io.cpp b/src/iso19111/io.cpp index 51162365..3ae3da0c 100644 --- a/src/iso19111/io.cpp +++ b/src/iso19111/io.cpp @@ -6573,7 +6573,7 @@ static BaseObjectNNPtr createFromUserInput(const std::string &text, * <ul> * <li>WKT string</li> * <li>PROJ string</li> - * <li>database code, prefixed by its authoriy. e.g. "EPSG:4326"</li> + * <li>database code, prefixed by its authority. e.g. "EPSG:4326"</li> * <li>OGC URN. e.g. "urn:ogc:def:crs:EPSG::4326", * "urn:ogc:def:coordinateOperation:EPSG::1671", * "urn:ogc:def:ellipsoid:EPSG::7001" @@ -6624,7 +6624,7 @@ BaseObjectNNPtr createFromUserInput(const std::string &text, * <ul> * <li>WKT string</li> * <li>PROJ string</li> - * <li>database code, prefixed by its authoriy. e.g. "EPSG:4326"</li> + * <li>database code, prefixed by its authority. e.g. "EPSG:4326"</li> * <li>OGC URN. e.g. "urn:ogc:def:crs:EPSG::4326", * "urn:ogc:def:coordinateOperation:EPSG::1671", * "urn:ogc:def:ellipsoid:EPSG::7001" diff --git a/src/iso19111/operation/concatenatedoperation.cpp b/src/iso19111/operation/concatenatedoperation.cpp index a1c0dca8..4f5dd885 100644 --- a/src/iso19111/operation/concatenatedoperation.cpp +++ b/src/iso19111/operation/concatenatedoperation.cpp @@ -417,7 +417,7 @@ void ConcatenatedOperation::fixStepsDirection( * extent * * @param operationsIn Vector of the CoordinateOperation steps. - * @param checkExtent Whether we should check the non-emptyness of the + * @param checkExtent Whether we should check the non-emptiness of the * intersection * of the extents of the operations * @throws InvalidOperation diff --git a/src/iso19111/operation/coordinateoperationfactory.cpp b/src/iso19111/operation/coordinateoperationfactory.cpp index 39e9bdde..cf33fa3c 100644 --- a/src/iso19111/operation/coordinateoperationfactory.cpp +++ b/src/iso19111/operation/coordinateoperationfactory.cpp @@ -377,7 +377,7 @@ CoordinateOperationContext::getGridAvailabilityUse() const { * The current implementation is limited to researching one intermediate * step. * - * By default, with the IF_NO_DIRECT_TRANSFORMATION stratgey, all potential + * By default, with the IF_NO_DIRECT_TRANSFORMATION strategy, all potential * C candidates will be used if there is no direct transformation. */ void CoordinateOperationContext::setAllowUseIntermediateCRS( diff --git a/src/iso19111/operation/transformation.cpp b/src/iso19111/operation/transformation.cpp index da68ffa6..8b822d51 100644 --- a/src/iso19111/operation/transformation.cpp +++ b/src/iso19111/operation/transformation.cpp @@ -366,7 +366,7 @@ TransformationNNPtr Transformation::create( // --------------------------------------------------------------------------- -/** \brief Instantiate a transformation ands its OperationMethod. +/** \brief Instantiate a transformation and its OperationMethod. * * @param propertiesTransformation The \ref general_properties of the * Transformation. diff --git a/src/iso19111/static.cpp b/src/iso19111/static.cpp index d099cd6c..20c61203 100644 --- a/src/iso19111/static.cpp +++ b/src/iso19111/static.cpp @@ -363,7 +363,7 @@ const UnitOfMeasure UnitOfMeasure::ARC_SECOND_PER_YEAR( "arc-seconds per year", M_PI / 180. / 3600. / 31556925.445, UnitOfMeasure::Type::ANGULAR, Identifier::EPSG, "1043"); -/** \brief Part-sper-million per year, unit of measure of type SCALE. */ +/** \brief Parts-per-million per year, unit of measure of type SCALE. */ const UnitOfMeasure UnitOfMeasure::PPM_PER_YEAR("parts per million per year", 1e-6 / 31556925.445, UnitOfMeasure::Type::SCALE, @@ -1028,7 +1028,7 @@ typedef struct * proj_create_from_database() and other functions in that section * will have generally minimal interaction with the functions declared in the * upper section of this header file (calling those functions on those objects - * will either return an error or default/non-sensical values). The exception is + * will either return an error or default/nonsensical values). The exception is * for ISO19111 objects of type CoordinateOperation that can be exported as a * valid PROJ pipeline. In this case, the PJ objects will work for example with * proj_trans_generic(). diff --git a/test/postinstall/test_pkg-config.sh b/test/postinstall/test_pkg-config.sh index f9ae36c2..83b09582 100755 --- a/test/postinstall/test_pkg-config.sh +++ b/test/postinstall/test_pkg-config.sh @@ -11,7 +11,7 @@ echo "Running post-install tests with pkg-config" prefix=$1 if [ -z "$prefix" ]; then - echo "First positional argument to the the installed prefix is required" + echo "First positional argument to the installed prefix is required" exit 1 fi diff --git a/test/unit/test_io.cpp b/test/unit/test_io.cpp index 2d035e43..36ec9c75 100644 --- a/test/unit/test_io.cpp +++ b/test/unit/test_io.cpp @@ -10504,7 +10504,7 @@ TEST(io, createFromUserInput) { ParsingException); { - // Completely non-sensical from a geodesic point of view... + // Completely nonsensical from a geodesic point of view... auto obj = createFromUserInput("urn:ogc:def:crs,crs:EPSG::4978," "cs:EPSG::6500," "coordinateOperation:EPSG::16031", @@ -10516,7 +10516,7 @@ TEST(io, createFromUserInput) { EXPECT_EQ(crs->derivingConversion()->getEPSGCode(), 16031); } { - // Completely non-sensical from a geodesic point of view... + // Completely nonsensical from a geodesic point of view... auto obj = createFromUserInput("urn:ogc:def:crs,crs:EPSG::4979," "cs:EPSG::6423," "coordinateOperation:EPSG::16031", @@ -10528,7 +10528,7 @@ TEST(io, createFromUserInput) { EXPECT_EQ(crs->derivingConversion()->getEPSGCode(), 16031); } { - // Completely non-sensical from a geodesic point of view... + // Completely nonsensical from a geodesic point of view... auto obj = createFromUserInput("urn:ogc:def:crs,crs:EPSG::32631," "cs:EPSG::4400," "coordinateOperation:EPSG::16031", diff --git a/test/unit/test_operationfactory.cpp b/test/unit/test_operationfactory.cpp index 20ef4ba8..d8723434 100644 --- a/test/unit/test_operationfactory.cpp +++ b/test/unit/test_operationfactory.cpp @@ -2990,7 +2990,7 @@ TEST(operation, transformation_VERTCON_to_PROJ_string) { PropertyMap(), VerticalReferenceFrame::create(PropertyMap()), VerticalCS::createGravityRelatedHeight(UnitOfMeasure::METRE)); - // Use of this type of transformation is a bit of non-sense here + // Use of this type of transformation is a bit of nonsense here // since it should normally be used with NGVD29 and NAVD88 for VerticalCRS, // and NAD27/NAD83 as horizontal CRS... auto vtransformation = Transformation::createVERTCON( @@ -3770,7 +3770,7 @@ TEST(operation, compoundCRS_to_compoundCRS_with_vertical_transform) { PropertyMap(), VerticalReferenceFrame::create(PropertyMap()), VerticalCS::createGravityRelatedHeight(UnitOfMeasure::METRE)); - // Use of this type of transformation is a bit of non-sense here + // Use of this type of transformation is a bit of nonsense here // since it should normally be used with NGVD29 and NAVD88 for VerticalCRS, // and NAD27/NAD83 as horizontal CRS... auto vtransformation = Transformation::createVERTCON( |