Plans to handle PROJ 6

[Jeff McKenna]

Hi Sandro, all,

I just wanted to make sure that you are aware of significant changes in
the PROJ library, and its release on 2019-03-01 (see below for release
notes). Please let me know if you need me to file this in your issue
tracker, as it will be important for users that the next SpatiaLite (and
SpatiaLite-tools) supports PROJ 6.

Thanks again,

-jeff




-------- Forwarded Message --------


PROJ 6 has undergone extensive changes to increase its functional scope
from a
cartographic projection engine with so-called "early-binding" geodetic datum
transformation capabilities to a more complete library supporting coordinate
transformations and coordinate reference systems.

As a foundation for other enhancements, PROJ now includes a C++
implementation
of the modelisation propopsed by the ISO-19111:2019 standard / OGC Abstract
Specification Topic 2: "Referencing By Coordinates", for geodetic reference
frames (datums), coordinate reference systems and coordinate operations.
Construction and query of those geodetic objects is available through a
new C++
API, and also accessible for the most part from bindings in the C API.

Those geodetic objects can be imported and exported from and into the OGC
Well-Known Text format (WKT) in its different variants: ESRI WKT, GDAL
WKT 1,
WKT2:2015 (ISO 19162:2015) and WKT2:2018 (ISO 19162:2018). Import and
export of
CRS objects from and into PROJ strings is also supported. This functionality
was previously available in the GDAL software library (except WKT2 support
which is a new feature), and is now an integral part of PROJ.

A unified database of geodetic objects, coordinate reference systems and
their
metadata, and coordinate operations between those CRS is now available in a
SQLite3 database file, proj.db. This includes definitions imported from the
IOGP EPSG dataset (v9.6.0 release), the IGNF (French national mapping
agency)
geodetic registry and the ESRI projection engine database. PROJ is now the
reference software in the "OSGeo C stack" for this CRS and coordinate
operation
database, whereas previously this functionality was spread over PROJ,
GDAL and
libgeotiff, and used CSV or other adhoc text-based formats.

Late-binding coordinate operation capabilities, that takes metadata such as
area of use and accuracy into account, has been added. This can avoid in a
number of situations the past requirement of using WGS84 as a pivot system,
which could cause unneeded accuracy loss, or was not doable at all sometimes
when transformation to WGS84 was not available. Those late-binding
capabilities
are now used by the proj_create_crs_to_crs() function and the cs2cs utility.

A new command line utility, projinfo, has been added to query
information about
a geodetic object of the database, import and export geodetic objects
from/into
WKT and PROJ strings, and display coordinate operations available
between two
CRSs.

Download the source distribution here:

https://download.osgeo.org/proj/proj-6.0.0.tar.gz
https://download.osgeo.org/proj/proj-6.0.0.zip


In addition to the new version of PROJ we are also releasing new datum grid
packages:

proj-datumgrid-europe 1.2:

https://download.osgeo.org/proj/proj-datumgrid-europe-1.2.tar.gz
https://download.osgeo.org/proj/proj-datumgrid-europe-1.2.zip

Changes include: Grids covering the UK, France and Sweden.

proj-datumgrid-north-america 1.2:

https://download.osgeo.org/proj/proj-datumgrid-north-america-1.2.tar.gz
https://download.osgeo.org/proj/proj-datumgrid-north-america-1.2.zip

Changes include: NAD83 -> NAD83(HPGN) grids, GEOIDB12 grids and the
Canadian ntv2_0.gsb grid

proj-datumgrid-world 1.0

https://download.osgeo.org/proj/proj-datumgrid-world-1.0.tar.gz
https://download.osgeo.org/proj/proj-datumgrid-world-1.0.zip

This is the first version of the world wide package. Currently it
only holds
the EGM2008 geoid grid.

[linux...@gmail.com]

On Monday, March 18, 2019 at 8:17:30 PM UTC+1, Jeff McKenna wrote:

Please let me know if you need me to file this in your issue
tracker, as it will be important for users that the next SpatiaLite (and
SpatiaLite-tools) supports PROJ 6.

The issue already exists: https://www.gaia-gis.it/fossil/libspatialite/info/6eabdf0e6d3520a7

See also: https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status

Kind Regards,

Bas

[Jeff McKenna]

Great, thanks for sharing the ticket link here. It's good to discuss
these plans in the open here as well. -jeff

[linux...@gmail.com]

On Monday, March 18, 2019 at 9:01:13 PM UTC+1, Jeff McKenna wrote:

Great, thanks for sharing the ticket link here.  It's good to discuss
these plans in the open here as well.  -jeff

SpatiaLite needs to add support for the proj.h API, because proj_api.h will be removed in PROJ 7.0.0 due in March 2020.

With no final release of SpatiaLite since 4.3.0a on 2015-09-07, it looks likely that the spatialite family will hold back adoption of PROJ 7.0.0 because it will still rely on proj_api.h.

I hope that PROJ 6.0.0 support will be a reason to revitalise spatialite development, that we can expect a 5.0.0 final release before March 2020 proving that it's not vaporware like 4.4 and 4.5.

To quote part of my post on the PROJ list about SpatiaLite [0]:

"

 SpatiaLite is an important package in the geospatial ecosystem, but it
 is the sick child in the family. Perhaps it's time to take it out to not
 hold back the rest of the ecosystem.

 Perhaps when users are confronted with distributions removing spatialite
 they will be inclined to support its development. I suspect the lack of
 funding and/or a healthy group of active developers is causing the
 stagnation in the SpatiaLite family.

 If the removal of SpatiaLite seriously affects QGIS, they may be able
 allocate some of their funding to get SpatiaLite back into shape, at
 least for the sake of QGIS.

"

I'm seriously considering removing the spatialite packages from Debian to prevent them from becoming blockers for proj (and other packages in the geospatial stack).

[0] https://lists.osgeo.org/pipermail/proj/2019-March/008291.html

Kind Regards,

Bas

[Jeff McKenna]

I'm not sure that this was shared here: details of how the upcoming
spatialite 5.0.0 release fully supports PROJ6
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=PROJ.6

-jeff

[Bas Couwenberg]

On Monday, July 1, 2019 at 1:05:25 PM UTC+2, Jeff McKenna wrote:

I'm not sure that this was shared here: details of how the upcoming
spatialite 5.0.0 release fully supports PROJ6
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=PROJ.6

So far libspatialite 5.0.0 (a final release accompanied by spatialite-tools 5.0.0 & librttopo 1.1.0 at minimum) is not something likely to happen, certainly not before the PROJ 7 release.

Sandro & Sandro, please prove me wrong.

[Pirmin Kalberer]

Hi Sandro

On 18.03.19 21:50, linux...@gmail.com wrote:
[...]>

> I hope that PROJ 6.0.0 support will be a reason to revitalise spatialite
> development, that we can expect a 5.0.0 final release before March 2020
> proving that it's not vaporware like 4.4 and 4.5.

In contrast of Bas' repeated insults, which would violate any existing
Code of Conduct, I hope you also saw the very positive comments on
Twitter about your PROJ analysis. The latest one:
https://twitter.com/MarkusNeteler/status/1150017304714985473

Regards
Pirmin

[Micha Silver]

Indeed an excellent review of PROJ.6 and how it will impact spatialite.

We've come to expect that level of detail from Sandro, so this is a good opportunity to stop "taking for granted" and mention a word of thanks.

Regards
Pirmin

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918