[Qgis-developer] QEP/RFC sqlite virtual tables

Matthias Kuhn matthias.kuhn at gmx.ch
Wed Oct 29 00:34:11 PDT 2014


Hi Régis,

On 28.10.2014 17:35, Régis Haubourg wrote:
> Hi all, 
> this is a very high level topic for me. I will just point out some
> user/funder needs, and maybe try to describe other strategies exist in GIS
> softs. 
>
> As a user coming from both ESRI and Mapinfo world:
>
>  - The main (and last?) real advantage of MI was its native pseudo-SQL
> capabilities (with many limitations). Users really often now have a
> centralized spatialDB, where the administrator can do many things (almost
> everything in fact), but the classical user has only two possibilies for
> relation Db treatments: algorithms or duplicate data in sqlite and learn
> spatial sql (unless their DBA grant them to Postgres... ). Power users are
> very happy, ex MI users are not in QGIS. 

I've also heard that from others. I think it's a very valid requirement
and pretty much what QEP/RFC 5 by Hugo proposes.

>
> - Arcgis have no agregate capabilities over its relations.. Joins are more
> developped and allow summarize algoithms. To go further, It requires using
> an external DB system, and it's a pain (they all have limitations, in term
> of cost or learning curve..). Postgis/sqlite is far away in terms of
> accessibility
>
> Having virtual sqlite tables would allow some MI-like behaviour. Users here
> would appreciate that a lot (I will still be using postgres underneath for
> perfs).

And that's where my main questionmarks are: Will this implementation be
able to make use of postgres capabilities? In particular, a postgres
database has a higher constant per-request cost in comparison to local
data (network roundtrip vs file access) but makes this up through
efficient filtering/aggregation. And if there are problem, how many
possibilities do we have to improve the situation.

>  For more simple use cases, some only want to improve joins by being able to
> join and output agregate values if multiples tuples join, for simple mapping
> purposes. I think UI needs boths things, a SQL dialog to create queries -
> Qspatialite-like - on every table, and some agregate capabilities over
> joins. 
>  What we must avoid is having two different implementations, with differents
> limitations. Only power users knowing what is really happening underneath
> will know what function to use, which is bad in UX terms. 
> A comparison is OGR CSV driver versus CSV plugin... User has to know that
> both tools are differents, behaves differently with a different providers.
> Nothing in the GUI let you know that except try-fail approach.

The problem is that we have one proposal which can be available soon
with lots of functionality and a not-too-hard implementation. But we/I
lack knowledge if it performs well in every scenario and if it offers
the possibility to optimize.

>
> BTW, I have the feeling you don't disagree at all but that we are digging
> one of the harder features of a GIS tool. IMHO, that really desserves
> discussions, prooves of concept.  Any other opinions in dev's?

I also don't think it's disagreement, it's evaluation of risks/chances
involved by either of the two.

Best
Matthias

-- 
Help getting QGIS to the next level of quality before November 15!
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing




More information about the Qgis-developer mailing list