<feed xmlns='http://www.w3.org/2005/Atom'>
<title>PROJ/include/proj/internal/esri_projection_mappings.hpp, branch 6.2.0</title>
<subtitle>Forked from https://github.com/OSGeo/PROJ</subtitle>
<link rel='alternate' type='text/html' href='https://git.otimperi.dev/PROJ/'/>
<entry>
<title>ISO19111: remove PROJ.5 specific format for CRS (refs #1214)</title>
<updated>2019-01-08T20:25:07+00:00</updated>
<author>
<name>Even Rouault</name>
<email>even.rouault@spatialys.com</email>
</author>
<published>2019-01-08T15:22:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.otimperi.dev/PROJ/commit/?id=f5e5435fd5071d550e0d13f7a5d71e09c1fab2c0'/>
<id>f5e5435fd5071d550e0d13f7a5d71e09c1fab2c0</id>
<content type='text'>
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720,
the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap
as an attempt of improving the PROJ.4 format used by GDAL and other products is
likely a dead-end since it is still lossy in many aspects and can cause confusion
with coodinate operations.

Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export.

Note: on the import side, I've kept the code that could parse unitconvert and
axisswap when building a CRS definition from a pipeline. It is there as a hidden
feature as it was kind of a tear to remove that code in case it might still be
useful...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720,
the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap
as an attempt of improving the PROJ.4 format used by GDAL and other products is
likely a dead-end since it is still lossy in many aspects and can cause confusion
with coodinate operations.

Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export.

Note: on the import side, I've kept the code that could parse unitconvert and
axisswap when building a CRS definition from a pipeline. It is there as a hidden
feature as it was kind of a tear to remove that code in case it might still be
useful...
</pre>
</div>
</content>
</entry>
<entry>
<title>Implement RFC 2: Initial integration of "GDAL SRS barn" work</title>
<updated>2018-11-14T21:48:29+00:00</updated>
<author>
<name>Even Rouault</name>
<email>even.rouault@spatialys.com</email>
</author>
<published>2018-11-14T16:40:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.otimperi.dev/PROJ/commit/?id=d928db15d53805d9b728b440079756081961c536'/>
<id>d928db15d53805d9b728b440079756081961c536</id>
<content type='text'>
This work mostly consists of:
- a C++ implementation of the ISO-19111:2018 / OGC Topic 2
  "Referencing by coordinates" classes to represent Datums,
  Coordinate systems, CRSs (Coordinate Reference Systems) and
  Coordinate Operations.
- methods to convert between this C++ modeling and WKT1, WKT2
  and PROJ string representations of those objects
- management and query of a SQLite3 database of CRS and Coordinate Operation definition
- a C API binding part of those capabilities

This is all-in-one squashed commit of the work of
https://github.com/OSGeo/proj.4/pull/1040
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This work mostly consists of:
- a C++ implementation of the ISO-19111:2018 / OGC Topic 2
  "Referencing by coordinates" classes to represent Datums,
  Coordinate systems, CRSs (Coordinate Reference Systems) and
  Coordinate Operations.
- methods to convert between this C++ modeling and WKT1, WKT2
  and PROJ string representations of those objects
- management and query of a SQLite3 database of CRS and Coordinate Operation definition
- a C API binding part of those capabilities

This is all-in-one squashed commit of the work of
https://github.com/OSGeo/proj.4/pull/1040
</pre>
</div>
</content>
</entry>
</feed>
