Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Il 28/05/2014 19:29, Régis Haubourg ha scritto: > - how much can we trust sqlite (the community doesn't seem too opened)? And are you talking about SQLite or SpatiaLite? > how stable library versions are (we've had many troubles with spatialite > versions) AFAIK there should be no major problem with SQLite versions. > - having redundant ways of doing the same thing is one of biggest criticism > of users here. Agreed. Thanks. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Not working mac nightly
Hi, The Mac QGIS nightly site has been updated: http://qgis.dakotacarto.com/ Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota On Wed, May 28, 2014 at 5:12 PM, Larry Shaffer wrote: > Hi Vincent, > > Under a normal compiling of QGIS, the psycopg2 Python package is not > installed, and is required to be installed by the user/developer. This is > different than the stable QGIS installer bundles from Kyngchaos.com, which > have other supporting libs and Python packages bundled in. Likewise, there > are no extra supporting installs for the Processing plugin, e.g. GRASS, > OTB, etc.. > > Adding all the supporting libs/packages would make the nightly > upload/download much, much larger. Also, the nightly is meant to be basic > build output for compiling and bundling, as defined by the CMake variable: > > QGIS_MACAPP_BUNDLE=2 > > If the supporting libs/packages are included in those CMake scripts [1], > then they are in the nightly, excepting instances where there are issues > building them or building against them with the latest master version. > > I will add information to the nightly download website that indicates what > extras components need locally installed. > > Kyngchaos.com has many of the required Python packages available as > installers [2]. > > [0] https://github.com/qgis/QGIS/blob/master/INSTALL#L1989-L1992 > [1] https://github.com/qgis/QGIS/tree/master/mac/cmake > [2] http://www.kyngchaos.com/software/python > > Regards, > > Larry Shaffer > Dakota Cartography > Black Hills, South Dakota > > > On Sun, May 25, 2014 at 2:07 AM, Vincent TINET wrote: > >> It is loading fine with Larry’s new version. >> >> Except that the psycopg2 python library is missing from the bundle. >> Processing (at least) is needing it to load. >> >> >> >> Le 24 mai 2014 à 14:10, Vincent TINET a écrit : >> >> > I tried to test the nightly builds a few days in a row and it doesn’t >> starts with the following error : >> > >> > Process: QGIS_2.3-dev [3186] >> > Path: >> /Volumes/VOLUME/QGIS_2.3-dev.app/Contents/MacOS/QGIS_2.3-dev >> > Identifier: org.qgis.qgis-dev >> > Version: ??? >> > Code Type: X86-64 (Native) >> > Parent Process: launchd [137] >> > Responsible: QGIS_2.3-dev [3186] >> > User ID: 501 >> > >> > Date/Time: 2014-05-24 14:08:16.406 +0200 >> > OS Version: Mac OS X 10.9.3 (13D65) >> > Report Version: 11 >> > Anonymous UUID: 898BFD97-214E-074A-83DA-63349E20 >> > >> > Sleep/Wake UUID: 074ECD49-01FF-408E-8E93-087F7A4E4776 >> > >> > Crashed Thread: 0 >> > >> > Exception Type: EXC_BREAKPOINT (SIGTRAP) >> > Exception Codes: 0x0002, 0x >> > >> > Application Specific Information: >> > dyld: launch, loading dependent libraries >> > >> > Dyld Error Message: >> > Library not loaded: QtSvg.framework/Versions/4/QtSvg >> > Referenced from: >> /Volumes/VOLUME/QGIS_2.3-dev.app/Contents/MacOS/lib/libqwt.dylib >> > Reason: image not found >> > >> > Binary Images: >> >0x7fff6c4d4000 - 0x7fff6c507817 dyld (239.4) >> <042C4CED-6FB2-3B1C-948B-CAF2EE3B9F7A> /usr/lib/dyld >> >0x7fff89306000 - 0x7fff89306fff com.apple.ApplicationServices >> (48 - 48) <3E3F01A8-314D-378F-835E-9CC4F8820031> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices >> >0x7fff8caa3000 - 0x7fff8caf1ff9 libstdc++.6.dylib (60) >> <0241E6A4-1368-33BE-950B-D0A175C41F54> /usr/lib/libstdc++.6.dylib >> >0x7fff8d29c000 - 0x7fff8d481fff com.apple.CoreFoundation (6.9 - >> 855.16) >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> >0x7fff8e6e6000 - 0x7fff8e752fff com.apple.framework.IOKit >> (2.0.1 - 907.100.13) <057FDBA3-56D6-3903-8C0B-849214BF1985> >> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit >> >0x7fff92c58000 - 0x7fff92c59ff7 libSystem.B.dylib (1197.1.1) >> /usr/lib/libSystem.B.dylib >> >0x7fff930a5000 - 0x7fff930a5fff com.apple.CoreServices (59 - >> 59) <7A697B5E-F179-30DF-93F2-8B503CEEEFD5> >> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices >> >0x7fff93268000 - 0x7fff93280fff libexpat.1.dylib (12) >> <97F4A9A7-CB3E-3BBF-9314-4997FC770E52> /usr/lib/libexpat.1.dylib >> >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Not working mac nightly
Hi Vincent, Under a normal compiling of QGIS, the psycopg2 Python package is not installed, and is required to be installed by the user/developer. This is different than the stable QGIS installer bundles from Kyngchaos.com, which have other supporting libs and Python packages bundled in. Likewise, there are no extra supporting installs for the Processing plugin, e.g. GRASS, OTB, etc.. Adding all the supporting libs/packages would make the nightly upload/download much, much larger. Also, the nightly is meant to be basic build output for compiling and bundling, as defined by the CMake variable: QGIS_MACAPP_BUNDLE=2 If the supporting libs/packages are included in those CMake scripts [1], then they are in the nightly, excepting instances where there are issues building them or building against them with the latest master version. I will add information to the nightly download website that indicates what extras components need locally installed. Kyngchaos.com has many of the required Python packages available as installers [2]. [0] https://github.com/qgis/QGIS/blob/master/INSTALL#L1989-L1992 [1] https://github.com/qgis/QGIS/tree/master/mac/cmake [2] http://www.kyngchaos.com/software/python Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota On Sun, May 25, 2014 at 2:07 AM, Vincent TINET wrote: > It is loading fine with Larry’s new version. > > Except that the psycopg2 python library is missing from the bundle. > Processing (at least) is needing it to load. > > > > Le 24 mai 2014 à 14:10, Vincent TINET a écrit : > > > I tried to test the nightly builds a few days in a row and it doesn’t > starts with the following error : > > > > Process: QGIS_2.3-dev [3186] > > Path: > /Volumes/VOLUME/QGIS_2.3-dev.app/Contents/MacOS/QGIS_2.3-dev > > Identifier: org.qgis.qgis-dev > > Version: ??? > > Code Type: X86-64 (Native) > > Parent Process: launchd [137] > > Responsible: QGIS_2.3-dev [3186] > > User ID: 501 > > > > Date/Time: 2014-05-24 14:08:16.406 +0200 > > OS Version: Mac OS X 10.9.3 (13D65) > > Report Version: 11 > > Anonymous UUID: 898BFD97-214E-074A-83DA-63349E20 > > > > Sleep/Wake UUID: 074ECD49-01FF-408E-8E93-087F7A4E4776 > > > > Crashed Thread: 0 > > > > Exception Type: EXC_BREAKPOINT (SIGTRAP) > > Exception Codes: 0x0002, 0x > > > > Application Specific Information: > > dyld: launch, loading dependent libraries > > > > Dyld Error Message: > > Library not loaded: QtSvg.framework/Versions/4/QtSvg > > Referenced from: > /Volumes/VOLUME/QGIS_2.3-dev.app/Contents/MacOS/lib/libqwt.dylib > > Reason: image not found > > > > Binary Images: > >0x7fff6c4d4000 - 0x7fff6c507817 dyld (239.4) > <042C4CED-6FB2-3B1C-948B-CAF2EE3B9F7A> /usr/lib/dyld > >0x7fff89306000 - 0x7fff89306fff com.apple.ApplicationServices > (48 - 48) <3E3F01A8-314D-378F-835E-9CC4F8820031> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > >0x7fff8caa3000 - 0x7fff8caf1ff9 libstdc++.6.dylib (60) > <0241E6A4-1368-33BE-950B-D0A175C41F54> /usr/lib/libstdc++.6.dylib > >0x7fff8d29c000 - 0x7fff8d481fff com.apple.CoreFoundation (6.9 - > 855.16) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > >0x7fff8e6e6000 - 0x7fff8e752fff com.apple.framework.IOKit (2.0.1 > - 907.100.13) <057FDBA3-56D6-3903-8C0B-849214BF1985> > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > >0x7fff92c58000 - 0x7fff92c59ff7 libSystem.B.dylib (1197.1.1) > /usr/lib/libSystem.B.dylib > >0x7fff930a5000 - 0x7fff930a5fff com.apple.CoreServices (59 - 59) > <7A697B5E-F179-30DF-93F2-8B503CEEEFD5> > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > >0x7fff93268000 - 0x7fff93280fff libexpat.1.dylib (12) > <97F4A9A7-CB3E-3BBF-9314-4997FC770E52> /usr/lib/libexpat.1.dylib > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
How about querying the sqlite_master table to find the data type? And why not use the constraints found in this query to set up the qgis relations? -Bob (aka cgs_bob on freenode) On May 27, 2014 6:04 AM, "Régis Haubourg" < regis.haubo...@eau-adour-garonne.fr> wrote: > Hugo Mercier wrote > > Or > >> calculated fields in view can't be explicitly cast, so QGIS should have > >> to > >> guess data type based on a data scan (a major unadressed issue of > sqlite) > > > > Hmmm I wasn't aware of this limitation in SQLITE views :( > > Yes, SQLITE does dynamic typing, so user or provider has to scan values to > guess the right type. > Here is a sqlite topic on that [0] > And here my initial post in qgis list [1] > > [0] > > http://sqlite.1065341.n5.nabble.com/Computed-columns-in-VIEWs-return-NULL-but-should-be-able-to-be-typed-Any-ideas-td56769.html#a56770 > > [1] > > http://osgeo-org.1560.x6.nabble.com/Spatialite-can-t-type-fields-of-a-view-td5058436.html > > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/have-aggregate-window-expressions-ever-been-discussed-tp5142215p5142714.html > Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Hi, the points Matthias raises are really good points: - how much can we trust sqlite (the community doesn't seem too opened)? And how stable library versions are (we've had many troubles with spatialite versions) - having redundant ways of doing the same thing is one of biggest criticism of users here. An advanced user who knows each tool will know what to do. those risks explain why current tests are feasibility tests only. We need those investigations to be aware of the limits of each possible approach. Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/have-aggregate-window-expressions-ever-been-discussed-tp5142215p5142970.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Server - WMS GetMap Jpeg compression
Hi all I just sent a pull request to allow configure the JPEG compression for getMap requests : * with a new configuration in the Project properties dialog / OWS Server / WMS capabilities : this is used as a default value if found. If not found (older QGIS), -1 is used as before * with an optionnal request parameter IMAGE_QUALITY . If passed and valid, it overrides the project configuration. Please review and comment : https://github.com/qgis/QGIS/pull/1403 Regards Michael 2014-05-26 17:22 GMT+02:00 kimaidou : > Hi Marco, > > Thanks for the reply > > I created an issue : http://hub.qgis.org/issues/10361 > > I agree with you that a parameter per project is enough. > > Regards, > Michael > > > 2014-05-26 17:12 GMT+02:00 Marco Hugentobler < > marco.hugentob...@sourcepole.ch>: > > Hi Michael >> >> At the moment, the compression rate is left to the Qt library both for >> png and jpeg (-1 is given to QImage::save). I agree it will be usefull to >> change from client or from project. >> >> >> >Why not >> >FORMAT=image%2Fjpeg%3B compression%3D90 >> >I guess it is not standard ? >> >> The problem here is that there has to be a new parameter for each >> compression rate. It might be better to have the possibility to configure >> the image quality in the project or by giving an optional parameter for the >> image quality (0-100 as the Qt parameter). So if the parameter is not >> there, the project setting is used. And if the setting is not set, -1 is >> used as it is now. >> >> Regards, >> Marco >> >> >> On 23.05.2014 18:44, kimaidou wrote: >> >> Or even better, having it layer per layer. Like we do for png , for >> example >> FORMAT=image%2Fpng%3B mode%3D8bit -> image 8 bits >> >> Why not >> FORMAT=image%2Fjpeg%3B compression%3D90 >> I guess it is not standard ? >> >> >> 2014-05-23 18:36 GMT+02:00 Paolo Cavallini : >> >>> Or even better, having a config at runtime, project by project. >>> >>> On 23 maggio 2014 18:33:00 CEST, kimaidou wrote: >>> Hi devs, Marco, René-Luc, I have some people giving feedback about the current JPEG compression. Many users think the "FORMAT=image/jpeg" parameters in the GetMap requests produce poor quality images. I guess the "80%" rate is used. I think it could be enough to increase it to 90 to produce better looking images (I personaly create my pyramid with this option with gdal), or better to leave the choice when installing QGIS Server by using a config parameter. Any feedback welcome Michael -- Qgis-developer mailing listqgis-develo...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> -- >>> http://faunalia.eu/ >>> >> >> >> >> ___ >> Qgis-developer mailing >> listQgis-developer@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> >> -- >> Dr. Marco Hugentobler >> Sourcepole - Linux & Open Source Solutions >> Weberstrasse 5, CH-8004 Zürich, switzerlandmarco.hugentob...@sourcepole.ch >> http://www.sourcepole.ch >> Technical Advisor QGIS Project Steering Committee >> >> >> ___ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
On 05/28/2014 10:30 AM, Hugo Mercier wrote: Le 28/05/2014 08:35, Matthias Kuhn a écrit : Hi All, As the responsible person for QGIS relations, I feel obliged to share my thoughts in this discussion. First of all a few notes about QGIS expressions and their current state: QGIS expressions are a nice and handy functionality to quickly calculate values based on a single feature in QGIS. This serves a lot of use-cases quick and easy. However, in their current state, they don't allow to do exactly what this thread originates from: aggregate and join data from other layers or use subqueries. Yes exactly. We have more or less the WHERE clause with expressions. Aggregates, joins and subqueries could be built using something else (relations?) Well relations would need to be integrated into some form of syntax first. And IMO this should be integrated nicely into the QgsExpression system to avoid having yet another candidate for this thread. The output of a relational query should be accepted as a node in a QgsExpression, and it should be able to insert a QgsExpression as part of this a relational query. So I think the best way is to extend expressions to support iterators (and maybe single features?) as return values. But I know that there are other opinions out there ;) I like the idea of using sqlites virtual tables to have immediate access to a huge base of functionality offered by sqlite to do complex queries. If we introduce this support, we have immediate support for a wide range of database functionality with a few lines of code. The only thing I am not sure (and I don't know the virtual tables implementation enough to answer this question) is if it is able to delegate cross-table queries to the original database. In short: can I do a request that requires data from different tables of the same database and have it executed directly inside the database? My suspicion is no, because the sqlite virtual tables will be known to sqlite as QGIS tables and it will still query the tables through the QGIS provider, therefore calculating e.g. a max functionality by querying the QGIS provider for all features and then calculating the "max" locally and not on the server side. This would be a major performance impact for customers having a single database that could do this calculation for us instead of doing this ourselves. Instead, if we have QGIS expressions (or a QGIS query implementation on top of it) support for this, we are able to tell, if different tables are from the same database and therefore if we are able to delegate the whole join/aggregate/subquery whatever job to the database and let the database do what it's good at. Therefore my question to the folks who know the sqlite virtual table code: is it possible to have sqlite virtual tables forward cross table queries to the database itself? Or is it possible to get access to the parsed query tree (or whatever the name of that may be) to determine based on QGIS side based on the parsed query if we are able to optimize by forwarding to the database. AFAIK, you do not have direct access to the query sent to a virtual table. But the SQLite engine will ask your virtual table driver what is the best way to resolve a constraint on columns. For instance, if the original query has a WHERE 'a = 2', then the driver will be asked if it knows how to quickly resolve this, using indexes (have a look at xBestIndex at http://www.sqlite.org/vtab.html) So I guess, you could use the remote database indexes. But, yes that would still be not very efficient if you want to query two tables of the same postgis database. In my mind, SQLite virtual tables are interesting for offering a more or less relational view on data sources that are not originally designed for that. But it would be suboptimal for already powerful databases. We then have two kinds of "database backends" : real databases (postgis and ... what else ?), and pseudo-databases through SQLite virtual tables. And we would have a conversion from QgsExpression + relations to different dialects of SQL (SQLite / PostgreSQL / ...) in each provider ? Does it make sense for you ? It does make sense. Real Databases: PostgreSQL, Oracle, MSSQL, (sqlite, native SQL through OGR) What would you like to use virtual tables drivers for? The idea of having it available as another provider for layer definitions sounds good to me anyway. But should it also be possible to use sqlite syntax wherever we have expression syntax integrated now? Then the UI would be "Field / Expression / SQLite"? In terms of control over what gets executed where and to translate it to native SQL wherever possible. In terms of quickly available functionality, sqlite virtual tables are most likely an easy shot. Is there a possibility to overcome the problem of "control"? Would be nice if yes, but I don't know the people behind sqlite. Is it worth adding two different syntaxes that may and will confuse users for their advantages?
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Hugo Mercier wrote > Le 27/05/2014 15:03, Régis Haubourg a écrit : >> Hugo Mercier wrote >>> Or calculated fields in view can't be explicitly cast, so QGIS should have to guess data type based on a data scan (a major unadressed issue of sqlite) >>> >>> Hmmm I wasn't aware of this limitation in SQLITE views :( >> >> Yes, SQLITE does dynamic typing, so user or provider has to scan values >> to >> guess the right type. >> Here is a sqlite topic on that [0] >> And here my initial post in qgis list [1] >> >> [0] >> http://sqlite.1065341.n5.nabble.com/Computed-columns-in-VIEWs-return-NULL-but-should-be-able-to-be-typed-Any-ideas-td56769.html#a56770 >> >> [1] >> http://osgeo-org.1560.x6.nabble.com/Spatialite-can-t-type-fields-of-a-view-td5058436.html > > Hi, > Still on this topic. I made a few tests with sqlite views. > Indeed you cannot enforce a particular column type, but : > * you can convert values with CAST (casting 'foobar' to integer gives > 0), even if the resulting type is undefined > * QGIS does not seem to have any particular problem with untyped SQLite > columns, they will be reported as TEXT (QString) in the layer properties > * Even if the column is untyped, each value has its own type. So if a > column results from a CAST, to integer say, then the corresponding > attribute will be in a QVariant typed as an integer when it is fetched. > You can then use this value in a QgsExpression or a categorized > symbology as an integer. > > Am I missing other use cases where not having a column type is a problem ? > ___ > Qgis-developer mailing list > Qgis-developer@.osgeo > http://lists.osgeo.org/mailman/listinfo/qgis-developer Good news! I couldn't achieve that with views in QGIS 1.8, all field cast to numeric were converted in Qstrings. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/have-aggregate-window-expressions-ever-been-discussed-tp5142215p5142949.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transectizer Plugin approval
Il 28/05/2014 16:59, Jorge Tornero ha scritto: > Hello All, > > Well, I've uploaded version 2.1 of plugin Transectizer. It fixes a little > issue about > scrollbars and several minor GUI changes. > > Please approve this new version if you consider it appropiate. done, thanks! -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Coments re QGIS 2.3.0 master, code rev a3628a6
Hi, I've been using Valmiera, but thought I'd give 2.3 a try. Very impressed with the rendering, but one practical issue has come up: I'm loading 1.17m polygons. Part way through rendering, I recognise the area I want to zoom to, so I simply zoom right in (yay +1 for multi-threading). Now comes the problem: How do I know when the rendering has fully completed? I see a few of my polygons appear, then seemingly nothing happens for a good few seconds, and then another clump of polygons appear. Until I have waited for a good while, do I start wondering is the rendering is still happening, or if I have holes in my data. Is it possible to (perhaps) change the background colour of the word "render" in the bottom right corner to say red when a rendering thread is active, and then back to grey (or even green) when all rendering threads have completed? Just a thought Regards and well done. Zoltan -- === Zoltan Szecsei PrGISc [PGP0031] Geograph (Pty) Ltd. GIS and Photogrammetric Services P.O. Box 7, Muizenberg 7950, South Africa. Mobile: +27-83-6004028 Fax:+27-86-6115323 www.geograph.co.za === ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Le 27/05/2014 15:03, Régis Haubourg a écrit : > Hugo Mercier wrote >> Or >>> calculated fields in view can't be explicitly cast, so QGIS should have >>> to >>> guess data type based on a data scan (a major unadressed issue of sqlite) >> >> Hmmm I wasn't aware of this limitation in SQLITE views :( > > Yes, SQLITE does dynamic typing, so user or provider has to scan values to > guess the right type. > Here is a sqlite topic on that [0] > And here my initial post in qgis list [1] > > [0] > http://sqlite.1065341.n5.nabble.com/Computed-columns-in-VIEWs-return-NULL-but-should-be-able-to-be-typed-Any-ideas-td56769.html#a56770 > > [1] > http://osgeo-org.1560.x6.nabble.com/Spatialite-can-t-type-fields-of-a-view-td5058436.html Hi, Still on this topic. I made a few tests with sqlite views. Indeed you cannot enforce a particular column type, but : * you can convert values with CAST (casting 'foobar' to integer gives 0), even if the resulting type is undefined * QGIS does not seem to have any particular problem with untyped SQLite columns, they will be reported as TEXT (QString) in the layer properties * Even if the column is untyped, each value has its own type. So if a column results from a CAST, to integer say, then the corresponding attribute will be in a QVariant typed as an integer when it is fetched. You can then use this value in a QgsExpression or a categorized symbology as an integer. Am I missing other use cases where not having a column type is a problem ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Transectizer Plugin approval
Hello All, Well, I've uploaded version 2.1 of plugin Transectizer. It fixes a little issue about scrollbars and several minor GUI changes. Please approve this new version if you consider it appropiate. Now a question: How to cite QGIS in a scientific paper? How to cite plugins or, say so, is there any policy about this? Best regards Jorge Tornero ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Server (from git) and WMS GetCapabilities
On Tue, May 27, 2014 at 4:02 PM, Luca Manganelli wrote: > have you tested the master version of QGIS Server with Qgis Web Client? > > It seems that Qgis Server, for WMS GetCapabilities, doesn't write the > section anymore (QGIS 2.0 did it), so this broke the Qgis > Web Client and cannot display map. This problem is resolved today on qgis master. Thank you mhugent! ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [OSM importer] Spatialite InitSpatialMetadata without (1) yet
I've submitted a pull request https://github.com/qgis/QGIS/pull/1399 giovanni 2014-05-27 10:31 GMT+02:00 G. Allegri : > Some months ago I opened a ticket about this [1]. I see that > InitSpatialMetadata is still called without the parameter, which makes it > being attached to a transaction. It is veeery slow on Windows, because > of the Spatialite version. Will the next 2.4 have an updated Spatialite (> > 4.1), which will prevent it from running inside a transaction? > > giovanni > > [1] http://hub.qgis.org/issues/9693 > > -- > Giovanni Allegri > http://about.me/giovanniallegri > Twitter: https://twitter.com/_giohappy_ > blog: http://blog.spaziogis.it > GEO+ geomatica in Italia http://bit.ly/GEOplus > -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [GRASS-dev] GRASS & QGIS: the future
On Wed, May 28, 2014 at 1:49 AM, Glynn Clements
wrote:
> But I still think that the global error handler is the wrong place for
> a longjmp(). Its original purpose was to allow the standard
> notification mechanism (stderr, log file, and/or email) to be replaced
> with a custom mechanism.
>
> Can you try the attached patch? The new function should be used like:
>
> if (setjmp(*G_fatal_longjmp(1))) {
> // this will be executed on fatal errors
> }
Works. Can I hope the patch will find a way to 7.0.0?
Thanks
Radim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Le 28/05/2014 08:35, Matthias Kuhn a écrit : > Hi All, > > As the responsible person for QGIS relations, I feel obliged to share my > thoughts in this discussion. > > First of all a few notes about QGIS expressions and their current state: > QGIS expressions are a nice and handy functionality to quickly calculate > values based on a single feature in QGIS. This serves a lot of use-cases > quick and easy. However, in their current state, they don't allow to do > exactly what this thread originates from: aggregate and join data from > other layers or use subqueries. Yes exactly. We have more or less the WHERE clause with expressions. Aggregates, joins and subqueries could be built using something else (relations?) > > I like the idea of using sqlites virtual tables to have immediate access > to a huge base of functionality offered by sqlite to do complex queries. > If we introduce this support, we have immediate support for a wide range > of database functionality with a few lines of code. The only thing I am > not sure (and I don't know the virtual tables implementation enough to > answer this question) is if it is able to delegate cross-table queries > to the original database. In short: can I do a request that requires > data from different tables of the same database and have it executed > directly inside the database? My suspicion is no, because the sqlite > virtual tables will be known to sqlite as QGIS tables and it will still > query the tables through the QGIS provider, therefore calculating e.g. a > max functionality by querying the QGIS provider for all features and > then calculating the "max" locally and not on the server side. This > would be a major performance impact for customers having a single > database that could do this calculation for us instead of doing this > ourselves. > > Instead, if we have QGIS expressions (or a QGIS query implementation on > top of it) support for this, we are able to tell, if different tables > are from the same database and therefore if we are able to delegate the > whole join/aggregate/subquery whatever job to the database and let the > database do what it's good at. > > Therefore my question to the folks who know the sqlite virtual table > code: is it possible to have sqlite virtual tables forward cross table > queries to the database itself? Or is it possible to get access to the > parsed query tree (or whatever the name of that may be) to determine > based on QGIS side based on the parsed query if we are able to optimize > by forwarding to the database. > AFAIK, you do not have direct access to the query sent to a virtual table. But the SQLite engine will ask your virtual table driver what is the best way to resolve a constraint on columns. For instance, if the original query has a WHERE 'a = 2', then the driver will be asked if it knows how to quickly resolve this, using indexes (have a look at xBestIndex at http://www.sqlite.org/vtab.html) So I guess, you could use the remote database indexes. But, yes that would still be not very efficient if you want to query two tables of the same postgis database. In my mind, SQLite virtual tables are interesting for offering a more or less relational view on data sources that are not originally designed for that. But it would be suboptimal for already powerful databases. We then have two kinds of "database backends" : real databases (postgis and ... what else ?), and pseudo-databases through SQLite virtual tables. And we would have a conversion from QgsExpression + relations to different dialects of SQL (SQLite / PostgreSQL / ...) in each provider ? Does it make sense for you ? > Concerning joins, merging this code with the relations seems a viable > option for me in the long run. Currently, relations do no caching and > do not "hard join" the data on the other table (meaning, joined fields > are not available as fields) and maybe there are other things missing > (I remember a thread here on the ML about this before) > Yes in my opinion, we should try to have the same code for what we call "joins" and more general relations. And on the GUI part, some redundancies between these two concepts may have to be reduced as well. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] have aggregate/window expressions ever been discussed?
Hi All, As the responsible person for QGIS relations, I feel obliged to share my thoughts in this discussion. First of all a few notes about QGIS expressions and their current state: QGIS expressions are a nice and handy functionality to quickly calculate values based on a single feature in QGIS. This serves a lot of use-cases quick and easy. However, in their current state, they don't allow to do exactly what this thread originates from: aggregate and join data from other layers or use subqueries. I like the idea of using sqlites virtual tables to have immediate access to a huge base of functionality offered by sqlite to do complex queries. If we introduce this support, we have immediate support for a wide range of database functionality with a few lines of code. The only thing I am not sure (and I don't know the virtual tables implementation enough to answer this question) is if it is able to delegate cross-table queries to the original database. In short: can I do a request that requires data from different tables of the same database and have it executed directly inside the database? My suspicion is no, because the sqlite virtual tables will be known to sqlite as QGIS tables and it will still query the tables through the QGIS provider, therefore calculating e.g. a max functionality by querying the QGIS provider for all features and then calculating the "max" locally and not on the server side. This would be a major performance impact for customers having a single database that could do this calculation for us instead of doing this ourselves. Instead, if we have QGIS expressions (or a QGIS query implementation on top of it) support for this, we are able to tell, if different tables are from the same database and therefore if we are able to delegate the whole join/aggregate/subquery whatever job to the database and let the database do what it's good at. Therefore my question to the folks who know the sqlite virtual table code: is it possible to have sqlite virtual tables forward cross table queries to the database itself? Or is it possible to get access to the parsed query tree (or whatever the name of that may be) to determine based on QGIS side based on the parsed query if we are able to optimize by forwarding to the database. Concerning joins, merging this code with the relations seems a viable option for me in the long run. Currently, relations do no caching and do not "hard join" the data on the other table (meaning, joined fields are not available as fields) and maybe there are other things missing (I remember a thread here on the ML about this before) Kind regards, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
