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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
