From a3f43744feec86272fe532124679d3a013ef9a8c Mon Sep 17 00:00:00 2001 From: PROJ deploybot Date: Tue, 22 Mar 2022 20:00:06 +0000 Subject: update with results of commit https://github.com/OSGeo/PROJ/commit/53c07a8bd211b7aee4bc07a9c6726005504b7181 --- apps/cct.html | 371 ++++++++++++++++++++++++ apps/common_man.html | 118 ++++++++ apps/cs2cs.html | 475 ++++++++++++++++++++++++++++++ apps/geod.html | 322 +++++++++++++++++++++ apps/gie.html | 514 +++++++++++++++++++++++++++++++++ apps/index.html | 160 +++++++++++ apps/proj.html | 365 +++++++++++++++++++++++ apps/projinfo.html | 799 +++++++++++++++++++++++++++++++++++++++++++++++++++ apps/projsync.html | 325 +++++++++++++++++++++ 9 files changed, 3449 insertions(+) create mode 100644 apps/cct.html create mode 100644 apps/common_man.html create mode 100644 apps/cs2cs.html create mode 100644 apps/geod.html create mode 100644 apps/gie.html create mode 100644 apps/index.html create mode 100644 apps/proj.html create mode 100644 apps/projinfo.html create mode 100644 apps/projsync.html (limited to 'apps') diff --git a/apps/cct.html b/apps/cct.html new file mode 100644 index 00000000..918aba97 --- /dev/null +++ b/apps/cct.html @@ -0,0 +1,371 @@ + + + + + + + cct — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

cct

+

Coordinate Conversion and Transformation.

+
+

Synopsis

+
+

cct [-cIostvz [args]] +opt[=arg] … file …

+
+

or

+
+

cct [-cIostvz [args]] {object_definition} file …

+
+

Where {object_definition} is one of the possibilities accepted +by proj_create(), provided it expresses a coordinate operation

+
+
+
+

New in version 8.0.0.

+
+
+

Note

+

Before version 8.0.0 only proj-strings could be used to instantiate +operations in cct.

+
+
+

or

+
+

cct [-cIostvz [args]] {object_reference} file …

+
+

where {object_reference} is a filename preceded by the ‘@’ character. The +file referenced by the {object_reference} must contain a valid +{object_definition}.

+
+
+

New in version 8.0.0.

+
+
+
+
+

Description

+

cct is a 4D equivalent to the proj projection program, +performs transformation coordinate systems on a set of input points. The +coordinate system transformation can include translation between projected +and geographic coordinates as well as the application of datum shifts.

+

The following control parameters can appear in any order:

+
+
+-c <x,y,z,t>
+

Specify input columns for (up to) 4 input parameters. Defaults to 1,2,3,4.

+
+ +
+
+-d <n>
+
+

New in version 5.2.0.

+
+

Specify the number of decimals in the output.

+
+ +
+
+-I
+

Do the inverse transformation.

+
+ +
+
+-o <output file name>, --output=<output file name>
+

Specify the name of the output file.

+
+ +
+
+-t <time>, --time=<time>
+

Specify a fixed observation time to be used for all input data.

+
+ +
+
+-z <height>, --height=<height>
+

Specify a fixed observation height to be used for all input data.

+
+ +
+
+-s <n>, --skip-lines=<n>
+
+

New in version 5.1.0.

+
+

Skip the first n lines of input. This applies to any kind of input, whether +it comes from STDIN, a file or interactive user input.

+
+ +
+
+-v, --verbose
+

Write non-essential, but potentially useful, information to stderr. +Repeat for additional information (-vv, -vvv, etc.)

+
+ +
+
+--version
+

Print version number.

+
+ +

The +opt arguments are associated with coordinate operation parameters. +Usage varies with operation.

+

For a complete description consult the projection pages.

+

cct is an acronym meaning Coordinate Conversion and Transformation.

+

The acronym refers to definitions given in the OGC 08-015r2/ISO-19111 +standard “Geographical Information – Spatial Referencing by Coordinates”, +which defines two different classes of coordinate operations:

+

Coordinate Conversions, which are coordinate operations where input +and output datum are identical (e.g. conversion from geographical to +cartesian coordinates) and

+

Coordinate Transformations, which are coordinate operations where +input and output datums differ (e.g. change of reference frame).

+
+
+

Use of remote grids

+
+

New in version 7.0.0.

+
+

If the PROJ_NETWORK environment variable is set to ON, +cct will attempt to use remote grids stored on CDN (Content +Delivery Network) storage, when they are not available locally.

+

More details are available in the Network capabilities section.

+
+
+

Examples

+
    +

  1. The operator specs describe the action to be performed by cct. So +the following script

    2. +
+
echo 12 55 0 0 | cct +proj=utm +zone=32 +ellps=GRS80
+
+
+

will transform the input geographic coordinates into UTM zone 32 coordinates. +Hence, the command

+
echo 12 55 | cct -z0 -t0 +proj=utm +zone=32 +ellps=GRS80
+
+
+

Should give results comparable to the classic proj command

+
echo 12 55 | proj +proj=utm +zone=32 +ellps=GRS80
+
+
+
    +

  1. Convert geographical input to UTM zone 32 on the GRS80 ellipsoid:

    2. +
+
cct +proj=utm +ellps=GRS80 +zone=32
+
+
+
    +

  1. Roundtrip accuracy check for the case above:

    2. +
+
cct +proj=pipeline +proj=utm +ellps=GRS80 +zone=32 +step +step +inv
+
+
+
    +

  1. As (2) but specify input columns for longitude, latitude, height and time:

    2. +
+
cct -c 5,2,1,4 +proj=utm +ellps=GRS80 +zone=32
+
+
+
    +

  1. As (2) but specify fixed height and time, hence needing only 2 cols in +input:

    2. +
+
cct -t 0 -z 0 +proj=utm +ellps=GRS80 +zone=32
+
+
+
    +

  1. Auxiliary data following the coordinate input is forward to the output +stream:

    2. +
+
$ echo 12 56 100 2018.0 auxiliary data | cct +proj=merc
+1335833.8895   7522963.2411      100.0000     2018.0000 auxiliary data
+
+
+
    +

  1. Coordinate operation referenced through its code

    2. +
+
$ echo 3541657.3778 948984.2343 5201383.5231 2020.5 | cct EPSG:8366
+3541657.9112    948983.7503  5201383.2482     2020.5000
+
+
+
    +

  1. Coordinate operation referenced through its name

    2. +
+
$ echo 3541657.3778 948984.2343 5201383.5231 2020.5 | cct "ITRF2014 to ETRF2014 (1)"
+3541657.9112    948983.7503  5201383.2482     2020.5000
+
+
+
+
+

Background

+

cct also refers to Carl Christian Tscherning (1942–2014), +professor of Geodesy at the University of Copenhagen, mentor and advisor +for a generation of Danish geodesists, colleague and collaborator for +two generations of global geodesists, Secretary General for the +International Association of Geodesy, IAG (1995–2007), fellow of the +American Geophysical Union (1991), recipient of the IAG Levallois Medal +(2007), the European Geosciences Union Vening Meinesz Medal (2008), and +of numerous other honours.

+

cct, or Christian, as he was known to most of us, was recognized for his +good mood, his sharp wit, his tireless work, and his great commitment to +the development of geodesy – both through his scientific contributions, +comprising more than 250 publications, and by his mentoring and teaching +of the next generations of geodesists.

+

As Christian was an avid Fortran programmer, and a keen Unix connoisseur, +he would have enjoyed to know that his initials would be used to name a +modest Unix style transformation filter, hinting at the tireless aspect +of his personality, which was certainly one of the reasons he accomplished +so much, and meant so much to so many people.

+

Hence, in honour of cct (the geodesist) this is cct (the program).

+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/common_man.html b/apps/common_man.html new file mode 100644 index 00000000..e3facb4c --- /dev/null +++ b/apps/common_man.html @@ -0,0 +1,118 @@ + + + + + + + Bugs — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ + + +
+
+
+ +
+ +
+

© Copyright 1983-2022. + Last updated on 22 Mar 2022. +

+
+ + Built with Sphinx using a + theme + provided by Read the Docs. + + +
+
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/cs2cs.html b/apps/cs2cs.html new file mode 100644 index 00000000..92d98322 --- /dev/null +++ b/apps/cs2cs.html @@ -0,0 +1,475 @@ + + + + + + + cs2cs — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

cs2cs

+

Filter for transformations between two coordinate reference systems.

+
+

Synopsis

+
+
+
cs2cs [-eEfIlrstvwW [args]]
+
+
[[–area <name_or_code>] | [–bbox <west_long,south_lat,east_long,north_lat>]]
+
[–authority <name>] [–no-ballpark] [–accuracy <accuracy>]
+
([+opt[=arg] …] [+to +opt[=arg] …] | {source_crs} {target_crs})
+
file …
+
+
+

where {source_crs} or {target_crs} is one of the possibilities accepted +by proj_create(), provided it expresses a CRS

+ +
+

New in version 6.0.0.

+
+
+

Note

+

before 7.0.1, it was needed to add +to between {source_crs} and {target_crs} +when adding a filename

+
+
+
+
+

Description

+

cs2cs performs transformation between the source and destination +cartographic coordinate reference system on a set of input points. The coordinate +reference system transformation can include translation between projected and +geographic coordinates as well as the application of datum shifts.

+

The following control parameters can appear in any order:

+
+
+-I
+

Method to specify inverse translation, convert from +to coordinate system to +the primary coordinate system defined.

+
+ +
+
+-t<a>
+

Where a specifies a character employed as the first character to denote a control +line to be passed through without processing. This option applicable to +ASCII input only. (# is the default value).

+
+ +
+
+-d <n>
+
+

New in version 5.2.0.

+
+

Specify the number of decimals in the output.

+
+ +
+
+-e <string>
+

Where string is an arbitrary string to be output if an error is detected during +data transformations. The default value is a three character string: *\t*.

+
+ +
+
+-E
+

Causes the input coordinates to be copied to the output line prior to +printing the converted values.

+
+ +
+
+-l<[=id]>
+

List projection identifiers that can be selected with +proj. cs2cs -l=id +gives expanded description of projection id, e.g. cs2cs -l=merc.

+
+ +
+
+-lp
+

List of all projection id that can be used with the +proj parameter. +Equivalent to cs2cs -l.

+
+ +
+
+-lP
+

Expanded description of all projections that can be used with the +proj +parameter.

+
+ +
+
+-le
+

List of all ellipsoids that can be selected with the +ellps parameters.

+
+ +
+
+-lu
+

List of all distance units that can be selected with the +units parameter.

+
+ +
+
+-r
+

This options reverses the order of the first two expected +inputs from that specified by the CRS to the opposite +order. The third coordinate, typically height, remains +third.

+
+ +
+
+-s
+

This options reverses the order of the first two expected +outputs from that specified by the CRS to the opposite +order. The third coordinate, typically height, remains +third.

+
+ +
+
+-f <format>
+

Where format is a printf format string to control the form of the output values. +For inverse projections, the output will be in degrees when this option is +employed. If a format is specified for inverse projection the output data +will be in decimal degrees. The default format is "%.2f" for forward +projection and DMS for inverse.

+
+ +
+
+-w<n>
+

Where n is the number of significant fractional digits to employ for seconds +output (when the option is not specified, -w3 is assumed).

+
+ +
+
+-W<n>
+

Where n is the number of significant fractional digits to employ for seconds +output. When -W is employed the fields will be constant width +with leading zeroes.

+
+ +
+
+-v
+

Causes a listing of cartographic control parameters tested for and used by +the program to be printed prior to input data.

+
+ +
+
+--area <name_or_code>
+
+

New in version 8.0.0.

+
+

Specify an area of interest to restrict the results when researching +coordinate operations between 2 CRS. The area of interest can be specified either +as a name (e.g “Denmark - onshore”) or a AUTHORITY:CODE (EPSG:3237)

+

This option is mutually exclusive with --bbox.

+
+ +
+
+--bbox <west_long,south_lat,east_long,north_lat>
+
+

New in version 8.0.0.

+
+

Specify an area of interest to restrict the results when researching +coordinate operations between 2 CRS. The area of interest is specified as a +bounding box with geographic coordinates, expressed in degrees in a +unspecified geographic CRS. +west_long and east_long should be in the [-180,180] range, and +south_lat and north_lat in the [-90,90]. west_long is generally lower than +east_long, except in the case where the area of interest crosses the antimeridian.

+
+ +
+
+--no-ballpark
+
+

New in version 8.0.0.

+
+

Disallow any coordinate operation that is, or contains, a +Ballpark transformation

+
+ +
+
+--accuracy <accuracy>
+
+

New in version 8.0.0.

+
+

Sets the minimum desired accuracy for candidate coordinate operations.

+
+ +
+
+--authority <name>
+
+

New in version 8.0.0.

+
+

This option can be used to restrict the authority of coordinate operations +looked up in the database. When not specified, coordinate +operations from any authority will be searched, with the restrictions set +in the authority_to_authority_preference database table related to the authority +of the source/target CRS themselves. +If authority is set to any, then coordinate operations from any authority will be searched +If authority is a non-empty string different of any, then coordinate operations +will be searched only in that authority namespace (e.g EPSG).

+

This option is mutually exclusive with --bbox.

+
+ +

The +opt run-line arguments are associated with cartographic +parameters. Usage varies with projection and for a complete description +consult the projection pages.

+

The cs2cs program requires two coordinate reference system (CRS) definitions. The first (or +primary is defined based on all projection parameters not appearing after the ++to argument. All projection parameters appearing after the +to argument +are considered the definition of the second CRS. If there is no +second CRS defined, a geographic CRS based on the +datum and ellipsoid of the source CRS is assumed. Note that the +source and destination CRS can both of same or different nature (geographic, +projected, compound CRS), or one of each and may have the same or different datums.

+

When using a WKT definition or a AUTHORITY:CODE, the axis order of the CRS will +be enforced. So for example if using EPSG:4326, the first value expected (or +returned) will be a latitude.

+

Internally, cs2cs uses the proj_create_crs_to_crs() function +to compute the appropriate coordinate operation, so implementation details of +this function directly impact the results returned by the program.

+

The environment parameter PROJ_LIB establishes the +directory for resource files (database, datum shift grids, etc.)

+

One or more files (processed in left to right order) specify the source of +data to be transformed. A - will specify the location of processing standard +input. If no files are specified, the input is assumed to be from stdin. +For input data the two data values must be in the first two white space +separated fields and when both input and output are ASCII all trailing portions +of the input line are appended to the output line.

+

Input geographic data (longitude and latitude) must be in DMS or decimal +degrees format and input cartesian data must be in units consistent with the +ellipsoid major axis or sphere radius units. Output geographic coordinates will +normally be in DMS format (use -f %.12f for decimal degrees with 12 decimal +places), while projected (cartesian) coordinates will be in linear +(meter, feet) units.

+
+

Use of remote grids

+
+

New in version 7.0.0.

+
+

If the PROJ_NETWORK environment variable is set to ON, +cs2cs will attempt to use remote grids stored on CDN (Content +Delivery Network) storage, when they are not available locally.

+

More details are available in the Network capabilities section.

+
+
+
+

Examples

+
+

Using PROJ strings

+

The following script

+
cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=10 +datum=NAD27 -r <<EOF
+45°15'33.1" 111.5W
+45d15.551666667N -111d30
++45.25919444444 111d30'000w
+EOF
+
+
+

will transform the input NAD83 geographic coordinates into NAD27 coordinates in +the UTM projection with zone 10 selected. The geographic values of this +example are equivalent and meant as examples of various forms of DMS input. +The x-y output data will appear as three lines of:

+
1402293.44  5076292.68 0.00
+
+
+
+
+

Using EPSG CRS codes

+

Transforming from WGS 84 latitude/longitude (in that order) to UTM Zone 31N/WGS 84

+
cs2cs EPSG:4326 EPSG:32631 <<EOF
+45N 2E
+EOF
+
+
+

outputs

+
421184.70   4983436.77 0.00
+
+
+
+
+

Using EPSG CRS names

+

Transforming from WGS 84 latitude/longitude (in that order) with EGM96 height to +UTM Zone 31N/WGS 84 with WGS84 ellipsoidal height

+
echo 45 2 0 | cs2cs "WGS 84 + EGM96 height" "WGS 84 / UTM zone 31N"
+
+
+

outputs

+
421184.70   4983436.77 50.69
+
+
+
+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/geod.html b/apps/geod.html new file mode 100644 index 00000000..2c1e5b03 --- /dev/null +++ b/apps/geod.html @@ -0,0 +1,322 @@ + + + + + + + geod — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

geod

+
+

Synopsis

+
+

geod +ellps=<ellipse> [-afFIlptwW [args]] [+opt[=arg] …] file …

+

invgeod +ellps=<ellipse> [-afFIlptwW [args]] [+opt[=arg] …] file …

+
+
+
+

Description

+

geod (direct) and invgeod (inverse) perform geodesic +(Great Circle) computations for determining latitude, longitude and back +azimuth of a terminus point given a initial point latitude, longitude, +azimuth and distance (direct) or the forward and back azimuths and distance +between an initial and terminus point latitudes and longitudes (inverse). +The results are accurate to round off for \(|f| < 1/50\), where +\(f\) is flattening.

+

invgeod may not be available on all platforms; in this case +use geod -I instead.

+

The following command-line options can appear in any order:

+
+
+-I
+

Specifies that the inverse geodesic computation is to be performed. May be +used with execution of geod as an alternative to invgeod execution.

+
+ +
+
+-a
+

Latitude and longitudes of the initial and terminal points, forward and +back azimuths and distance are output.

+
+ +
+
+-t<a>
+

Where a specifies a character employed as the first character to denote a control +line to be passed through without processing.

+
+ +
+
+-le
+

Gives a listing of all the ellipsoids that may be selected with the ++ellps= option.

+
+ +
+
+-lu
+

Gives a listing of all the units that may be selected with the +units= +option. (Default units are meters.)

+
+ +
+
+-f <format>
+

Where format is a printf format string to control the output form of the +geographic coordinate values. The default mode is DMS.

+
+ +
+
+-F <format>
+

Where format is a printf format string to control the output form of the distance +value. The default mode is "%.3f".

+
+ +
+
+-w<n>
+

Where n is the number of significant fractional digits to employ for seconds +output (when the option is not specified, -w3 is assumed).

+
+ +
+
+-W<n>
+

Where n is the number of significant fractional digits to employ for seconds +output. When -W is employed the fields will be constant width +with leading zeroes.

+
+ +
+
+-p
+

This option causes the azimuthal values to be output as unsigned DMS +numbers between 0 and 360 degrees. Also note -f.

+
+ +

The +opt command-line options are associated with geodetic +parameters for specifying the ellipsoidal or sphere to use. +controls. The options are processed in left to right order +from the command line. Reentry of an option is ignored with +the first occurrence assumed to be the desired value.

+

See Cartographic projection for full +list of these parameters and controls.

+

One or more files (processed in left to right order) specify +the source of data to be transformed. A - will specify the +location of processing standard input. If no files are specified, +the input is assumed to be from stdin.

+

For direct determinations input data must be in latitude, longitude, +azimuth and distance order and output will be latitude, +longitude and back azimuth of the terminus point. Latitude, +longitude of the initial and terminus point are input for the +inverse mode and respective forward and back azimuth from the +initial and terminus points are output along with the distance +between the points.

+

Input geographic coordinates (latitude and longitude) and +azimuthal data must be in decimal degrees or DMS format and +input distance data must be in units consistent with the ellipsoid +major axis or sphere radius units. The latitude must lie +in the range [-90d,90d]. Output geographic coordinates will be +in DMS (if the -f switch is not employed) to 0.001” with trailing, +zero-valued minute-second fields deleted. Output distance +data will be in the same units as the ellipsoid or sphere +radius.

+

The Earth’s ellipsoidal figure may be selected in the same manner +as program proj by using +ellps=, +a=, +es=, etc.

+

geod may also be used to determine intermediate points along +either a geodesic line between two points or along an arc of +specified distance from a geographic point. In both cases an +initial point must be specified with +lat_1=lat and +lon_1=lon +parameters and either a terminus point +lat_2=lat and ++lon_2=lon or a distance and azimuth from the initial point +with +S=distance and +A=azimuth must be specified.

+

If points along a geodesic are to be determined then either ++n_S=integer specifying the number of intermediate points +and/or +del_S=distance specifying the incremental distance +between points must be specified.

+

To determine points along an arc equidistant from the initial +point both +del_A=angle and +n_A=integer must be specified +which determine the respective angular increments and number of +points to be determined.

+
+
+

Examples

+

The following script determines the geodesic azimuths and distance in U.S. +statute miles from Boston, MA, to Portland, OR:

+
geod +ellps=clrk66 <<EOF -I +units=us-mi
+42d15'N 71d07'W 45d31'N 123d41'W
+EOF
+
+
+

which gives the results:

+
-66d31'50.141" 75d39'13.083" 2587.504
+
+
+

where the first two values are the azimuth from Boston to Portland, +the back azimuth from Portland to Boston followed by the distance.

+

An example of forward geodesic use is to use the Boston location +and determine Portland’s location by azimuth and distance:

+
geod +ellps=clrk66 <<EOF +units=us-mi
+42d15'N 71d07'W -66d31'50.141" 2587.504
+EOF
+
+
+

which gives:

+
45d31'0.003"N 123d40'59.985"W 75d39'13.094"
+
+
+
+

Note

+

Lack of precision in the distance value compromises the +precision of the Portland location.

+
+
+
+

Further reading

+
    +

  1. GeographicLib.

    2. +

  2. C. F. F. Karney, Algorithms for Geodesics, J. Geodesy 87(1), 43–55 (2013); +addenda.

    3. +

  3. A geodesic bibliography.

    4. +
+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/gie.html b/apps/gie.html new file mode 100644 index 00000000..af88bca5 --- /dev/null +++ b/apps/gie.html @@ -0,0 +1,514 @@ + + + + + + + gie — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

gie

+

The Geospatial Integrity Investigation Environment

+
+

Synopsis

+
+

gie [ -hovql [ args ] ] file[s]

+
+
+
+

Description

+

gie, the Geospatial Integrity Investigation Environment, is a +regression testing environment for the PROJ transformation library. Its primary +design goal is to be able to perform regression testing of code that are a part +of PROJ, while not requiring any other kind of tooling than the same C compiler +already employed for compiling the library.

+
+
+-h, --help
+

Print usage information

+
+ +
+
+-o <file>, --output <file>
+

Specify output file name

+
+ +
+
+-v, --verbose
+

Verbose: Provide non-essential informational output. Repeat -v for +more verbosity (e.g. -vv)

+
+ +
+
+-q, --quiet
+

Quiet: Opposite of verbose. In quiet mode not even errors are +reported. Only interaction is through the return code (0 on success, +non-zero indicates number of FAILED tests)

+
+ +
+
+-l, --list
+

List the PROJ internal system error codes

+
+ +
+
+--version
+

Print version number

+
+ +

Tests for gie are defined in simple text files. Usually having the +extension .gie. Test for gie are written in the purpose-build command language for gie. +The basic functionality of the gie command language is implemented through just +3 command verbs: operation, which defines the PROJ operation to test, +accept, which defines the input coordinate to read, and expect, which +defines the result to expect.

+

A sample test file for gie that uses the three above basic commands looks +like:

+
<gie>
+
+--------------------------------------------
+Test output of the UTM projection
+--------------------------------------------
+operation  +proj=utm  +zone=32  +ellps=GRS80
+--------------------------------------------
+accept     12  55
+expect     691_875.632_14   6_098_907.825_05
+
+</gie>
+
+
+

Parsing of a gie file starts at <gie> and ends when </gie> +is reached. Anything before <gie> and after </gie> is not considered. +Test cases are created by defining an operation which +accept an input coordinate and expect an output +coordinate.

+

Because gie tests are wrapped in the <gie>/</gie> tags it is +also possible to add test cases to custom made init files. +The tests will be ignore by PROJ when reading the init file with +init and +gie ignores anything not wrapped in <gie>/</gie>.

+

gie tests are defined by a set of commands like operation, +accept and expect in the example above. Together the +commands make out the gie command language. Any line in a +gie file that does not start with a command is ignored. In the +example above it is seen how this can be used to add comments and styling to +gie test files in order to make them more readable as well as +documenting what the purpose of the various tests are.

+

Below the gie command language is explained in details.

+
+
+

Examples

+
    +

  1. Run all tests in a file with all debug information turned on

    2. +
+
gie -vvvv corner-cases.gie
+
+
+
    +

  1. Run all tests in several files

    2. +
+
gie foo bar
+
+
+
+
+

gie command language

+
+
+operation <+args>
+

Define a PROJ operation to test. Example:

+
operation proj=utm zone=32 ellps=GRS80
+# test 4D function
+accept    12 55 0 0
+expect    691875.63214  6098907.82501  0  0
+
+# test 2D function
+accept    12 56
+expect    687071.4391   6210141.3267
+
+
+
+ +
+
+accept <x y [z [t]]>
+

Define the input coordinate to read. Takes test coordinate. The coordinate +can be defined by either 2, 3 or 4 values, where the first two values are +the x- and y-components, the 3rd is the z-component and the 4th is the time +component. The number of components in the coordinate determines which +version of the operation is tested (2D, 3D or 4D). Many coordinates can be +accepted for one operation. For each accept an +accompanying expect is needed.

+

Note that gie accepts the underscore (_) as a thousands +separator. It is not required (in fact, it is entirely ignored by the +input routine), but it significantly improves the readability of the very +long strings of numbers typically required in projected coordinates.

+

See operation for an example.

+
+ +
+
+expect <x y [z [t]]> | <error code>
+

Define the expected coordinate that will be returned from accepted +coordinate passed though an operation. The expected coordinate can be +defined by either 2, 3 or 4 components, similarly to accept. +Many coordinates can be expected for one operation. For each +expect an accompanying accept is needed.

+

See operation for an example.

+

In addition to expecting a coordinate it is also possible to expect a +PROJ error code in case an operation can’t be created. This is useful when +testing that errors are caught and handled correctly. Below is an example of +that tests that the pipeline operator fails correctly when a non-invertible +pipeline is constructed.

+
operation   proj=pipeline step
+            proj=urm5 n=0.5 inv
+expect      failure pjd_err_malformed_pipeline
+
+
+

See gie --list for a list of error codes that can be expected.

+
+ +
+
+tolerance <tolerance>
+

The tolerance command controls how much accepted coordinates +can deviate from the expected coordinate. This is handy to test that an +operation meets a certain numerical tolerance threshold. Some operations +are expected to be accurate within millimeters where others might only be +accurate within a few meters. tolerance should

+
operation       proj=merc
+# test coordinate as returned by ```echo 12 55 | proj +proj=merc``
+tolerance       1 cm
+accept          12 55
+expect          1335833.89 7326837.72
+
+# test that the same coordinate with a 50 m false easting as determined
+# by ``echo 12 55 |proj +proj=merc +x_0=50`` is still within a 100 m
+# tolerance of the unaltered coordinate from proj=merc
+tolerance       100 m
+accept          12 55
+expect          1335883.89  7326837.72
+
+
+

The default tolerance is 0.5 mm. See proj -lu for a list of possible +units.

+
+ +
+
+roundtrip <n> <tolerance>
+

Do a roundtrip test of an operation. roundtrip needs a +operation and a accept command +to function. The accepted coordinate is passed to the operation first in +it’s forward mode, then the output from the forward operation is passed +back to the inverse operation. This procedure is done n times. If the +resulting coordinate is within the set tolerance of the initial coordinate, +the test is passed.

+

Example with the default 100 iterations and the default tolerance:

+
operation       proj=merc
+accept          12 55
+roundtrip
+
+
+

Example with count and default tolerance:

+
operation       proj=merc
+accept          12 55
+roundtrip       10000
+
+
+

Example with count and tolerance:

+
operation       proj=merc
+accept          12 55
+roundtrip       10000 5 mm
+
+
+
+ +
+
+direction <direction>
+

The direction command specifies in which direction an operation +is performed. This can either be forward or inverse. An example of +this is seen below where it is tested that a symmetrical transformation +pipeline returns the same results in both directions.

+
operation proj=pipeline zone=32 step
+          proj=utm  ellps=GRS80 step
+          proj=utm  ellps=GRS80 inv
+tolerance 0.1 mm
+
+accept 12 55 0 0
+expect 12 55 0 0
+
+# Now the inverse direction (still same result: the pipeline is symmetrical)
+
+direction inverse
+expect 12 55 0 0
+
+
+

The default direction is “forward”.

+
+ +
+
+ignore <error code>
+

This is especially +useful in test cases that rely on a grid that is not guaranteed to be +available. Below is an example of that situation.

+
operation proj=hgridshift +grids=nzgd2kgrid0005.gsb ellps=GRS80
+tolerance 1 mm
+ignore    pjd_err_failed_to_load_grid
+accept    172.999892181021551 -45.001620431954613
+expect    173                 -45
+
+
+

See gie --list for a list of error codes that can be ignored.

+
+ +
+
+require_grid <grid_name>
+

Checks the availability of the grid <grid_name>. If it is not found, then +all accept/expect pairs until the next +operation will be skipped. +require_grid can be repeated several times to specify several grids whose +presence is required.

+
+ +
+
+echo <text>
+

Add user defined text to the output stream. See the example below.

+
<gie>
+echo ** Mercator projection tests **
+operation +proj=merc
+accept  0   0
+expect  0   0
+</gie>
+
+
+

which returns

+
-------------------------------------------------------------------------------
+Reading file 'test.gie'
+** Mercator projection test **
+-------------------------------------------------------------------------------
+total:  1 tests succeeded,  0 tests skipped,  0 tests failed.
+-------------------------------------------------------------------------------
+
+
+
+ +
+
+skip
+

Skip any test after the first occurrence of skip. In the example below only +the first test will be performed. The second test is skipped. This feature is mostly +relevant for debugging when writing new test cases.

+
<gie>
+operation proj=merc
+accept  0   0
+expect  0   0
+skip
+accept  0   1
+expect  0   110579.9
+</gie>
+
+
+
+ +
+
+

Strict mode

+
+

New in version 7.1.

+
+

A stricter variant of normal gie syntax can be used by wrapping gie commands +between <gie-strict> and </gie-strict>. In strict mode, comment lines +must start with a sharp character. Unknown commands will be considered as an error. +A command can still be split on several lines, but intermediate lines must +end with the space character followed by backslash to mark the continuation.

+
+
<gie-strict>
+# This is a comment. The following line with multiple repeated characters too
+-------------------------------------------------
+# A command on several lines must use " \" continuation
+operation proj=hgridshift +grids=nzgd2kgrid0005.gsb \
+          ellps=GRS80
+tolerance 1 mm
+ignore    pjd_err_failed_to_load_grid
+accept    172.999892181021551 -45.001620431954613
+expect    173                 -45
+</gie-strict>
+
+
+
+
+
+

Background

+

More importantly than being an acronym for “Geospatial Integrity Investigation +Environment”, gie were also the initials, user id, and USGS email address of +Gerald Ian Evenden (1935–2016), the geospatial visionary, who, already in the +1980s, started what was to become the PROJ of today.

+

Gerald’s clear vision was that map projections are just special functions. +Some of them rather complex, most of them of two variables, but all of them +just special functions, and not particularly more special than the sin(), +cos(), tan(), and hypot() already available in the C standard library.

+

And hence, according to Gerald, they should not be particularly much harder +to use, for a programmer, than the sin()’s, tan()’s and +hypot()’s so readily available.

+

Gerald’s ingenuity also showed in the implementation of the vision, where +he devised a comprehensive, yet simple, system of key-value pairs for +parameterising a map projection, and the highly flexible PJ struct, storing +run-time compiled versions of those key-value pairs, hence making a map +projection function call, pj_fwd(PJ, point), as easy as a traditional function +call like hypot(x,y).

+

While today, we may have more formally well defined metadata systems (most +prominent the OGC WKT2 representation), nothing comes close being as easily +readable (“human compatible”) as Gerald’s key-value system. This system in +particular, and the PROJ system in general, was Gerald’s great gift to anyone +using and/or communicating about geodata.

+

It is only reasonable to name a program, keeping an eye on the +integrity of the PROJ system, in honour of Gerald.

+

So in honour, and hopefully also in the spirit, of Gerald Ian Evenden +(1935–2016), this is the Geospatial Integrity Investigation Environment.

+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/index.html b/apps/index.html new file mode 100644 index 00000000..dcbc4cb5 --- /dev/null +++ b/apps/index.html @@ -0,0 +1,160 @@ + + + + + + + Applications — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Applications

+

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 support +for datum transformation. The geod program provides the ability to do +geodesic (great circle) computations. gie is the program used for +regression tests in PROJ. cct, a 4D equivalent to the proj +program, performs transformation coordinate systems on a set of input points. +projinfo performs queries for geodetic objects and coordinate +operations. projsync is a tool for synchronizing PROJ datum and +transformation support data.

+
+ +
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/proj.html b/apps/proj.html new file mode 100644 index 00000000..98bd06a9 --- /dev/null +++ b/apps/proj.html @@ -0,0 +1,365 @@ + + + + + + + proj — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

proj

+

Cartographic projection filter.

+
+

Synopsis

+
+

proj [-beEfiIlmorsStTvVwW] [args]] [+opt[=arg] …] file …

+

invproj [-beEfiIlmorsStTvVwW] [args]] [+opt[=arg] …] file …

+
+
+
+

Description

+

proj and invproj perform respective forward and inverse +conversion of cartographic data to or from cartesian data with a wide +range of selectable projection functions.

+

invproj may not be available on all platforms; in this case +use proj -I instead.

+

The following control parameters can appear in any order

+
+
+-b
+

Special option for binary coordinate data input and output through standard +input and standard output. Data is assumed to be in system type double +floating point words. This option is to be used when proj is a child process +and allows bypassing formatting operations.

+
+ +
+
+-d <n>
+
+ +
+

New in version 5.2.0: Specify the number of decimals in the output.

+
+
+
+-i
+

Selects binary input only (see -b).

+
+ +
+
+-I
+

Alternate method to specify inverse projection. Redundant when used with +invproj.

+
+ +
+
+-o
+

Selects binary output only (see -b).

+
+ +
+
+-t<a>
+

Where a specifies a character employed as the first character to denote a +control line to be passed through without processing. This option +applicable to ASCII input only. (# is the default value).

+
+ +
+
+-e <string>
+

Where string is an arbitrary string to be output if an error is detected during +data transformations. The default value is a three character string: *\t*. +Note that if the -b, -i or -o options are employed, an error +is returned as HUGE_VAL value for both return values.

+
+ +
+
+-E
+

Causes the input coordinates to be copied to the output line prior to +printing the converted values.

+
+ +
+
+-l<[=id]>
+

List projection identifiers that can be selected with +proj. proj -l=id +gives expanded description of projection id, e.g. proj -l=merc.

+
+ +
+
+-lp
+

List of all projection id that can be used with the +proj parameter. +Equivalent to proj -l.

+
+ +
+
+-lP
+

Expanded description of all projections that can be used with the +proj +parameter.

+
+ +
+
+-le
+

List of all ellipsoids that can be selected with the +ellps parameters.

+
+ +
+
+-lu
+

List of all distance units that can be selected with the +units parameter.

+
+ +
+
+-r
+

This options reverses the order of the expected input from +longitude-latitude or x-y to latitude-longitude or y-x.

+
+ +
+
+-s
+

This options reverses the order of the output from x-y or longitude-latitude +to y-x or latitude-longitude.

+
+ +
+
+-S
+

Causes estimation of meridional and parallel scale factors, area scale +factor and angular distortion, and maximum and minimum scale factors to be +listed between <> for each input point. For conformal projections meridional +and parallel scales factors will be equal and angular distortion zero. Equal +area projections will have an area factor of 1.

+
+ +
+
+-m <mult>
+

The cartesian data may be scaled by the mult parameter. When processing data +in a forward projection mode the cartesian output values are multiplied by +mult otherwise the input cartesian values are divided by mult before inverse +projection. If the first two characters of mult are 1/ or 1: then the +reciprocal value of mult is employed.

+
+ +
+
+-f <format>
+

Where format is a printf format string to control the form of the output values. +For inverse projections, the output will be in degrees when this option is +employed. The default format is "%.2f" for forward projection and DMS for +inverse.

+
+ +
+
+-w<n>
+

Where n is the number of significant fractional digits to employ for seconds +output (when the option is not specified, -w3 is assumed).

+
+ +
+
+-W<n>
+

Where n is the number of significant fractional digits to employ for seconds +output. When -W is employed the fields will be constant width +with leading zeroes.

+
+ +
+
+-v
+

Causes a listing of cartographic control parameters tested for and used by +the program to be printed prior to input data.

+
+ +
+
+-V
+

This option causes an expanded annotated listing of the characteristics of +the projected point. -v is implied with this option.

+
+ +

The +opt run-line arguments are associated with cartographic parameters. +Additional projection control parameters may be contained in two auxiliary +control files: the first is optionally referenced with the ++init=file:id and the second is always processed after the name of the +projection has been established from either the run-line or the contents of ++init file. The environment parameter PROJ_LIB establishes the +default directory for a file reference without an absolute path. This is +also used for supporting files like datum shift files.

+

Usage of +opt varies with projection and for a complete description +consult the projection pages.

+

One or more files (processed in left to right order) specify the source of +data to be converted. A - will specify the location of processing standard +input. If no files are specified, the input is assumed to be from stdin. +For ASCII input data the two data values must be in the first two white space +separated fields and when both input and output are ASCII all trailing +portions of the input line are appended to the output line.

+

Input geographic data (longitude and latitude) must be in DMS or decimal degrees format and input +cartesian data must be in units consistent with the ellipsoid major axis or +sphere radius units. Output geographic coordinates will be in DMS (if the +-w switch is not employed) and precise to 0.001” with trailing, zero-valued +minute-second fields deleted.

+
+
+

Example

+

The following script

+
proj +proj=utm +lon_0=112w +ellps=clrk66 -r <<EOF
+45d15'33.1" 111.5W
+45d15.551666667N -111d30
++45.25919444444 111d30'000w
+EOF
+
+
+

will perform UTM forward projection with a standard UTM central meridian +nearest longitude 112W. The geographic values of this example are equivalent +and meant as examples of various forms of DMS input. The x-y output +data will appear as three lines of:

+
460769.27     5011648.45
+
+
+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/projinfo.html b/apps/projinfo.html new file mode 100644 index 00000000..7deccc2b --- /dev/null +++ b/apps/projinfo.html @@ -0,0 +1,799 @@ + + + + + + + projinfo — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

projinfo

+
+

New in version 6.0.0.

+
+

Geodetic object and coordinate operation queries

+
+

Synopsis

+
+
+
projinfo
+
+
[-o formats] [-k crs|operation|datum|ensemble|ellipsoid] [–summary] [-q]
+
[[–area name_or_code] | [–bbox west_long,south_lat,east_long,north_lat]]
+
[–spatial-test contains|intersects]
+
[–crs-extent-use none|both|intersection|smallest]
+
[–grid-check none|discard_missing|sort|known_available]
+
[–pivot-crs always|if_no_direct_transformation|never|{auth:code[,auth:code]*}]
+
[–show-superseded] [–hide-ballpark] [–accuracy {accuracy}]
+
[–allow-ellipsoidal-height-as-vertical-crs]
+
[–boundcrs-to-wgs84]
+
[–authority name]
+
[–main-db-path path] [–aux-db-path path]*
+
[–dump-db-structure]
+
[–identify] [–3d]
+
[–output-id AUTH:CODE]
+
[–c-ify] [–single-line]
+
–searchpaths | –remote-data |
+
–list-crs [list-crs-filter] |
+
–dump-db-structure [{object_definition} | {object_reference}] |
+
{object_definition} | {object_reference} | (-s {srs_def} -t {srs_def})
+

+
+
+

where {object_definition} or {srs_def} is one of the possibilities accepted +by proj_create()

+ +

{object_reference} is a filename preceded by the ‘@’ character. The +file referenced by the {object_reference} must contain a valid +{object_definition}.

+
+
+
+

Description

+

projinfo is a program that can query information on a geodetic object, +coordinate reference system (CRS) or coordinate operation, when the -s and -t +options are specified, and display it under different formats (PROJ string, WKT string +or PROJJSON string).

+

It can also be used to query coordinate operations available between two CRS.

+

The program is named with some reference to the GDAL gdalsrsinfo that offers +partly similar services.

+

The following control parameters can appear in any order:

+
+
+-o formats
+

formats is a comma separated combination of: +all, default, PROJ, WKT_ALL, WKT2:2015, WKT2:2019, WKT1:GDAL, WKT1:ESRI, PROJJSON, SQL.

+

Except all and default, other formats can be preceded by - to disable them.

+
+

Note

+

WKT2_2019 was previously called WKT2_2018.

+
+
+

Note

+

Before PROJ 6.3.0, WKT1:GDAL was implicitly calling –boundcrs-to-wgs84. +This is no longer the case.

+
+
+

Note

+

When SQL is specified, --output-id must be specified.

+
+
+ +
+
+-k crs|operation|datum|ensemble|ellipsoid
+

When used to query a single object with a AUTHORITY:CODE, determines the (k)ind of the object +in case there are CRS, coordinate operations or ellipsoids with the same CODE. +The default is crs.

+
+ +
+
+--summary
+

When listing coordinate operations available between 2 CRS, return the +result in a summary format, mentioning only the name of the coordinate +operation, its accuracy and its area of use.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+-q
+

Turn on quiet mode. Quiet mode is only available for queries on single objects, +and only one output format is selected. In that mode, only the PROJ, WKT or PROJJSON +string is displayed, without other introduction output. The output is then +potentially compatible of being piped in other utilities.

+
+ +
+
+--area name_or_code
+

Specify an area of interest to restrict the results when researching +coordinate operations between 2 CRS. The area of interest can be specified either +as a name (e.g “Denmark - onshore”) or a AUTHORITY:CODE (EPSG:3237) +This option is exclusive of --bbox.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--bbox west_long,south_lat,east_long,north_lat
+

Specify an area of interest to restrict the results when researching +coordinate operations between 2 CRS. The area of interest is specified as a +bounding box with geographic coordinates, expressed in degrees in a +unspecified geographic CRS. +west_long and east_long should be in the [-180,180] range, and +south_lat and north_lat in the [-90,90]. west_long is generally lower than +east_long, except in the case where the area of interest crosses the antimeridian.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--spatial-test contains|intersects
+

Specify how the area of use of coordinate operations found in the database +are compared to the area of use specified explicitly with --area or --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 +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 +area of interest is listed.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--crs-extent-use none|both|intersection|smallest
+

Specify which area of interest to consider when no explicit one is specified +with --area or --bbox options. +By default (smallest strategy), the area of +use of the source or target CRS will be looked, and the one that is the +smallest one in terms of area will be used as the area of interest. +If using none, no area of interest is used. +If using both, only coordinate operations that relate (contain or intersect +depending of the --spatial-test strategy) to the area of use of both CRS +are selected. +If using intersection, the area of interest is the intersection of the +bounding box of the area of use of the source and target CRS

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--grid-check none|discard_missing|sort|known_available
+

Specify how the presence or absence of a horizontal or vertical shift grid +required for a coordinate operation affects the results returned when +researching coordinate operations between 2 CRS. +The default strategy is sort (if PROJ_NETWORK is not defined). +In that case, all candidate +operations are returned, but the actual availability of the grids is used +to determine the sorting order. That is, if a coordinate operation involves +using a grid that is not available in the PROJ resource directories +(determined by the PROJ_LIB environment variable, it will be listed in +the bottom of the results. +The none strategy completely disables the checks of presence of grids and +this returns the results as if all the grids where available. +The discard_missing strategy discards results that involve grids not +present in the PROJ resource directories. +The known_available strategy discards results that involve grids not +present in the PROJ resource directories and that are not known of the CDN. +This is the default strategy is PROJ_NETWORK is set to ON.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--pivot-crs always|if_no_direct_transformation|never|{auth:code[,auth:code]*}
+

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 +( 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 +even if there are direct transformations. +It is also possible to restrict the pivot CRS to consider by specifying +one or several CRS by their AUTHORITY:CODE.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--show-superseded
+

When enabled, coordinate operations that are superseded by others will be +listed. Note that supersession is not equivalent to deprecation: superseded +operations are still considered valid although they have a better equivalent, +whereas deprecated operations have been determined to be erroneous and are +not considered at all.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--hide-ballpark
+
+

New in version 7.1.

+
+

Hides any coordinate operation that is, or contains, a +Ballpark transformation

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--accuracy {accuracy}
+
+

New in version 8.0.

+
+

Sets the minimum desired accuracy for returned coordinate operations.

+
+

Note

+

only used for coordinate operation computation

+
+
+ +
+
+--allow-ellipsoidal-height-as-vertical-crs
+
+

New in version 8.0.

+
+

Allows exporting a geographic or projected 3D CRS as a compound CRS whose +vertical CRS represents the ellipsoidal height.

+
+

Note

+

only used for CRS, and with WKT1:GDAL output format

+
+
+ +
+
+--boundcrs-to-wgs84
+

When specified, this option researches a coordinate operation from the +base geographic CRS of the single CRS, source or target CRS to the WGS84 +geographic CRS, and if found, wraps those CRS into a BoundCRS object. +This is mostly to be used for early-binding approaches.

+
+ +
+
+--authority name
+

Specify the name of the authority into which to restrict looks up for +objects, when specifying an object by name or when coordinate operations are +computed. The default is to allow all authorities.

+

When used with SQL output, this restricts the authorities to which intermediate +objects can belong to (the default is EPSG and PROJ). Note that the authority +of the --output-id option will also be implicitly added.

+
+ +
+
+--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.

+
+ +
+
+--aux-db-path path
+

Specify the name and path of auxiliary databases, that are to be combined +with the main database. Those auxiliary databases must have a table +structure that is identical to the main database, but can be partly filled +and their entries can refer to entries of the main database. +The option may be repeated to specify several auxiliary databases.

+
+ +
+
+--identify
+

When used with an object definition, this queries the PROJ database to find +known objects, typically CRS, that are close or identical to the object. +Each candidate object is associated with an approximate likelihood percentage. +This is useful when used with a WKT string that lacks a EPSG identifier, +such as ESRI WKT1. This might also be used with PROJ strings. +For example, +proj=utm +zone=31 +datum=WGS84 +type=crs will be identified +with a likelihood of 70% to EPSG:32631

+
+ +
+
+--dump-db-structure
+
+

New in version 8.1.

+
+

Outputs the sequence of SQL statements to create a new empty valid auxiliary +database. This option can be specified as the only switch of the utility. +If also specifying a CRS object and the --output-id option, the +definition of the object as SQL statements will be appended.

+
+ +
+
+--list-crs [list-crs-filter]
+
+

New in version 8.1.

+
+

Outputs a list (authority name:code and CRS name) of the filtered CRSs from the database. +If no filter is provided all authority names and types of non deprecated CRSs are dumped. +list-crs-filter is a comma separated combination of: allow_deprecated,geodetic,geocentric, +geographic,geographic_2d,geographic_3d,vertical,projected,compound. +Affected by options --authority, --area, --bbox and --spatial-test

+
+ +
+
+--3d
+
+

New in version 6.3.

+
+

“Promote” the CRS(s) to their 3D version. In the context of researching +available coordinate transformations, explicitly specifying this option is +not necessary, because when one of the source or target CRS has a vertical +component but not the other one, the one that has no vertical component is +automatically promoted to a 3D version, where its vertical axis is the +ellipsoidal height in metres, using the ellipsoid of the base geodetic CRS.

+
+ +
+
+--output-id=AUTH:NAME
+
+

New in version 8.1.

+
+

Identifier to assign to the object (for SQL output).

+

It is strongly recommended that new objects should not be added in common +registries, such as EPSG, ESRI, IAU, etc. +Users should use a custom authority name instead. If a new object should be +added to the official EPSG registry, users are invited to follow the +procedure explained at https://epsg.org/dataset-change-requests.html.

+

Combined with --dump-db-structure, users can create +auxiliary databases, instead of directly modifying the main proj.db database. +See the example how to export to an auxiliary database.

+

Those auxiliary databases can be specified through +proj_context_set_database_path() or the PROJ_AUX_DB +environment variable.

+
+ +
+
+--c-ify
+

For developers only. Modify the string output of the utility so that it +is easy to put those strings in C/C++ code

+
+ +
+
+--single-line
+

Output PROJ, WKT or PROJJSON strings on a single line, instead of multiple +indented lines by default.

+
+ +
+
+--searchpaths
+
+

New in version 7.0.

+
+

Output the directories into which PROJ resources will be looked for +(if not using C API such as proj_context_set_search_paths() +that will override them.

+
+ +
+
+--remote-data
+
+

New in version 7.0.

+
+

Display information regarding if Network capabilities is enabled, and the +related URL.

+
+ +
+
+

Examples

+
    +

  1. Query the CRS object corresponding to EPSG:4326

    2. +
+
projinfo EPSG:4326
+
+
+

Output:

+
PROJ.4 string:
++proj=longlat +datum=WGS84 +no_defs +type=crs
+
+WKT2:2019 string:
+GEOGCRS["WGS 84",
+    DATUM["World Geodetic System 1984",
+        ELLIPSOID["WGS 84",6378137,298.257223563,
+            LENGTHUNIT["metre",1]]],
+    PRIMEM["Greenwich",0,
+        ANGLEUNIT["degree",0.0174532925199433]],
+    CS[ellipsoidal,2],
+        AXIS["geodetic latitude (Lat)",north,
+            ORDER[1],
+            ANGLEUNIT["degree",0.0174532925199433]],
+        AXIS["geodetic longitude (Lon)",east,
+            ORDER[2],
+            ANGLEUNIT["degree",0.0174532925199433]],
+    USAGE[
+        SCOPE["unknown"],
+        AREA["World"],
+        BBOX[-90,-180,90,180]],
+    ID["EPSG",4326]]
+
+
+
    +

  1. List the coordinate operations between NAD27 (designed with its CRS name) +and NAD83 (designed with its EPSG code 4269) within an area of interest

    2. +
+
projinfo -s NAD27 -t EPSG:4269 --area "USA - Missouri"
+
+
+

Output:

+
DERIVED_FROM(EPSG):1241, NAD27 to NAD83 (1), 0.15 m, USA - CONUS including EEZ
+
+PROJ string:
++proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert \
++xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=conus \
++step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
+
+WKT2:2019 string:
+COORDINATEOPERATION["NAD27 to NAD83 (1)",
+    SOURCECRS[
+        GEOGCRS["NAD27",
+            DATUM["North American Datum 1927",
+                ELLIPSOID["Clarke 1866",6378206.4,294.978698213898,
+                    LENGTHUNIT["metre",1]]],
+            PRIMEM["Greenwich",0,
+                ANGLEUNIT["degree",0.0174532925199433]],
+            CS[ellipsoidal,2],
+                AXIS["geodetic latitude (Lat)",north,
+                    ORDER[1],
+                    ANGLEUNIT["degree",0.0174532925199433]],
+                AXIS["geodetic longitude (Lon)",east,
+                    ORDER[2],
+                    ANGLEUNIT["degree",0.0174532925199433]]]],
+    TARGETCRS[
+        GEOGCRS["NAD83",
+            DATUM["North American Datum 1983",
+                ELLIPSOID["GRS 1980",6378137,298.257222101,
+                    LENGTHUNIT["metre",1]]],
+            PRIMEM["Greenwich",0,
+                ANGLEUNIT["degree",0.0174532925199433]],
+            CS[ellipsoidal,2],
+                AXIS["geodetic latitude (Lat)",north,
+                    ORDER[1],
+                    ANGLEUNIT["degree",0.0174532925199433]],
+                AXIS["geodetic longitude (Lon)",east,
+                    ORDER[2],
+                    ANGLEUNIT["degree",0.0174532925199433]]]],
+    METHOD["CTABLE2"],
+    PARAMETERFILE["Latitude and longitude difference file","conus"],
+    OPERATIONACCURACY[0.15],
+    USAGE[
+        SCOPE["unknown"],
+        AREA["USA - CONUS including EEZ"],
+        BBOX[23.81,-129.17,49.38,-65.69]],
+    ID["DERIVED_FROM(EPSG)",1241]]
+
+
+
    +

  1. Export an object as a PROJJSON string

    2. +
+
projinfo GDA94 -o PROJJSON -q
+
+
+

Output:

+
{
+    "type": "GeographicCRS",
+    "name": "GDA94",
+    "datum": {
+        "type": "GeodeticReferenceFrame",
+        "name": "Geocentric Datum of Australia 1994",
+        "ellipsoid": {
+            "name": "GRS 1980",
+            "semi_major_axis": 6378137,
+            "inverse_flattening": 298.257222101
+        }
+    },
+    "coordinate_system": {
+        "subtype": "ellipsoidal",
+        "axis": [
+        {
+            "name": "Geodetic latitude",
+            "abbreviation": "Lat",
+            "direction": "north",
+            "unit": "degree"
+        },
+        {
+            "name": "Geodetic longitude",
+            "abbreviation": "Lon",
+            "direction": "east",
+            "unit": "degree"
+        }
+        ]
+    },
+    "area": "Australia - GDA",
+    "bbox": {
+        "south_latitude": -60.56,
+        "west_longitude": 93.41,
+        "north_latitude": -8.47,
+        "east_longitude": 173.35
+    },
+    "id": {
+        "authority": "EPSG",
+        "code": 4283
+    }
+}
+
+
+
    +

  1. Exporting the SQL statements to insert a new CRS in an auxiliary database.

    2. +
+
# Get the SQL statements for a custom CRS
+projinfo "+proj=merc +lat_ts=5 +datum=WGS84 +type=crs +title=my_crs" --output-id HOBU:MY_CRS -o SQL -q > my_crs.sql
+cat my_crs.sql
+
+# Initialize an auxiliary database with the schema of the reference database
+echo ".schema" | sqlite3 /path/to/proj.db | sqlite3 aux.db
+
+# Append the content of the definition of HOBU:MY_CRS
+sqlite3 aux.db < my_crs.db
+
+# Check that everything works OK
+projinfo --aux-db-path aux.db HOBU:MY_CRS
+
+
+

or more simply:

+
# Create an auxiliary database with the definition of a custom CRS.
+projinfo "+proj=merc +lat_ts=5 +datum=WGS84 +type=crs +title=my_crs" --output-id HOBU:MY_CRS --dump-db-structure | sqlite3 aux.db
+
+# Check that everything works OK
+projinfo --aux-db-path aux.db HOBU:MY_CRS
+
+
+

Output:

+
INSERT INTO geodetic_crs VALUES('HOBU','GEODETIC_CRS_MY_CRS','unknown','','geographic 2D','EPSG','6424','EPSG','6326',NULL,0);
+INSERT INTO usage VALUES('HOBU','USAGE_GEODETIC_CRS_MY_CRS','geodetic_crs','HOBU','GEODETIC_CRS_MY_CRS','PROJ','EXTENT_UNKNOWN','PROJ','SCOPE_UNKNOWN');
+INSERT INTO conversion VALUES('HOBU','CONVERSION_MY_CRS','unknown','','EPSG','9805','Mercator (variant B)','EPSG','8823','Latitude of 1st standard parallel',5,'EPSG','9122','EPSG','8802','Longitude of natural origin',0,'EPSG','9122','EPSG','8806','False easting',0,'EPSG','9001','EPSG','8807','False northing',0,'EPSG','9001',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,0);
+INSERT INTO usage VALUES('HOBU','USAGE_CONVERSION_MY_CRS','conversion','HOBU','CONVERSION_MY_CRS','PROJ','EXTENT_UNKNOWN','PROJ','SCOPE_UNKNOWN');
+INSERT INTO projected_crs VALUES('HOBU','MY_CRS','my_crs','','EPSG','4400','HOBU','GEODETIC_CRS_MY_CRS','HOBU','CONVERSION_MY_CRS',NULL,0);
+INSERT INTO usage VALUES('HOBU','USAGE_PROJECTED_CRS_MY_CRS','projected_crs','HOBU','MY_CRS','PROJ','EXTENT_UNKNOWN','PROJ','SCOPE_UNKNOWN');
+
+
+
PROJ.4 string:
++proj=merc +lat_ts=5 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +type=crs
+
+WKT2:2019 string:
+PROJCRS["my_crs",
+    BASEGEOGCRS["unknown",
+        ENSEMBLE["World Geodetic System 1984 ensemble",
+            MEMBER["World Geodetic System 1984 (Transit)"],
+            MEMBER["World Geodetic System 1984 (G730)"],
+            MEMBER["World Geodetic System 1984 (G873)"],
+            MEMBER["World Geodetic System 1984 (G1150)"],
+            MEMBER["World Geodetic System 1984 (G1674)"],
+            MEMBER["World Geodetic System 1984 (G1762)"],
+            ELLIPSOID["WGS 84",6378137,298.257223563,
+                LENGTHUNIT["metre",1]],
+            ENSEMBLEACCURACY[2.0]],
+        PRIMEM["Greenwich",0,
+            ANGLEUNIT["degree",0.0174532925199433]],
+        ID["HOBU","GEODETIC_CRS_MY_CRS"]],
+    CONVERSION["unknown",
+        METHOD["Mercator (variant B)",
+            ID["EPSG",9805]],
+        PARAMETER["Latitude of 1st standard parallel",5,
+            ANGLEUNIT["degree",0.0174532925199433],
+            ID["EPSG",8823]],
+        PARAMETER["Longitude of natural origin",0,
+            ANGLEUNIT["degree",0.0174532925199433],
+            ID["EPSG",8802]],
+        PARAMETER["False easting",0,
+            LENGTHUNIT["metre",1],
+            ID["EPSG",8806]],
+        PARAMETER["False northing",0,
+            LENGTHUNIT["metre",1],
+            ID["EPSG",8807]]],
+    CS[Cartesian,2],
+        AXIS["(E)",east,
+            ORDER[1],
+            LENGTHUNIT["metre",1]],
+        AXIS["(N)",north,
+            ORDER[2],
+            LENGTHUNIT["metre",1]],
+    ID["HOBU","MY_CRS"]]
+
+
+
    +

  1. Get the WKT representation of EPSG:25832 in the WKT1:GDAL output format and on a single line

    2. +
+
projinfo -o WKT1:GDAL --single-line EPSG:25832
+
+
+

Output:

+
WKT1:GDAL string:
+PROJCS["ETRS89 / UTM zone 32N",GEOGCS["ETRS89",DATUM["European_Terrestrial_Reference_System_1989",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6258"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4258"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","25832"]]
+
+
+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/apps/projsync.html b/apps/projsync.html new file mode 100644 index 00000000..dd542a57 --- /dev/null +++ b/apps/projsync.html @@ -0,0 +1,325 @@ + + + + + + + projsync — PROJ 9.0.0 documentation + + + + + + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

projsync

+
+

New in version 7.0.0.

+
+

Tool for synchronizing PROJ datum and transformation support data.

+
+

Synopsis

+
+
+
projsync
+
+
[–endpoint URL]
+
[–local-geojson-file FILENAME]
+
([–user-writable-directory] | [–system-directory] | [–target-dir DIRNAME])
+
[–bbox west_long,south_lat,east_long,north_lat]
+
[–spatial-test contains|intersects]
+
[–source-id ID] [–area-of-use NAME]
+
[–file NAME]
+
[–all] [–exclude-world-coverage]
+
[–quiet | –verbose] [–dry-run] [–list-files]
+
[–no-version-filtering]
+
+
+
+
+
+

Description

+

projsync is a program that downloads remote resource files +into a local directory. This is an alternative to downloading a proj-data-X.Y.Z +archive file, or using the on-demand networking capabilities of PROJ.

+

The following control parameters can appear in any order:

+
+
+--endpoint URL
+

Defines the URL where to download the master files.geojson file and then +the resource files. Defaults to the value set in proj.ini

+
+ +
+
+--local-geojson-file FILENAME
+

Defines the filename for the master GeoJSON files that references resources. +Defaults to ${endpoint}/files.geojson

+
+ +
+
+--user-writable-directory
+

Specifies that resource files must be downloaded in the +user writable directory. This is the default.

+
+ +
+
+--system-directory
+

Specifies that resource files must be downloaded in the +${installation_prefix}/share/proj directory. The user launching projsync +should make sure it has writing rights in that directory.

+
+ +
+
+--target-dir DIRNAME
+

Directory into which resource files must be downloaded.

+
+ +
+
+--bbox west_long,south_lat,east_long,north_lat
+

Specify an area of interest to restrict the resources to download. +The area of interest is specified as a +bounding box with geographic coordinates, expressed in degrees in a +unspecified geographic CRS. +west_long and east_long should be in the [-180,180] range, and +south_lat and north_lat in the [-90,90]. west_long is generally lower than +east_long, except in the case where the area of interest crosses the antimeridian.

+
+ +
+
+--spatial-test contains|intersects
+

Specify how the extent of the resource files +are compared to the area of use specified explicitly with --bbox. +By default, any resource files whose extent intersects the value specified +by --bbox will be selected. +If using the contains strategy, only resource files whose extent is +contained in the value specified by --bbox will be selected.

+
+ +
+
+--source-id ID
+

Restrict resource files to be downloaded to those whose source_id property +contains the ID value. Specifying ? as ID will list all possible values.

+
+ +
+
+--area-of-use NAME
+

Restrict resource files to be downloaded to those whose area_of_use property +contains the NAME value. Specifying ? as NAME will list all possible values.

+
+ +
+
+--file NAME
+

Restrict resource files to be downloaded to those whose name property +contains the NAME value. Specifying ? as NAME will list all possible values.

+
+ +
+
+--all
+

Ask to download all files.

+
+ +
+
+--exclude-world-coverage
+

Exclude files which have world coverage.

+
+ +
+
+-q / --quiet
+

Quiet mode

+
+ +
+
+--verbose
+
+

New in version 8.1.

+
+

Verbose mode (more than default)

+
+ +
+
+--dry-run
+

Simulate the behavior of the tool without downloading resource files.

+
+ +
+
+--list-files
+

List file names, with the source_id and area_of_use properties.

+
+ +
+
+--no-version-filtering
+
+

New in version 8.1.

+
+

By default, projsync only downloads files that are compatible of +the PROJ_DATA.VERSION metadata of proj.db, taking into account the +version_added and version_removed properties of entries in files.geojson. +When specifying this switch, all files referenced in files.geojson +will be candidate (combined with other filters).

+
+ +

At least one of --list-files, --file, --source-id, +--area-of-use, --bbox or --all must be specified.

+

Options --file, --source-id, --area-of-use and +--bbox are combined with a AND logic.

+
+
+

Examples

+
    +

  1. Download all resource files

    2. +
+
projsync --all
+
+
+
    +

  1. Download resource files covering specified point and attributing to an agency

    2. +
+
projsync --source-id fr_ign --bbox 2,49,2,49
+
+
+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file -- cgit v1.2.3