D 2019-04-16T11:53:16.392
L PROJ.6
U sandro
W 8641
<a href="https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.3.0-doc">back</a><hr><br>
<h1>Introduction</h1>
<b>PROJ</b> is a well-known library for performing conversions between cartographic projections.<br>
It's universally supported by almost all open source GIS-oriented applications and packages, so there is no need to waste time in futher presentations.<br>
We just need a bit of history to fully understand the current state-of-the-art:<br><br>
Timeline:
<ul>
<li>Very few users and developers do really realize how ancient is PROJ, and how far in time it started moving its first steps.</li>
<li>in <b>1980</b> (about 40 years ago) Gerald Evenden started working on the very first PROJ version, and at the time it was a Ratfor program.</li>
<li>in <b>1985</b> the code was completely rewritten in C to run on UNIX systems, and it was named <b>PROJ.2</b>.</li>
<li>in <b>1990</b> was released an updated version named <b>PROJ.3</li>
<li>in <b>1994</b> a more advanced version was released, and it was obviously named <b>PROJ.4</b></li>
<li>in <b>1995</b> Evenden stopped any further development activity and the project become inactive for several years.</li>
<li>in <b>2000</b> Frank Warmerdam bacame the new maintainer and released version <b>4.4</b></li>
<li>After this reborn the revitalized project continued to be regularly maintained, but no further relevant improvements were introduced.<br>
PROJ.4 just continued its very placid evolution in a substantially conservative way.</li>
</ul><br>
<b><u>Short conclusion</u></b>: the fourth version of PROJ (aka <b>PROJ.4</b>) lasted for about two decades, a very uncommon situation.<br>
And a full generation of developers and users become sincerly convinced that PROJ.4 was the real name of the library.
<h3>The revolution comes</h3>
Timeline:
<ul>
<li>in <b>2018</b> Even Rouault, Kristian Evers and others start developing a revolutionized PROJ supporting many relevant innovations.<br>
<b>PROJ.5</b> is intended to be the first preliminary step of a more complex evolution schema.</li>
<li>on <b>March 2019</b> a more mature version is released, and it's <b>PROJ.6</b></li>
<li>Next year (2020) <b>PROJ.7</b> is expected to be released, and it will fully complete the transition between the old and new architectures.</li>
</ul>
<br>
<b><u>Note</u></b>: the whole transition implies many relevant changes, so that a deeply revised API will be required.
In other words, the old <b>PROJ.4</b> and the new <b>PROJ.7</b> will support two different APIs, thus abruptly breaking cross-version compatibility.<br>
This is an umpleasant new, because it practically means that all software modules depending on PROJ (this including SpatiaLite) will require a not at all trivial rewrite in order to fulfill the new API requirements.<br>
But when you consider that's the first time in its very long life that PROJ requires an extra effrot in order to introduce so many useful innovations, this unexpected API breakage looks fully justified and absolutely reasonable.<br><br>
<b><u>More details about the API breakage</u></b>:
<ul>
<li><b>PROJ.5</b> started introducing the new API, but was still able to support the old traditional API without any complaint.</li>
<li><b>PROJ.6</b> have depreceted the old traditional API.<br>
It still continues to be reluctanctly supported, but the library requires to be compiled by explicitly defining a <b>-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H=1</b> directive in order to effectively enable this option.</li>
<li>and finally the next-to-come <b>PROJ.7</b> will completely get rid of the old API.</li>
</ul>
<br>
<hr>
<h1>What's new in PROJ.6</h1>
Old versions of PROJ (including <b>PROJ.4</b>) required to define each <b>CRS</b> (<i>Coordinate Reference System</i>) by a corresponding <b>proj-string</b>.
The following table exemplifies the case of few CRSes:<br><br>
<table cellspacing="8" cellpadding="8" bgcolor="#d0ffd0" border="1">
<tr><th>SRID</th><th>CRS Name</th><th>proj-string</th></tr>
<tr><td align="right">3003</td><td>Monte Mario / Italy zone 1</td>
<td>+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs</td></tr>
<tr><td align="right">4326</td><td>WGS 84</td>
<td>+proj=longlat +datum=WGS84 +no_defs</td></tr>
<tr><td align="right">32632</td><td>WGS 84 / UTM zone 32N</td>
<td>+proj=utm +zone=32 +datum=WGS84 +units=m +no_defs</td>
</table>
<br><br>
New versions of PROJ (starting since <b>PROJ.6</b>) still continue to support the old <b>proj-strings</b>, but the preferred notation for defining any CRS is now conformant to the <b>ISO-19111:2019</b> international standard (<i>OGC Abstract Specification Topic 2: “Referencing By Coordinates”</i>).
The following table exemplifies the same CRSes as above in the ISO WKT notation:
<br><br>
<table cellspacing="8" cellpadding="8" bgcolor="#d0ffd0" border="1">
<tr><th>SRID</th><td>3003</td><td>4326</td><td>32632</td></tr>
<tr><th>CRS Name</th><td>Monte Mario / Italy zone 1</td></td><td>WGS 84</td><td>WGS 84 / UTM zone 32N</td></tr>
<tr><th>ISO-2018 WKT</th>
<td valign="top"><verbatim>
PROJCRS["Monte Mario / Italy zone 1",
BASEGEODCRS["Monte Mario",
DATUM["Monte Mario",<br>
ELLIPSOID["International 1924",6378388,297,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]]],
CONVERSION["Italy zone 1",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",9,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",1500000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],<br>
LENGTHUNIT["metre",1]],
AREA["Italy - west of 12°E"],
BBOX[36.53,5.94,47.04,12],
ID["EPSG",3003]]
</verbatim></td>
<td valign="top"><verbatim>
GEODCRS["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]],
AREA["World"],
BBOX[-90,-180,90,180],
ID["EPSG",4326]]
</verbatim></td>
<td valign="top"><verbatim>
PROJCRS["WGS 84 / UTM zone 32N",
BASEGEODCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]]],
CONVERSION["UTM zone 32N",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",9,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",500000,
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]],
AREA["World - N hemisphere - 6°E to 12°E - by country"],
BBOX[0,6,84,12],
ID["EPSG",32632]]
</verbatim></td>
</tr>
</table>
<br><br>
<br><br>
<hr><br>
<a href="https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.3.0-doc">back</a>
Z df105200a0eb19ffe17f9560b2b64eea