projinfo answers the question people usually skip: is this actually the CRS you think it is. By the end you will have a repeatable workflow for inspecting coordinate reference systems (CRSs), comparing transformations, and exporting a machine-readable definition. The examples use projinfo from PROJ 9.4.0, installed here as the Debian package proj-bin 9.4.0-1build2.
Allow about fifteen minutes. You need a shell and the proj-bin command. The normal queries are read-only and need no sudo. This guide does not edit proj.db, download grids, or change PROJ configuration.
Start by confirming the executable and its resource directories are the ones you expect:
$ command -v projinfo
/usr/bin/projinfo
$ dpkg-query -W -f='${Package} ${Version}\n' proj-bin proj-data
proj-bin 9.4.0-1build2
proj-data 9.4.0-1build2
$ projinfo --searchpaths
/home/your-user/.local/share/proj
/usr/share/projThe first path is user-specific. What matters is that a system resource directory shows up and the package versions are visible. This particular build does not accept --version: an unrecognised option just prints the usage text, so use the package query above for the version instead.
Pass an authority and code as the object definition. EPSG:4326 is the familiar WGS 84 geographic CRS:
$ projinfo EPSG:4326
PROJ.4 string:
+proj=longlat +datum=WGS84 +no_defs +type=crs
WKT2:2019 string:
GEOGCRS["WGS 84", ...]The full output includes the PROJ string and a multiline WKT2:2019 definition. Treat the PROJ string as an interchange result, not a promise that every consumer handles axis order or datum details the same way. Need a format for software to consume? Pick it explicitly rather than scraping labels off the default display.
For a compact pipeline, select PROJJSON and quiet mode:
$ projinfo EPSG:4326 -o PROJJSON -q | sed -n '1,8p'
{
"$schema": "https://proj.org/schemas/v0.7/projjson.schema.json",
"type": "GeographicCRS",
"name": "WGS 84",
"datum_ensemble": {
"name": "World Geodetic System 1984 ensemble",-q only works for a single-object query with one output format selected. It strips the introductory label, which makes the result safer to pipe into another tool. The sed command above just shortens the display; it does not touch the JSON itself.
Use -s for the source CRS and -t for the target. Add an area when location affects which operation is appropriate:
$ projinfo -s EPSG:4326 -t EPSG:3857 \
--bbox -1,50,1,52 --summary
Candidate operations found: 1
EPSG:3856, Popular Visualisation Pseudo-Mercator, 0 m, World.The bounding box is west,south,east,north, in degrees; here it covers a small patch of southern Britain. The summary keeps the operation name, stated accuracy and area of use visible, without dumping every candidate's full PROJ and WKT text.
There is a subtle default lurking here. Without an explicit area, PROJ 9.4 uses the smallest relevant CRS area of use by default. Make that choice explicit with --crs-extent-use, or use --area "USA - Missouri" when a named database area reads clearer. Do not pass --area and --bbox together: they are alternatives, not a combination.
Some transformations depend on horizontal or vertical shift grids. Candidate operations can still show up when a grid is missing, but that absence affects ordering and filtering. Check the current network setting before you draw conclusions from a result:
$ projinfo --remote-data
Status: disabled
Reason: not enabled in proj.ini or PROJ_NETWORK=ON not specifiedWith network access disabled, the default grid strategy is sort: candidates stay available, but operations whose grids are missing from the PROJ resource directories get pushed lower in the results. --grid-check discard_missing is useful when you need only locally usable candidates. --grid-check none switches off the availability check entirely, which means it can happily report an operation that cannot actually run on this host.
Do not flip network access on just to make a query look tidier. If a workflow genuinely needs remote grids, decide that policy separately, weigh the source and storage implications, then test the real transformation. Nothing in this guide makes a persistent change, so there is nothing here to undo.
Got a PROJ string or WKT with no authority code attached? --identify asks the local PROJ database for close matches:
$ projinfo --identify \
'+proj=utm +zone=31 +datum=WGS84 +type=crs' | sed -n '1,12p'
PROJ.4 string:
+proj=utm +zone=31 +datum=WGS84 +units=m +no_defs +type=crs
WKT2:2019 string:
PROJCRS["unknown", ...]Identification is a lookup with an approximate likelihood attached, not proof that the input is the named CRS. Inspect the full candidates and their areas before you swap a definition into a dataset or configuration. A CRS name can also be ambiguous, so an authority code beats a name whenever one is available.
Use --list-crs to browse the installed database, and add a filter when the unfiltered list is too much:
$ projinfo --list-crs projected | sed -n '1,5p'
EPSG:2000 "Anguilla 1957 / British West Indies Grid"
EPSG:2001 "Antigua 1943 / British West Indies Grid"
EPSG:2002 "Dominica 1945 / British West Indies Grid"
EPSG:2003 "Grenada 1953 / British West Indies Grid"Filters include geographic, geographic_2d, geographic_3d, vertical, projected and compound. Results depend on the installed database and can be narrowed further with --authority or an area constraint.
For a legacy consumer that insists on one-line WKT1:GDAL, make both choices explicit:
$ projinfo -o WKT1:GDAL --single-line EPSG:25832
WKT1:GDAL string:
PROJCS["ETRS89 / UTM zone 32N",GEOGCS["ETRS89", ...]--single-line changes presentation, not the CRS. Keep the normal multiline output for review, version control and error diagnosis, and reach for PROJJSON when the receiving program supports it and you need structured fields rather than legacy text.
projinfo queries definitions and operations; it does not process coordinate values. Use cs2cs for that.--aux-db-path; never overwrite the system proj.db as a shortcut.proj-bin and proj-data versions and resource paths.