[gdal-dev] Plan for a next Spatialite release ? Should the community fork it ?

Even Rouault even.rouault at spatialys.com
Wed Jul 1 08:42:23 PDT 2020


Hi Sandro,

I hope this emails finds you, and you are doing well. We had a few exchanges in private over 
past months about a next Spatialite release, but I'm still unclear on when a next release will 
materialize, hence this public call, with the Spatialite list, and GDAL and QGIS communities 
CC'ed. The intend of this email is to be constructive hopefully.

Downstream projects of Spatialite will have soon a critical need for a new release of 
Spatialite, as there is no released version of Spatialite that uses the PROJ >= 6 API. Spatialite 
4.3.0a, the latest stable release, dating from almost 5 years now, and uses the deprecated 
proj_api.h.
proj_api.h should normally have been removed in March this year, for PROJ 7.0, as announced 
2.5 years ago, but this was defered, mostly because Spatialite wasn't ready yet. PROJ 8, 
planned for March 2021, will certainly remove proj_api.h, so we will have an issue if no 
Spatialite release has been done in the meantime.

If no new Spatialite release is to happen soon, I can see 2 potential solutions:

a) drop Spatialite support from GDAL and QGIS. That would be a fair amount of work, and a 
functional regression for both projects. Besides support for the Spatialite format itself, both 
GDAL and QGIS benefit from its SQL spatial function to do analysis on GeoPackage files for 
example. There are also hidden dependencies to Spatialite, like the QGIS WFS client using 
Spatialite internally to do local caching of downloaded features.

b) or do a community fork of the current state of the Spatialite fossil repository, which 
implements the needed PROJ >= 6 support. This is certainly not an ideal solution, as that 
could create confusion on users on where the "official" Spatialite is. I would not call this a 
"hostile" fork, but more a "pragmatic" fork... If I were to do it, this would probably be a github 
repo, to make contributions from the community easier. But beyond the question of forking 
or not, I do think using github (or gitlab) for the official project would make it easier to foster 
collaboration.

Can you tell us about your plan and a realistic schedule for a Spatialite (would that be 5.0 or 
6.0 ?) release ? Can the community help somehow ? Is there anything preventing from 
releasing current fossil repo now ? If that may related to new features not yet implemented 
you've in mind and that you would like to land in a release, can't they wait after a release has 
been done with what exists already in Fossil ?

I'd say that if things don't seem to be moving, I'd probably go myself to implement solution b) 
this fall, hopefully with support of others devs reading this email as I'm already more than 
busy on other OSS projects.

Cheers,

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200701/4942d9d6/attachment.html>


More information about the gdal-dev mailing list