[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