[QGIS-Developer] Status of transaction support in Geopackages

Wed Feb 28 03:06:42 PST 2018

Hi Luigi,
I think you summed up things right.

For the sake of the thread readability, I re-post Mark's answer that for
some reason was not considered a response to this thread by the mailman
list.

------

Feb 27, 2018; 1:47pm

>> Do you have a link to the issues? Does it ignore them or worse?

The original report was 3 years ago and is still active:

https://issues.qgis.org/issues/12479

It was also a topic of a QGIS Grant Applications - August 2016
'Correction of QgsOgrProvider implementaion of GDAL 2.0'

A pull request was offered about Oct/Nov 2016 for Qgis 2.18 so that the
corrected code would be used for the start of Qgis 3.0 - but refused
because it was considered an api change.

Around April 2017 I saw that in Qgis 3.0 had still not been corrected,
despite the many changes that had been made.

Up to then I had been using a gdal version adapted to support writable
SpatialViews, that had not been accepted by gdal. But due to the evolvement
of gdal was becoming to difficult to maintain.

Around June I started work on the Spatialite-Provider, with consultations
with Alessandro Furieri (Sandro) of the Spatialite project about the future
needs, of what is now being termed, as Spatialite 5.0.

>> Having you all on the same code base is a neat solution I think.
Not when the 1 Provider (Ogr) will only offer partial results.
Writable SpatialView has existed since Spatialite 2.4 (we now have 4.3) and
there is no sign that Ogr will support this in the near future.

With Spatialite 5.0, where the world of Vector/Rasters, with Se/Sld Styles
are being brought togeather, this will become more difficult to deal with
with the separated gdal/ogr providers for all aspects of what can be done.

>> the amount of work to review the massive PRs was a limiting factor to
have that merged.
>> Do you have plans to ease that review process?
At the moment I am completing the last stage (of originally 4 stages) of
development (Database Maintenance, adding/renaming of columns etc.).

I have also started work on a Pdf which should help as an orientation as to
what the changes are and the reasons why.
One point I wrote this morning is: 'The Spatialite 5.0 Layout is similar in
nature to WMS/WFS 'getCapabilities', combining Vector, Raster and
Se/Sld-Styles.'

One goal is that such a Pdf should assist any reviewer who is willing to
work through this.

A major problem is also, that since Spatialite 5 has not yet been release,
it is difficult to understand why these massive changes are needed. So the
reluctance it is no surprise to me.

But the facts remain:
a) The present Spatialite-Provider is better than the Ogr support for
Spatialite
b) The present Spatialite-Provider will not be able deal will with what
Spatialite 5 offers

Although I myself am not a co-developer of Spatialite (more like a
collaborator), I intend to keep this up to-date with future developments.
It is also likely that Sandro will take a closer look after the present
development phase is over.

Mark Johnson, Berlin Germany

-

2018-02-28 11:30 GMT+01:00 Luigi Pirelli <luipir at gmail.com>:

> I agree about GDLA/OGR, and are the positions already expressed in the
> Mark's PR
>
> but take into account that:
>
> 1) maintainer could be Mark (as for other core plugins e.g.
> MetaSearch). I agree that having only a maintainer for a complex core
> part can be dangerous for quality of the overall project => agree with
> Regis, could be a PSC decision.
> 2) The code is already there and should overpass some sqlite
> limitations not present in spatialite giving professional opportunity
> right now (but also reducing the hability to rise funds for a OGR
> solution :( )
> 3) It can be compiled or packaged optionally
> 4) Marks seems not focusing on work on GDAL/OGR
>
> btw without reviewers it's hard to have any merge
> Luigi Pirelli
>
> ************************************************************
> **************************************
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS 2nd Edition:
> * https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-qgis-second-edition
> * Hire me: http://goo.gl/BYRQKg
> ************************************************************
> **************************************
>
>
> On 27 February 2018 at 21:40, Alessandro Pasotti <apasotti at gmail.com>
> wrote:
> > On Tue, Feb 27, 2018 at 12:21 PM, Luigi Pirelli <luipir at gmail.com>
> wrote:
> >>
> >> >
> >> > On 27/02/2018 11:12, Mark Johnson wrote:
> >> >>>> that we get rid of the current provider and rely on GDAL only.
> >> >>
> >> >> With the 'current provider' I assume you mean the
> Spatialite-Provider.
> >> >>
> >> >> Please remember that the Spatialite-Provider was never designed to
> >> >> support GeoPackage.
> >> >>
> >> >> Please also remember that Gdal/Ogr does not support all aspects of
> >> >> Spatialite
> >> >> - writable SpatialViews are not supported
> >> >>
> >> >> The present QgsOgrProvider does not support Spatialite-Tables with
> more
> >> >> than 1 geometry properly.
> >> >
> >> > Would it be possible to add these to the QgsOgrProvider, or are there
> >> > some limitations ?
> >>
> >> Hi Hugo
> >>
> >> Some technical opinion are available in related PR done by Mark to
> >> propose a new Spatialite provider.
> >> The general opinion is to check before if it make sense to remove
> >> spatialite limitations in the gdal provider to sqlite.
> >> There are also opinon that the PR is actually not so simple to review,
> >> for the complexity and extension. Oslandia can do it if apport more to
> >> his business.
> >>
> >> IMHO I can't see any problem to merge it after review and have a new
> >> or parallel spatialite provicer.
> >>
> >
> > Well, I do: I think that unless there is an overwhelming technical
> reason to
> > take a different route, QGIS should not create alternative providers
> where
> > OGR/GDAL can do the job.
> >
> > The reason is both in how open source works: building wonderful
> applications
> > on top of wonderful libraries (GDAL/OGR in this case) and in how we
> should
> > avoid to enlarge the code base without a valid reason.
> >
> > The right approach in this particular case is IMHO to work with OGR/GDAL
> to
> > add the missing features in the base libraries or to improve the existing
> > QGIS providers if the problems is in them, this will prevent duplication
> and
> > lower the maintenance efforts on the shoulders of QGIS developers.
> >
> >
> > --
> > Alessandro Pasotti
> > w3:   www.itopen.it
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180228/1201b511/attachment.html>