diff options
Diffstat (limited to 'docs/source')
25 files changed, 111 insertions, 111 deletions
diff --git a/docs/source/contributing.rst b/docs/source/contributing.rst index e7f9101e..5e198ae7 100644 --- a/docs/source/contributing.rst +++ b/docs/source/contributing.rst @@ -4,13 +4,13 @@ Contributing =========================== -PROJ.4 has a wide and varied user base. Some are highly skilled +PROJ has a wide and varied user base. Some are highly skilled geodesists with a deep knowledge of map projections and reference systems, some are GIS software developers and others are GIS users. All users, regardless of the profession or skill level, has the ability to -contribute to PROJ.4. Here's a few suggestion on how: +contribute to PROJ. Here's a few suggestion on how: -- Help PROJ.4-users that is less experienced than yourself. +- Help PROJ-users that is less experienced than yourself. - Write a bug report - Request a new feature - Write documentation for your favorite map projection @@ -18,20 +18,20 @@ contribute to PROJ.4. Here's a few suggestion on how: - Implement a new feature In the following sections you can find some guidelines on how to -contribute. As PROJ.4 is managed on GitHub most contributions require +contribute. As PROJ is managed on GitHub most contributions require that you have a GitHub account. Familiarity with `issues <https://guides.github.com/features/issues/>`__ and the `GitHub Flow <https://guides.github.com/introduction/flow/>`__ is an advantage. -Help a fellow PROJ.4 user +Help a fellow PROJ user ------------------------- -The main forum for support for PROJ.4 is the mailing list. You can +The main forum for support for PROJ is the mailing list. You can subscribe to the mailing list `here <http://lists.maptools.org/mailman/listinfo/proj>`__ and read the archive `here <http://lists.maptools.org/pipermail/proj/>`__. -If you have questions about the usage of PROJ.4 the mailing list is also +If you have questions about the usage of PROJ the mailing list is also the place to go. Please *do not* use the GitHub issue tracker as a support forum. Your question is much more likely to be answered on the mailing list, as many more people follow that than the issue tracker. @@ -40,7 +40,7 @@ Adding bug reports ------------------ Bug reports are handled in the `issue -tracker <https://github.com/OSGeo/proj.4/issues>`__ on PROJ.4's home on +tracker <https://github.com/OSGeo/proj.4/issues>`__ on PROJ's home on GitHub. Writing a good bug report is not easy. But fixing a poorly documented bug is not easy either, so please put in the effort it takes to create a thorough bug report. @@ -49,7 +49,7 @@ A good bug report includes at least: - A title that quickly explains the problem - A description of the problem and how it can be reproduced -- Version of PROJ.4 being used +- Version of PROJ being used - Version numbers of any other relevant software being used, e.g. operating system - A description of what already has been done to solve the problem @@ -61,16 +61,16 @@ them in a timely manner if you have an interest in getting the issue solved. Finally, please only submit bug reports that are actually related to -PROJ.4. If the issue materializes in software that uses PROJ.4 it is +PROJ. If the issue materializes in software that uses PROJ it is likely a problem with that particular software. Make sure that it -actually is a PROJ.4 problem before you submit an issue. If you can -reproduce the problem only by using tools from PROJ.4 it is definitely a -problem with PROJ.4. +actually is a PROJ problem before you submit an issue. If you can +reproduce the problem only by using tools from PROJ it is definitely a +problem with PROJ. Feature requests ---------------- -Got an idea for a new feature in PROJ.4? Submit a thorough description +Got an idea for a new feature in PROJ? Submit a thorough description of the new feature in the `issue tracker <https://github.com/OSGeo/proj.4/issues>`__. Please include any technical documents that can help the developer make the new feature a @@ -84,14 +84,14 @@ Note that not all feature requests are accepted. Write documentation ------------------- -PROJ.4 is in dire need of better documentation. Any contributiions of -documentation are greatly appreaciated. The PROJ.4 documentation is +PROJ is in dire need of better documentation. Any contributiions of +documentation are greatly appreaciated. The PROJ documentation is available on `proj4.org <ttp://proj4.org>`__. The website is generated with `Sphinx <http://www.sphinx-doc.org/en/stable/>`__. Contributions to the documentation should be made as `Pull Requests <https://github.com/OSGeo/proj.4/pulls>`__ on GitHub. -If you intend to document one of PROJ.4's supported projections please +If you intend to document one of PROJ's supported projections please use the `Mercator projection <http://proj4.org/projections/merc.html>`__ as a template. @@ -120,7 +120,7 @@ Submitting Changes ~~~~~~~~~~~~~~~~~~ - Push your changes to a topic branch in your fork of the repository. -- Submit a pull request to the PROJ.4 repository in the OSGeo +- Submit a pull request to the PROJ repository in the OSGeo organization. - If your pull request fixes/references an issue, include that issue number in the pull request. For example: @@ -131,7 +131,7 @@ Submitting Changes Fixes #123. -- PROJ.4 developers will look at your patch and take an appropriate +- PROJ developers will look at your patch and take an appropriate action. Coding conventions @@ -140,7 +140,7 @@ Coding conventions Programming language ^^^^^^^^^^^^^^^^^^^^ -PROJ.4 is developed strictly in ANSI C 89. +PROJ is developed strictly in ANSI C 89. Coding style ^^^^^^^^^^^^ @@ -152,7 +152,7 @@ with the style of the locally surrounding code. Whitespace ^^^^^^^^^^ -Throughout the PROJ.4 code base you will see differing whitespace use. +Throughout the PROJ code base you will see differing whitespace use. The general rule is to keep whitespace in whatever form it is in the file you are currently editing. If the file has a mix of tabs and space please convert the tabs to space in a separate commit before making any @@ -166,14 +166,14 @@ File names Files in which projections are implemented are prefixed with an upper-case ``PJ_`` and most other files are prefixed with lower-case ``pj_``. Some file deviate from this pattern, most of them dates back to -the very early releases of PROJ.4. New contributions should follow the +the very early releases of PROJ. New contributions should follow the pj-prefix pattern. Unless there are obvious reasons not to. Legalese ~~~~~~~~ Commiters are the front line gatekeepers to keep the code base clear of -improperly contributed code. It is important to the PROJ.4 users, +improperly contributed code. It is important to the PROJ users, developers and the OSGeo foundation to avoid contributing any code to the project without it being clearly licensed under the project license. diff --git a/docs/source/development/bindings.rst b/docs/source/development/bindings.rst index 80babcb2..3fac1869 100644 --- a/docs/source/development/bindings.rst +++ b/docs/source/development/bindings.rst @@ -4,40 +4,40 @@ Language bindings ******************************************************************************** -PROJ.4 bindings are available for a number of different development platforms. +PROJ bindings are available for a number of different development platforms. Python ====== `pyproj <http://pypi.python.org/pypi/pyproj>`_: -Python interface (wrapper for PROJ.4) +Python interface (wrapper for PROJ) Ruby ======= `proj4rb <http://proj4rb.rubyforge.org>`_: -Bindings for PROJ.4 in ruby +Bindings for PROJ in ruby TCL ======== `proj4tcl <http://wiki.tcl.tk/41270>`_: -Bindings for PROJ.4 in tcl (critcl source) +Bindings for PROJ in tcl (critcl source) MySQL ===== `fProj4 <http://sourceforge.net/projects/mysqlscientific/files/fPROJ4/>`_: -Bindings for PROJ.4 in MySQL +Bindings for PROJ in MySQL Excel ======== `proj.xll <https://github.com/jbuonagurio/proj.xll>`_: -Excel add-in for PROJ.4 map projections +Excel add-in for PROJ map projections Visual Basic ================== -`PROJ.4 VB Wrappers <http://ftp.dfg.ca.gov/Public/BDB/Tools/proj4/proj_api.zip>`_: +`PROJ VB Wrappers <http://ftp.dfg.ca.gov/Public/BDB/Tools/proj4/proj_api.zip>`_: By Eric G. Miller. diff --git a/docs/source/development/cmake.rst b/docs/source/development/cmake.rst index 1429ae88..5a8ce624 100644 --- a/docs/source/development/cmake.rst +++ b/docs/source/development/cmake.rst @@ -1,10 +1,10 @@ .. _cmake: ******************************************************************************** -Using Proj.4 in CMake projects +Using PROJ in CMake projects ******************************************************************************** -The recommended way to use the Proj.4 library in a CMake project is to +The recommended way to use the PROJ library in a CMake project is to link to the imported library target ``${PROJ4_LIBRARIES}`` provided by the CMake configuration which comes with the library. Typical usage is: diff --git a/docs/source/development/index.rst b/docs/source/development/index.rst index 743224a6..3f8a7bf6 100644 --- a/docs/source/development/index.rst +++ b/docs/source/development/index.rst @@ -5,7 +5,7 @@ Development ================================================================================ These pages are primarily focused towards developers either contributing to the -PROJ.4 project or using the library in their own software. +PROJ project or using the library in their own software. .. toctree:: diff --git a/docs/source/development/quickstart.rst b/docs/source/development/quickstart.rst index 7137d85a..960cddbf 100644 --- a/docs/source/development/quickstart.rst +++ b/docs/source/development/quickstart.rst @@ -4,15 +4,15 @@ Quick start ================================================================================ -This is a short introduction to the PROJ.4 API. In the following section we +This is a short introduction to the PROJ API. In the following section we create a simple program that transforms a geodetic coordinate to UTM and back again. The program is explained a few lines at a time. The complete program can be seen at the end of the section. See the following sections for more in-depth descriptions of different parts of -the PROJ.4 API or consult the :doc:`API reference <reference/index>` for specifics. +the PROJ API or consult the :doc:`API reference <reference/index>` for specifics. -Before the PROJ.4 API can be used it is necessary to include the ``proj.h`` header +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: .. literalinclude:: ../../../examples/pj_obs_api_mini_demo.c @@ -54,10 +54,10 @@ details. :lines: 50-52 :dedent: 4 -PROJ.4 uses it's own data structures for handling coordinates. Here we use a +PROJ uses it's own data structures for handling coordinates. Here we use a ``PJ_COORD`` which is easily assigned with the function ``proj_coord``. Note that the input values are converted to radians with ``proj_torad``. This is -necessary since PROJ.4 is using radians internally. See :doc:`transformations` +necessary since PROJ is using radians internally. See :doc:`transformations` for further details. .. literalinclude:: ../../../examples/pj_obs_api_mini_demo.c diff --git a/docs/source/development/threads.rst b/docs/source/development/threads.rst index a557fa07..674f4bd1 100644 --- a/docs/source/development/threads.rst +++ b/docs/source/development/threads.rst @@ -4,7 +4,7 @@ Threads ================================================================================ -This page is about efforts to make PROJ.4 thread safe. +This page is about efforts to make PROJ thread safe. Key Thread Safety Issues -------------------------------------------------------------------------------- @@ -14,14 +14,14 @@ Key Thread Safety Issues introduction of the projCtx execution context. * the datum shift using grid files uses globally shared lists of loaded grid information. Access to this has been made safe in 4.7.0 with the introduction - of a proj.4 mutex used to protect access to these memory structures (see + of a PROJ mutex used to protect access to these memory structures (see pj_mutex.c). projCtx -------------------------------------------------------------------------------- Primarily in order to avoid having pj_errno as a global variable, a "thread -context" structure has been introduced into a variation of the PROJ.4 API for +context" structure has been introduced into a variation of the PROJ API for the 4.8.0 release. The pj_init() and pj_init_plus() functions now have context variations called pj_init_ctx() and pj_init_plus_ctx() which take a projections context. @@ -68,7 +68,7 @@ src/multistresstest.c -------------------------------------------------------------------------------- A small multi-threaded test program has been written (src/multistresstest.c) -for testing multithreaded use of PROJ.4. It performs a series of reprojections +for testing multithreaded use of PROJ. It performs a series of reprojections to setup a table expected results, and then it does them many times in several threads to confirm that the results are consistent. At this time this program is not part of the builds but it can be built on linux like: diff --git a/docs/source/download.rst b/docs/source/download.rst index 4b9cbb92..9afad945 100644 --- a/docs/source/download.rst +++ b/docs/source/download.rst @@ -45,7 +45,7 @@ Linux Docker ................................................................................ -A `Docker`_ image with just PROJ.4 binaries and a full compliment of grid shift +A `Docker`_ image with just PROJ binaries and a full compliment of grid shift files is available on `DockerHub`_: .. _`Docker`: https://docker.org diff --git a/docs/source/faq.rst b/docs/source/faq.rst index 8afdb35d..c508a167 100644 --- a/docs/source/faq.rst +++ b/docs/source/faq.rst @@ -15,7 +15,7 @@ Where can I find the list of projections and their arguments? There is no simple single location to find all the required information. The !PostScript/PDF documents listed on the [http://trac.osgeo.org/proj/wiki main] -PROJ.4 page under documentation are the authoritative source but projections +PROJ page under documentation are the authoritative source but projections and options are spread over several documents in a form more related to their order of implementation than anything else. @@ -25,7 +25,7 @@ units with the '''-lu''' option, and the list of built-in datums with the '''-ld''' option. The [http://www.remotesensing.org/geotiff/proj_list/ GeoTIFF Projections Pages] -include most of the common PROJ.4 projections, and a definition of the +include most of the common PROJ projections, and a definition of the projection specific options for each. * How do I do datum shifts between NAD27 and NAD83? @@ -50,10 +50,10 @@ In order for datum shifting to work properly the various grid shift files must be available. See below. More details are available in the [wiki:GenParms#nadgrids-GridBasedDatumAdjustments General Parameters] document. -How do I build/configure PROJ.4 to support datum shifting? +How do I build/configure PROJ to support datum shifting? -------------------------------------------------------------------------------- -After downloading and unpacking the PROJ.4 source, also download and unpack the +After downloading and unpacking the PROJ source, also download and unpack the set of datum shift files. See :ref:`download` for instructions how to fetch and install these files @@ -61,10 +61,10 @@ On Windows the extra nadshift target must be used. For instance ``nmake /f makefile.vc nadshift`` in the ``proj/src`` directory. A default build and install on Unix will normally build knowledge of the -directory where the grid shift files are installed into the PROJ.4 library +directory where the grid shift files are installed into the PROJ library (usually /usr/local/share/proj). On Windows the library is normally built thinking that C:\PROJ\NAD is the installed directory for the grid shift files. -If the built in concept of the PROJ.4 data directory is incorrect, the ``PROJ_LIB`` +If the built in concept of the PROJ data directory is incorrect, the ``PROJ_LIB`` environment can be defined with the correct directory. How do I debug problems with NAD27/NAD83 datum shifting? @@ -88,7 +88,7 @@ How do I debug problems with NAD27/NAD83 datum shifting? are not identified as having a datum, the datum shifting (and ellipsoid change) step is just quietly skipped! 4. The ``PROJ_DEBUG`` environment can be defined (any value) to force extra output - from the PROJ.4 library to stderr (the text console normally) with + from the PROJ library to stderr (the text console normally) with information on what data files are being opened and in some cases why a transformation fails. @@ -99,17 +99,17 @@ How do I debug problems with NAD27/NAD83 datum shifting? .. note:: - ``PROJ_DEBUG`` support is not yet very mature in the PROJ.4 library. + ``PROJ_DEBUG`` support is not yet very mature in the PROJ library. 5. The ``-v`` flag to cs2cs can be useful in establishing more detail on what parameters being used internally for a coordinate system. This will include expanding the definition of +datum clause. -How do I use EPSG coordinate system codes with PROJ.4? +How do I use EPSG coordinate system codes with PROJ? -------------------------------------------------------------------------------- There is somewhat imperfect translation between 2d geographic and projected -coordinate system codes and PROJ.4 descriptions of the coordinate system +coordinate system codes and PROJ descriptions of the coordinate system available in the epsg definition file that normally lives in the proj/nad directory. If installed (it is installed by default on Unix), it is possible to use EPSG numbers like this: @@ -144,12 +144,12 @@ use is more fully described in the [wiki:GenParms#towgs84-DatumtransformationtoWGS84 towgs84] parameter discussion. -Does PROJ.4 work in different international numeric locales? +Does PROJ work in different international numeric locales? -------------------------------------------------------------------------------- -No. PROJ.4 makes extensive use of sprintf() and atof() internally to translate +No. PROJ makes extensive use of sprintf() and atof() internally to translate numeric values. If a locale is in effect that modifies formatting of numbers, -altering the role of commas and periods in numbers, then PROJ.4 will not work. +altering the role of commas and periods in numbers, then PROJ will not work. This problem is common in some European locales. On unix-like platforms, this problem can be avoided by forcing the use of the @@ -194,7 +194,7 @@ the WGS84 datum which has a quite differently shaped ellipsoid. In this case, and many other cases using spherical projections, the desired approach is to actually treat the lat/long locations on the sphere as if they were on WGS84 without any adjustments when using them for converting to other -coordinate systems. The solution is to "trick" PROJ.4 into applying no change +coordinate systems. The solution is to "trick" PROJ into applying no change to the lat/long values when going to (and through) WGS84. This can be accomplished by asking PROJ to use a null grid shift file for switching from your spherical lat/long coordinates to WGS84. @@ -212,7 +212,7 @@ Similar issues apply with many other datasets distributed with projections based on a spherical earth model - such as many NASA datasets. This coordinate system is now known by the EPSG code 3857 and has in the past been known as EPSG:3785 and EPSG:900913. When using this coordinate system with GDAL/OGR it -is helpful to include the +wktext so the exact PROJ.4 string will be preserved +is helpful to include the +wktext so the exact PROJ string will be preserved in the WKT representation (otherwise key parameters like `+nadgrids=@null` will be dropped): @@ -224,11 +224,11 @@ be dropped): Why do I get different results with 4.5.0 and 4.6.0? -------------------------------------------------------------------------------- -The default datum application behavior changed with the 4.6.0 release. PROJ.4 +The default datum application behavior changed with the 4.6.0 release. PROJ will now only apply a datum shift if both the source and destination coordinate system have valid datum shift information. -From the PROJ.4 4.6.0 Release Notes (in NEWS): +From the PROJ 4.6.0 Release Notes (in NEWS): * MAJOR: Rework pj_transform() to avoid applying ellipsoid to ellipsoid transformations as a datum shift when no datum info is available. @@ -302,7 +302,7 @@ Output of above command: 0 0.7853981633974483 0.00 41.94 -What options does PROJ.4 allow for the shape of the Earth (geodesy)? +What options does PROJ allow for the shape of the Earth (geodesy)? -------------------------------------------------------------------------------- See https://github.com/OSGeo/proj.4/blob/master/src/pj_ellps.c @@ -315,7 +315,7 @@ What if I want a spherical Earth? Use ``+ellps=sphere``. See https://github.com/OSGeo/proj.4/blob/master/src/pj_ellps.c for the radius used in this case. -How do I change the radius of the Earth? How do I use PROJ.4 for work on Mars? +How do I change the radius of the Earth? How do I use PROJ for work on Mars? -------------------------------------------------------------------------------- You can supply explicit values for the semi minor and semi major axes instead diff --git a/docs/source/grids.rst b/docs/source/grids.rst index 4c0bc577..b3a551d7 100644 --- a/docs/source/grids.rst +++ b/docs/source/grids.rst @@ -44,7 +44,7 @@ HARN With the support of `i-cubed <http://www.i-cubed.com>`__, Frank Warmerdam has written tools to translate the HPGN grids from NOAA/NGS from ``.los/.las`` format -into NTv2 format for convenient use with PROJ.4. This project included +into NTv2 format for convenient use with PROJ. This project included implementing a `.los/.las reader <https://github.com/OSGeo/gdal/tree/trunk/gdal/frmts/raw/loslasdataset.cpp>`__ for GDAL, and an `NTv2 reader/writer <https://github.com/OSGeo/gdal/tree/trunk/gdal/frmts/raw/ntv2dataset.cpp>`__. Also, a script to do the bulk translation was implemented in @@ -55,7 +55,7 @@ The command to do the translation was: loslas2ntv2.py -auto *hpgn.los -As GDAL uses NAD83/WGS84 as a pivot datum, the sense of the HPGN datum shift offsets were negated to map from HPGN to NAD83 instead of the other way. The files can be used with PROJ.4 like this: +As GDAL uses NAD83/WGS84 as a pivot datum, the sense of the HPGN datum shift offsets were negated to map from HPGN to NAD83 instead of the other way. The files can be used with PROJ like this: :: @@ -101,7 +101,7 @@ distributed, but can be obtained by users through free and legal methods. Canada NTv2.0 ................................................................................ -Although NTv1 grid shifts are provided freely with PROJ.4, the higher-quality +Although NTv1 grid shifts are provided freely with PROJ, the higher-quality NTv2.0 file needs to be downloaded from Natural Resources Canada. More info: http://www.geod.nrcan.gc.ca/tools-outils/ntv2_e.php. diff --git a/docs/source/htpd.rst b/docs/source/htpd.rst index 2209c865..4007bef6 100644 --- a/docs/source/htpd.rst +++ b/docs/source/htpd.rst @@ -10,8 +10,8 @@ HTPD This page documents use of the `crs2crs2grid.py` script and the HTDP (Horizontal Time Dependent Positioning) grid shift modelling program from -NGS/NOAA to produce PROJ.4 compatible grid shift files for fine grade -conversions between various NAD83 epochs and WGS84. Traditionally PROJ.4 has +NGS/NOAA to produce PROJ compatible grid shift files for fine grade +conversions between various NAD83 epochs and WGS84. Traditionally PROJ has treated NAD83 and WGS84 as equivalent and failed to distinguish between different epochs or realizations of those datums. At the scales of much mapping this is adequate but as interest grows in high resolution imagery and @@ -121,7 +121,7 @@ source and destination date (epoch). For example: crs2crs2grid.py 29 2002.0 8 2002.0 -o nad83_2002.ct2 -The output is a CTable2 format grid shift file suitable for use with PROJ.4 +The output is a CTable2 format grid shift file suitable for use with PROJ (4.8.0 or newer). It might be utilized something like: diff --git a/docs/source/index.rst b/docs/source/index.rst index 324d52fc..88bac738 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -1,13 +1,13 @@ .. _home: ****************************************************************************** -PROJ.4 +PROJ ****************************************************************************** -PROJ.4 is a standard UNIX filter function which converts geographic longitude +PROJ is a standard UNIX filter function which converts geographic longitude and latitude coordinates into cartesian coordinates (and vice versa), and it is a C API for software developers to include coordinate transformation in their -own software. PROJ.4 is maintained on `GitHub <http://github.com/OSGeo/proj.4/>`_. +own software. PROJ is maintained on `GitHub <http://github.com/OSGeo/proj.4/>`_. ============= ================================================================ @@ -49,7 +49,7 @@ Documentation Mailing List ================================================================================ -The PROJ.4 mailing list can be found at http://lists.maptools.org/mailman/listinfo/proj +The PROJ mailing list can be found at http://lists.maptools.org/mailman/listinfo/proj Indices and tables ================== diff --git a/docs/source/usage/apps/index.rst b/docs/source/usage/apps/index.rst index 73c5c63c..0d818682 100644 --- a/docs/source/usage/apps/index.rst +++ b/docs/source/usage/apps/index.rst @@ -4,7 +4,7 @@ Applications ================================================================================ -Bundled with PROJ.4 comes a set of small command line utilities. The +Bundled with PROJ comes a set of small command line utilities. The ``proj`` program is limited to converting between geographic and projection coordinates within one datum. The ``cs2cs`` program operates similarly, but allows translation between any pair of definable coordinate systems, including diff --git a/docs/source/usage/environmentvars.rst b/docs/source/usage/environmentvars.rst index 38cb46de..0d5d06a8 100644 --- a/docs/source/usage/environmentvars.rst +++ b/docs/source/usage/environmentvars.rst @@ -4,7 +4,7 @@ Environment variables ================================================================================ -PROJ.4 can be crontrolled by setting environment variables. Most users will +PROJ can be crontrolled by setting environment variables. Most users will have a use for the :envvar:`PROJ_LIB`. On UNIX systems environment variables can be set for a shell-session with:: @@ -30,14 +30,14 @@ done by setting the variable with no content:: .. envvar:: PROJ_LIB - The location of PROJ.4 :doc:`resource files<resource_files>`. + The location of PROJ :doc:`resource files<resource_files>`. It is only possible to specify a single library in :envvar:`PROJ_LIB`; e.g. it - does not behave like PATH. PROJ.4 is hardcoded to look for resource files + does not behave like PATH. PROJ is hardcoded to look for resource files in other locations as well, amongst those are the users home directory, ``/usr/share/proj`` and the current folder. .. envvar:: PROJ_DEBUG - Set the debug level of PROJ.4. The default debug level is zero, which results - in no debug output when using PROJ.4. A number from 1-3, whit 3 being the most + 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 verbose setting. diff --git a/docs/source/usage/index.rst b/docs/source/usage/index.rst index 81ea4b6b..d59296d0 100644 --- a/docs/source/usage/index.rst +++ b/docs/source/usage/index.rst @@ -1,10 +1,10 @@ .. _usage: ================================================================================ -Using PROJ.4 +Using PROJ ================================================================================ -The main purpose of PROJ.4 is to transform coordinates from one coordinate +The main purpose of PROJ is to transform coordinates from one coordinate reference system to another. This can be achieved either with the included command line applications or the C API that is a part of the software package. diff --git a/docs/source/usage/operations/conversions/index.rst b/docs/source/usage/operations/conversions/index.rst index 54324ec4..af27e2fd 100644 --- a/docs/source/usage/operations/conversions/index.rst +++ b/docs/source/usage/operations/conversions/index.rst @@ -5,7 +5,7 @@ Conversions ================================================================================ Conversions are coordinate operations in which both coordinate reference systems -are based on the same datum. In PROJ.4 projections are differentiated from +are based on the same datum. In PROJ projections are differentiated from conversions. .. toctree:: diff --git a/docs/source/usage/operations/conversions/unitconvert.rst b/docs/source/usage/operations/conversions/unitconvert.rst index ad848207..73e517bd 100644 --- a/docs/source/usage/operations/conversions/unitconvert.rst +++ b/docs/source/usage/operations/conversions/unitconvert.rst @@ -46,7 +46,7 @@ expected to be in units of decimalyears. This can be fixed with `unitconvert`:: Distance units ############################################################################### -In the table below all distance units supported by PROJ.4 is listed. +In the table below all distance units supported by PROJ is listed. The same list can also be produced on the command line with `proj` or `cs2cs`, by adding the `-lu` flag when calling the utility. @@ -100,7 +100,7 @@ by adding the `-lu` flag when calling the utility. Time units ############################################################################### -In the table below all time units supported by PROJ.4 is listed. +In the table below all time units supported by PROJ is listed. +--------------+-----------------------------+ | mjd | Modfied Julian date | diff --git a/docs/source/usage/operations/index.rst b/docs/source/usage/operations/index.rst index d78f8947..87bfdc40 100644 --- a/docs/source/usage/operations/index.rst +++ b/docs/source/usage/operations/index.rst @@ -4,11 +4,11 @@ Coordinate operations ================================================================================ -Coordinate operations in PROJ.4 are divided into three groups: +Coordinate operations in PROJ are divided into three groups: Projections, conversions and transformations. Projections are purely cartographic mappings of the sphere onto the plane. Technically projections are conversions (according to ISO standards), though in -PROJ.4 projections are distinguished from conversions. Conversions are coordinate +PROJ projections are distinguished from conversions. Conversions are coordinate operations that do not exert a change in reference frame. Operations that do exert a change in reference frame are called transformations. diff --git a/docs/source/usage/operations/projections/geos.rst b/docs/source/usage/operations/projections/geos.rst index 3b24e1f7..28b96736 100644 --- a/docs/source/usage/operations/projections/geos.rst +++ b/docs/source/usage/operations/projections/geos.rst @@ -66,7 +66,7 @@ This example represents the scanning geometry of the Meteosat series satellite. However, the GOES satellite series use the opposite scanning geometry, with the E/W axis (``x``) as the sweep-angle axis, and the N/S (``y``) as the fixed-angle axis. -The sweep argument is used to tell PROJ.4 which on which axis the outer-gimbal +The sweep argument is used to tell PROJ which on which axis the outer-gimbal is rotating. The possible values are x or y, y being the default. Thus, the scanning geometry of the Meteosat series satellite should take sweep as x, and GOES should take sweep as y. diff --git a/docs/source/usage/operations/projections/index.rst b/docs/source/usage/operations/projections/index.rst index f7eb0c67..904dc9e6 100644 --- a/docs/source/usage/operations/projections/index.rst +++ b/docs/source/usage/operations/projections/index.rst @@ -5,7 +5,7 @@ Projections ================================================================================ Projections are coordinate operations that are technically conversions but since -projections are so fundamental to PROJ.4 we differentiate them from conversions. +projections are so fundamental to PROJ we differentiate them from conversions. Projections map the spherical 3D space to a flat 2D space. diff --git a/docs/source/usage/operations/transformations/hgridshift.rst b/docs/source/usage/operations/transformations/hgridshift.rst index a9690260..7f3c9895 100644 --- a/docs/source/usage/operations/transformations/hgridshift.rst +++ b/docs/source/usage/operations/transformations/hgridshift.rst @@ -30,7 +30,7 @@ of the continental US, Alaska and Canada is loaded at the same time:: +hgridshift +grids=@conus,@alaska,@ntv2_0.gsb,@ntv_can.dat The ``@`` in the above example states that the grid is optional, in case the grid -is not found in the PROJ.4 search path. The list of grids is prioritized so that +is not found in the PROJ search path. The list of grids is prioritized so that grids in the start of the list takes presedence over the grids in the back of the list. diff --git a/docs/source/usage/operations/transformations/vgridshift.rst b/docs/source/usage/operations/transformations/vgridshift.rst index 31b3e56e..e9f78310 100644 --- a/docs/source/usage/operations/transformations/vgridshift.rst +++ b/docs/source/usage/operations/transformations/vgridshift.rst @@ -32,7 +32,7 @@ the global model:: +vgridshift +grids=@dvr90.gtx,egm96_16.gtx The ``@`` in the above example states that the grid is optional, in case the grid -is not found in the PROJ.4 search path. The list of grids is prioritized so that +is not found in the PROJ search path. The list of grids is prioritized so that grids in the start of the list takes presedence over the grids in the back of the list. diff --git a/docs/source/usage/projections.rst b/docs/source/usage/projections.rst index 8f0b3586..645c1eb1 100644 --- a/docs/source/usage/projections.rst +++ b/docs/source/usage/projections.rst @@ -4,12 +4,12 @@ Cartographic projection ================================================================================ -The foundation of PROJ.4 is the large number of +The foundation of PROJ is the large number of :doc:`projections<operations/projections/index>` available in the library. This section is devoted to the generic parameters that can be used on any projection in the -PROJ.4 library. +PROJ library. -Below is a list of PROJ.4 parameters which can be applied to most coordinate +Below is a list of PROJ parameters which can be applied to most coordinate system definitions. This table does not attempt to describe the parameters particular to particular projection types. These can be found on the pages documenting the individual :doc:`projections<operations/projections/index>`. @@ -76,7 +76,7 @@ systems (such as UTM) have implicit false easting and northing values. Longitude Wrapping +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -By default PROJ.4 wraps output longitudes in the range -180 to 180. The ``+over`` +By default PROJ wraps output longitudes in the range -180 to 180. The ``+over`` switch can be used to disable the default wrapping which is done at a low level in ``pj_inv()``. This is particularly useful with projections like the :doc:`equidistant cylindrical<operations/projections/eqc>` diff --git a/docs/source/usage/quickstart.rst b/docs/source/usage/quickstart.rst index 96bfbba1..2cf66122 100644 --- a/docs/source/usage/quickstart.rst +++ b/docs/source/usage/quickstart.rst @@ -4,7 +4,7 @@ Quick start ================================================================================ -Coordinate transformations are defined by, what in PROJ.4 terminology is +Coordinate transformations are defined by, what in PROJ terminology is known as, "proj-strings". A proj-string describes any transformation regardless of how simple or complicated it might be. The simplest case is projection of geodetic coordinates. This section focuses on the simpler cases and introduces the basic @@ -22,7 +22,7 @@ parameters that applies to the projection and, if needed, a description of a datum shift. In the example above geodetic coordinates are transformed to projected space with the :doc:`Mercator projection<operations/projections/merc>` with the latitude of true scale at 56.5 degrees north on the GRS80 ellipsoid. Every -projection in PROJ.4 is identified by a shorthand such as ``merc`` in the above +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 @@ -43,7 +43,7 @@ the utility, for instance by using the ``echo`` command: 3399483.80 752085.60 -PROJ.4 also comes bundled with the ``cs2cs`` utility which is used to transform +PROJ also comes bundled with the ``cs2cs`` utility which is used to transform from onecoordinate reference system to another. Say we want to convert the above Mercator coordinates to UTM, we can do that with ``cs2cs``: diff --git a/docs/source/usage/resource_files.rst b/docs/source/usage/resource_files.rst index 9a202879..7a1dea8b 100644 --- a/docs/source/usage/resource_files.rst +++ b/docs/source/usage/resource_files.rst @@ -5,7 +5,7 @@ Resource files ================================================================================ A number of files containing preconfigured transformations and default parameters -for certain projections are bundled with the PROJ.4 distribution. Init files +for certain projections are bundled with the PROJ distribution. Init files contains preconfigured proj-strings for various coordinate reference systems and the defaults file contains default values for parameters of select projections. @@ -21,8 +21,8 @@ it easy to transformations between any two coordinate reference systems with 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.4 but it is also possible to -add your own custom init files. PROJ.4 looks for the init files in the directoty +A number of init files come pre-bundled with PROJ but it is also possible to +add your own custom init files. PROJ looks for the init files in the directoty listed in the ``PROJ_LIB`` environment variable. The format of init files made up of a identifier in angled brackets and a @@ -84,7 +84,7 @@ which then expands to +epoch=2000.0 +transpose +tobs=2010.5 -Below is a list of the init files that are packaged with PROJ.4. +Below is a list of the init files that are packaged with PROJ. ======== ================================================================ Name Description @@ -108,12 +108,12 @@ Below is a list of the init files that are packaged with PROJ.4. Defaults file ------------------------------------------------------------------------------- -The ``proj_def.dat`` file supplies default parameters for PROJ.4. It uses the same +The ``proj_def.dat`` file supplies default parameters for PROJ. It uses the same syntax as the init files described above. The identifiers in the defaults file describe to what the parameters should apply. If the ``<general>`` identifier is used, then all parameters in that section applies for all proj-strings. Otherwise the identifier is connected to a specific projection. With the defaults file -supplied with PROJ.4 the default ellipsoid is set to WGS84 (for all proj-strings). +supplied with PROJ the default ellipsoid is set to WGS84 (for all proj-strings). Apart from that only the Albers Equal Area, :doc:`Lambert Conic Conformal<operations/projections/lcc>` and the :doc:`Lagrange<operations/projections/lagrng>` projections have default parameters. diff --git a/docs/source/usage/transformation.rst b/docs/source/usage/transformation.rst index 98e607a7..2f5ee880 100644 --- a/docs/source/usage/transformation.rst +++ b/docs/source/usage/transformation.rst @@ -4,17 +4,17 @@ Geodetic transformation ================================================================================ -PROJ.4 can do everything from the most simple projection to very complex +PROJ can do everything from the most simple projection to very complex transformations across many reference frames. While originally developed as a -tool for cartographic projections, PROJ.4 has over time evolved into a powerfull +tool for cartographic projections, PROJ has over time evolved into a powerfull generic coordinate transformation engine that makes it possible to do both large scale cartographic projections as well as coordinate transformation at a geodetic high precision level. This chapter delves into the details of how geodetec transformations of varying complexity can be performed. -In PROJ.4, two frameworks for geodetic transformations exists, the *cs2cs* +In PROJ, two frameworks for geodetic transformations exists, the *cs2cs* framework and the *transformation pipelines* framework. The first is the original, -and limited, framework for doing geodetic transforms in PROJ.4 The latter is a +and limited, framework for doing geodetic transforms in PROJ The latter is a newer addition that aims to be a more complete transformation framework. Both are described in the sections below. Large portions of the text are based on [EversKnudsen2017]_. @@ -60,7 +60,7 @@ of 3 steps (geodetic-to-cartesian → Helmert → cartesian-to-geodetic), pipeli The pipeline driver, makes this kind of chained transformations possible. The implementation is compact, consisting of just one pseudo-projection, called ``pipeline``, which takes as its arguments strings of elementary projections -(note: "projection" is the, slightly misleading, PROJ.4 term used for any kind of +(note: "projection" is the, slightly misleading, PROJ term used for any kind of transformation). The pipeline pseudo projection is supplemented by a number of elementary transformations, all in all providing a framework for building high accuracy @@ -69,7 +69,7 @@ solutions for a wide spectrum of geodetic tasks. As a first example, let us take a look at the iconic *geodetic → Cartesian → Helmert → geodetic* case (steps 2 to 4 in the example in -the itroduction). In PROJ.4 it can be implemented as +the itroduction). In PROJ it can be implemented as :: @@ -108,7 +108,7 @@ deprecated system with decimeter level tensions. step proj=utm ellps=GRS80 zone=33 With the pipeline framework spatiotemporal transformation is possible. This is -possible by leveraging the time dimension in PROJ.4 that enables 4D coordinates +possible by leveraging the time dimension in PROJ that enables 4D coordinates (three spatial components and one temporal component) to be passed through a transformation pipeline. In the example below a transformation from ITRF93 to ITRF2000 is defined. The temporal component is given as GPS weeks in the input @@ -209,8 +209,8 @@ such as NAD27 to NAD83. These grid shift files include a shift to be applied at each grid location. Actually grid shifts are normally computed based on an interpolation between the containing four grid points. -PROJ.4 supports use of grid files for shifting between various reference frames. -The grid shift table formats are ctable (the binary format produced by the PROJ.4 +PROJ supports use of grid files for shifting between various reference frames. +The grid shift table formats are ctable (the binary format produced by the PROJ ``nad2bin`` program), NTv1 (the old Canadian format), and NTv2 (``.gsb`` - the new Canadian and Australian format). |