[Qgis-developer] Error Offline Editing
Hi, I have been using the offline editing plugin and i have detected a problem. Using PostGIS like data source, the plugin creates sqlite database. But the problem is, that the relationship between feature on postgis and sqlite its alterate. In the table logs_fid the field values 'remote_fid' don't correspond with the correct value for 'offline_fid' Finally Synchronize works fine, but data is send to the wrong feature. Regards Valenty ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Building plugin for Print Composer
The suggestion from John is exactly what we did too. And we also built a chart composer... It would be great to have the means to know what other teams are working to. It would save a lor of time and money and, probably, get better software from a shared effort ;) giovanni Il 22/giu/2015 19:31, John Gitau gka...@gmail.com ha scritto: Hi Jakob, A workaround would be to have a plugin that creates a new composer view object: *custom_composer = self.iface.createNewComposer(My Composer)* Then get a reference to the main window in the composer view: *main_window = custom_composer.composerWindow()* Then you can either add a new toolbar (and required actions) or append an action to the main toolbar. Have a look at the ComposerWrapper class for something similar we implemented for designing charts in the composer: https://gist.github.com/gkahiu/06a43a589f9441736397 Hope this is helpful. Cheers, John On Mon, Jun 22, 2015 at 2:07 PM, G. Allegri gioha...@gmail.com wrote: You can act on it but you can't custom gui widgets to the Composer interface. I cannot check the code right know. I listen to a specific (existing) composition opening but if I remember correctly you can watch the Composer opening too. Il 22/giu/2015 17:19, Jakob Lanstorp jlanst...@gmail.com ha scritto: Hi Giovanni, thanks for the update. Another solution would be to catch the event when a user starts an existing print composer. Cannot in doc for the pyqgis API find anything for this. Anyone who know is one can listens for a print composer to startup by the user and act on it. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187p5212221.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 ___ 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
[Qgis-developer] Slow insert to GRASS SQLite db from QGIS
Vector import to GRASS in QGIS browser is very slow when using SQLite database, about 6s/1000 features. It takes less than 1s with dbf driver or if v.in.ogr + sqlite is used (even if run from GRASS tools). The chain is: qgis.exe - thread - qgis.v.in.exe - sqlite.exe Could it be some SQLite db locking? Somehow switched on when sqlite.exe driver is started from multi thread app? qgis.v.in.exe is C++ MSVC. Any idea? Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Using TravisCI integration in Github for QGIS Python plugin
By default in QGIS plugin builder you meant is here https://github.com/g-sherman/Qgis-Plugin-Builder/blob/master/run-env-linux.sh#L6 ?. If so, that is not the default if you install QGIS like this in Travis https://github.com/AIFDR/inasafe/blob/develop/.travis.yml#L17. You can just pass /usr as the argument when running run-env-linux.sh script On Tue, Jun 23, 2015 at 1:19 AM, Tom Chadwin tom.chad...@nnpa.org.uk wrote: I've got a bit further with this, but have an embarrassingly basic question. I'm using Tim's Plugin Builder's run-env-linux.sh, but the default QGIS path doesn't seem to match where Travis installs QGIS to - is Travis running Ubuntu? Can anyone tell me what QGIS path I should pass to run-env-linux.sh? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Using-TravisCI-integration-in-Github-for-QGIS-Python-plugin-tp5207646p5212347.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 -- *---* *Akbar Gumbira* *Software Engineer* *Geospatial, NLP, Data Mining, Machine Learning, Artificial Intelligence* ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Report 4 - Multithread Support on QGIS Toolbox
Hi Marcus, Good to see that you are making progress, it's nice to see the completed this week list being so long :) I think it would be good to include this blog on planet.qgis.org, I guess there is an RSS feed that can be added to the aggregator? Anyway, keep up the good work! All the best, Matthias On 06/22/2015 12:05 AM, Marcus Santos wrote: Hi all, Here is my fourth report [1] on the multithreading support. Feel free to comment the report or any other post. The code is on the dev branch [2]. Have a nice week, Marcus Santos [1] - https://qgisgsoc2015.wordpress.com/2015/06/21/fourth-report/ [2] - https://github.com/mvcsantos/QGIS/tree/dev ___ 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] Building plugin for Print Composer
You can act on it but you can't custom gui widgets to the Composer interface. I cannot check the code right know. I listen to a specific (existing) composition opening but if I remember correctly you can watch the Composer opening too. Il 22/giu/2015 17:19, Jakob Lanstorp jlanst...@gmail.com ha scritto: Hi Giovanni, thanks for the update. Another solution would be to catch the event when a user starts an existing print composer. Cannot in doc for the pyqgis API find anything for this. Anyone who know is one can listens for a print composer to startup by the user and act on it. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187p5212221.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] QGIS plugins site is down
On 22-06-15 12:47, DelazJ wrote: Hi, I'm just forwarding the issue report I just see in QGIS hub (hub.qgis.org/issues/13023 http://hub.qgis.org/issues/13023), thinking that it's worth being reported here ( who?) and quickly fixed instead of among various issues. Regards, DelazJ Thanks for reporting. will dive into it... Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS plugins site is down
Hi, I'm just forwarding the issue report I just see in QGIS hub ( hub.qgis.org/issues/13023), thinking that it's worth being reported here ( who?) and quickly fixed instead of among various issues. Regards, DelazJ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Q/A Compiler Warnings
On 16 June 2015 at 21:54, Matthias Kuhn matth...@opengis.ch wrote: In the quest for an always closer-to-perfection state of code, some goblins tried to get the warning count (on gcc and clang) yesterday as close to zero as possible. This was done in order to allow you (as a developer) to see if your code changes cause warnings without scrolling through heaps of meaningless warnings. Thanks goblins! Your work in much appreciated :) At the moment most of the warnings left originate from the geometry refactoring and point to empty methods which have not yet been implemented. These warnings point to real problems and should be fixed as soon as possible, in order to have some time left before release to be able to test the fixes before the release. @Marco, what is your schedule concerning these? I've just pushed some fixes to master which reimplement these stubbed methods and comment out some of the unimplemented new methods. 2.10 release was approaching too close for comfort to leave these in! @Marco Please let me know if I've made any errors doing this... The plan is to let travis test for warnings and if there are warnings mark the build red. With this in place, an author of a commit will be required to spend some thoughts on a warning and take care of it before merging into master. As an example, if you deprecate a method, you will have to check where it is used, where it can be updated to its successor and where it's required to use the deprecated method and appropriately put macros there. IMO this workflow should be preferred to merging code which produces warnings of which the community (i.e. somebody out there) will have to take care of. Big +1 from me to this! Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Report 4 - Multithread Support on QGIS Toolbox
On 22-06-15 09:11, Matthias Kuhn wrote: I think it would be good to include this blog on planet.qgis.org, I guess there is an RSS feed that can be added to the aggregator? Mmm, done: http://qgis.org http://planet.qgis.org but as Marcus is such an active blogger, he is on all frontpages now :-) Is this ok? @Marcus: if it is possible, maybe do a weekly report to, and tag/categorize this one, so instead of this feed, I only do the weekly ones? Anyway, it is great to see that is progress and action!! Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Building plugin for Print Composer
Is it possibly to build a Python plugin minded for the print composer alone? -Need to build a plugin with a new button inside print composer that lists all labels in the composer in a new dialog for editing. This would be a tool for easy handling of complex header and footers in the layout for the novice user. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187.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] Report 4 - Multithread Support on QGIS Toolbox
Good to see that you are making progress, it's nice to see the completed this week list being so long :) Anyway, it is great to see that is progress and action!! Thank you Richard and Matthias =) but as Marcus is such an active blogger, he is on all frontpages now :-) Yes, I can see that there is a lot of posts in the main pages. @Marcus: if it is possible, maybe do a weekly report to, and tag/categorize this one, so instead of this feed, I only do the weekly ones? I’ve created a category called “reports” for weekly reports. We can now change the RSS feed. How can I change? The other posts will be on the “Midterm” category. Best regards, Marcus On 22 Jun 2015, at 08:29, Richard Duivenvoorde rdmaili...@duif.net wrote: On 22-06-15 09:11, Matthias Kuhn wrote: I think it would be good to include this blog on planet.qgis.org, I guess there is an RSS feed that can be added to the aggregator? Mmm, done: http://qgis.org http://planet.qgis.org Is this ok? Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Building plugin for Print Composer
Hi Jacob. For the moment it isn't possible to extend the Composer with custom plugins. It's sonething that will be discussed for the next Report Engine (QGIS 3.0) I've built a Python plugin that uses the composer widgets (composition, items, etc.) within a custom interface but you can only use the building blocks by yourself. E.g. you can open/create abd manage a composition inside your own widget and add items to it. In your case they could be text or html items, for header and footer. giovanni Il 22/giu/2015 15:18, Jakob Lanstorp jlanst...@gmail.com ha scritto: Is it possibly to build a Python plugin minded for the print composer alone? -Need to build a plugin with a new button inside print composer that lists all labels in the composer in a new dialog for editing. This would be a tool for easy handling of complex header and footers in the layout for the novice user. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187.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
[Qgis-developer] Using environment variables in path definitions in QGIS
To the QGIS developers list - I have a goal of making a fully portable Windows edition of QGIS. Fully portable means that I simply can install QGIS by copying the QGIS program directory to a location on the users PC and start QGIS by double clicking on the QGIS.bat file in the ..\bin directory. I've reached 95% of my target by using the OSGeo4W installation as a template and making some modification the the start-up bat file. Mostly by using the --configpath qualifier to 1) redefine the location of the QGIS user directory .qgis2 and 2) not using the registry to save option values. By using the --configpath qualifier QGIS creates and uses the .qgis2\QGIS\QGIS2.ini file to store option values normally located in the registry. Some of these values are path definitions: example: Configuration\SAGA_FOLDER=C:/OSGeo4W/apps\\saga Configuration\GRASS_WIN_SHELL=C:/OSGeo4W/apps\\msys Configuration\R_SCRIPTS_FOLDER=C:\\OSGeo4W\\.qgis2\\processing\\rscripts I would like to use environment variables as part of the path definition in the ini file like this: Configuration\SAGA_FOLDER=%OSGEO4W_HOME%/apps\\saga Configuration\GRASS_WIN_SHELL=%OSGEO4W_HOME%/apps\\msys Configuration\R_SCRIPTS_FOLDER=%QGIS_USERDIR%\\processing\\rscripts (OSGEO4W_HOME and QGIS_USERDIR is environment variables, that contains the path for the QGIS program directory and the QGIS user directory) The problem is, that QGIS doesn't interpret the %..% as a environment variable and replace it with the value of the variable but simply interprets it literally resulting in paths containing % - signs and environment variable names. Is there a method to get QGIS to interpret the environment variable and replace it with the content of the variable ? Or should a put it on the wish list in the bug tracker ? Regards Bo Victor Thomsen AestasGIS Denmark ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Processing: Raster calc errors (SAGA and
Looks like you do not have GDAL correctly installed in there. Both error traces complain about the same thing. 2015-06-19 16:39 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 19/06/2015 14:03, Paolo Cavallini ha scritto: Hi all, we are getting errors in raster calculators (both SAGA and GDAL) on Win; on OSX and Debian they are running fine. This happens with the training manual no_data project. Any hint? Probably I pinned the problem down: all the machines not working had a previous instalation of QGIS, the fresh ones are working smoothly. So it must ba a leftover, probably the path: should one look in Windows registry? In this case better reset on postinstall? All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Change the query of a query layer (postgis)
On 18 June 2015 at 00:06, Olivier Dalang olivier.dal...@gmail.com wrote: Actually it seems the layer.setDataSource() method works, sorry for the noise ! But then it resets the style of the layer to default (uniform random color), as if the layer was freshly added... No, you're right. It was crashy. It's been fixed in master, and I've also made it now retain the layer's renderer and legend if the geometry type has not changed. Hope that helps! Nyall 2015-06-17 14:29 GMT+02:00 Olivier Dalang olivier.dal...@gmail.com: Hi ! Is it possible to change the query of a postgis query layer in python without reloading the project ? The goal is to have a parameter in my query that I'd be able to change with a slider. I tried the QgsVectorLayer.setDataSource() method, but it makes QGis crash. I tried the workaround described here ( http://gis.stackexchange.com/questions/62610/changing-data-source-of-layer-in-qgis ), writing and reading the XML file, but it also makes QGis crash. If not possible, is there a serious limitation behind this, or is the feature just missing/bugged ? Example : I have this query loaded as a layer: SELECT id, name, ST_Buffer(geom,25) as geom FROM my_table But I want to be able to change the hardcoded buffer from 25 to some value from a QSlider. Thanks! Olivier ___ 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] Building plugin for Print Composer
Hi Giovanni, thanks for the update. Another solution would be to catch the event when a user starts an existing print composer. Cannot in doc for the pyqgis API find anything for this. Anyone who know is one can listens for a print composer to startup by the user and act on it. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187p5212221.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 91e44ea crash browsing GRASS 7 vector
I forgot to add that GRASS stable in OSGeo4W switched to grass-7.0.1RC1-1 while qgis-dev-2.9.0-104 is still compiled with grass-7.0.0-1 so when updating OSGeo4W select manually to keep grass-7.0.0-1. Radim On Mon, Jun 22, 2015 at 10:23 AM, Radim Blazek radim.bla...@gmail.com wrote: Hi Roy, the bug is fixed in OSGeo4w qgis-dev-2.9.0-104. Apart from browsing and displaying GRASS data you should be able to import data to GRASS in the browser with drag and drop. There are still some issues with import which I am trying to sort out: - vector import with more features is slow due to slow inserting to db (provider problem, v.in.ogr is fast) - temporary vector maps (polygons cleaning) are not deleted - animated import icon is missing, it means no layer icon = import running, for now on Windows Testing is welcome. Radim On Mon, Jun 15, 2015 at 10:03 AM, Roy royr...@outlook.com wrote: Thank you for the info Radim! Il 15/06/2015 08.25, Radim Blazek ha scritto: Hi Roy, this is known issue I haven't been able to fix so far. It has something to do with getting list of vector layers in thread. It seems to only happen with GRASS 7 on windows when Vect_cidx_get_* functions are used in thread (browser items are populated in threads). I have already double checked the code including relevant parts of GRASS vector lib without success. Radim On Thu, Jun 11, 2015 at 10:37 AM, Roy royr...@outlook.com wrote: Hi, i'm testing QGIS desktop 2.9.0 with grass 7 and it crashes when browsing a grass 7 DB; (windows osgeo4w 32 bit) i simply prepared a grass7 location and mapset, imported a vector stopped grass and opened QGIS, with browser panel QGIS crashes navigating to the imported vector, if you confirm i can open a bug report, Roy ___ 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis 91e44ea crash browsing GRASS 7 vector
Hi Roy, the bug is fixed in OSGeo4w qgis-dev-2.9.0-104. Apart from browsing and displaying GRASS data you should be able to import data to GRASS in the browser with drag and drop. There are still some issues with import which I am trying to sort out: - vector import with more features is slow due to slow inserting to db (provider problem, v.in.ogr is fast) - temporary vector maps (polygons cleaning) are not deleted - animated import icon is missing, it means no layer icon = import running, for now on Windows Testing is welcome. Radim On Mon, Jun 15, 2015 at 10:03 AM, Roy royr...@outlook.com wrote: Thank you for the info Radim! Il 15/06/2015 08.25, Radim Blazek ha scritto: Hi Roy, this is known issue I haven't been able to fix so far. It has something to do with getting list of vector layers in thread. It seems to only happen with GRASS 7 on windows when Vect_cidx_get_* functions are used in thread (browser items are populated in threads). I have already double checked the code including relevant parts of GRASS vector lib without success. Radim On Thu, Jun 11, 2015 at 10:37 AM, Roy royr...@outlook.com wrote: Hi, i'm testing QGIS desktop 2.9.0 with grass 7 and it crashes when browsing a grass 7 DB; (windows osgeo4w 32 bit) i simply prepared a grass7 location and mapset, imported a vector stopped grass and opened QGIS, with browser panel QGIS crashes navigating to the imported vector, if you confirm i can open a bug report, Roy ___ 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Using environment variables in path definitions in QGIS
See also: http://hub.qgis.org/issues/12623 Maybe it is a bit tricky for a general solution, since variables are defined and named differently on the different OSes?... As a workaround you could probably put a string replacement procedure into your QGIS.bat? We used e.g. a #USERPROFILE# string, as a placeholder, which got replaced when a custom QGIS2 folder template - containing the QGIS.ini - was copied to a new user... Not too trivial to replace a string in a text-file on Windows using batch (I understood from my colleagues)... Cheers Stefan -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Bo Victor Thomsen Sent: 22. juni 2015 11:32 To: qgis-developer@lists.osgeo.org Subject: [Qgis-developer] Using environment variables in path definitions in QGIS To the QGIS developers list - I have a goal of making a fully portable Windows edition of QGIS. Fully portable means that I simply can install QGIS by copying the QGIS program directory to a location on the users PC and start QGIS by double clicking on the QGIS.bat file in the ..\bin directory. I've reached 95% of my target by using the OSGeo4W installation as a template and making some modification the the start-up bat file. Mostly by using the --configpath qualifier to 1) redefine the location of the QGIS user directory .qgis2 and 2) not using the registry to save option values. By using the --configpath qualifier QGIS creates and uses the .qgis2\QGIS\QGIS2.ini file to store option values normally located in the registry. Some of these values are path definitions: example: Configuration\SAGA_FOLDER=C:/OSGeo4W/apps\\saga Configuration\GRASS_WIN_SHELL=C:/OSGeo4W/apps\\msys Configuration\R_SCRIPTS_FOLDER=C:\\OSGeo4W\\.qgis2\\processing\\rscripts I would like to use environment variables as part of the path definition in the ini file like this: Configuration\SAGA_FOLDER=%OSGEO4W_HOME%/apps\\saga Configuration\GRASS_WIN_SHELL=%OSGEO4W_HOME%/apps\\msys Configuration\R_SCRIPTS_FOLDER=%QGIS_USERDIR%\\processing\\rscripts (OSGEO4W_HOME and QGIS_USERDIR is environment variables, that contains the path for the QGIS program directory and the QGIS user directory) The problem is, that QGIS doesn't interpret the %..% as a environment variable and replace it with the value of the variable but simply interprets it literally resulting in paths containing % - signs and environment variable names. Is there a method to get QGIS to interpret the environment variable and replace it with the content of the variable ? Or should a put it on the wish list in the bug tracker ? Regards Bo Victor Thomsen AestasGIS Denmark ___ 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] Using TravisCI integration in Github for QGIS Python plugin
I have. I was just trying to put together as minimal a test environment as possible. I didn't know which packages from the inasafe yaml I needed, and which I could do without. I presume it requires many more than qgis2web. Original message From: Etienne Trimaille [via OSGeo.org] ml-node+s1560n5212350...@n6.nabble.com Date: 22/06/2015 19:37 (GMT+00:00) To: Tom Chadwin tom.chad...@nnpa.org.uk Subject: Re: Using TravisCI integration in Github for QGIS Python plugin Have a look to the Travis config file in inasafe : https://github.com/AIFDR/inasafe/blob/develop/.travis.yml 2015-06-22 20:19 GMT+02:00 Tom Chadwin [hidden email]: I've got a bit further with this, but have an embarrassingly basic question. I'm using Tim's Plugin Builder's run-env-linux.sh, but the default QGIS path doesn't seem to match where Travis installs QGIS to - is Travis running Ubuntu? Can anyone tell me what QGIS path I should pass to run-env-linux.sh? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Using-TravisCI-integration-in-Github-for-QGIS-Python-plugin-tp5207646p5212347.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/qgis-developer If you reply to this email, your message will be added to the discussion below: http://osgeo-org.1560.x6.nabble.com/Using-TravisCI-integration-in-Github-for-QGIS-Python-plugin-tp5207646p5212350.html To unsubscribe from Using TravisCI integration in Github for QGIS Python plugin, click herehttp://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5207646code=dG9tLmNoYWR3aW5Abm5wYS5vcmcudWt8NTIwNzY0NnwxNDg2MTk5Mjcx. NAMLhttp://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml Tom Chadwin, ICT Manager Telephone: 01434 611530 Mob: Web: www.northumberlandnationalpark.org.ukhttp://www.northumberlandnationalpark.org.uk/ IMPORTANT NOTICE - Disclaimer - This communication is from Northumberland National Park Authority (NNPA).The Authority’s head office and principal place of business is Eastburn, South Park, Hexham, Northumberland, NE46 1BS, United Kingdom. If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please delete the email and destroy any copies of it. Any views or opinions presented are solely those of the author and do not necessarily represent those of NNPA.Contractors or potential contractors are reminded that a formal Order or Contract is needed for NNPA to be bound by any offer or acceptance of terms for the supply of goods or services Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the NNPA for any loss or damage arising in any way from the receipt or use thereof. Computer systems of this Authority may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purpose. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Using-TravisCI-integration-in-Github-for-QGIS-Python-plugin-tp5207646p5212359.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] Using TravisCI integration in Github for QGIS Python plugin
I've got a bit further with this, but have an embarrassingly basic question. I'm using Tim's Plugin Builder's run-env-linux.sh, but the default QGIS path doesn't seem to match where Travis installs QGIS to - is Travis running Ubuntu? Can anyone tell me what QGIS path I should pass to run-env-linux.sh? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Using-TravisCI-integration-in-Github-for-QGIS-Python-plugin-tp5207646p5212347.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] Error Offline Editing
Hi Valenty, This sounds like a bug. It would be great if you could open an issue report at http://qgis.org/en/site/getinvolved/development/index.html#bugs-features-and-issue with as much details as possible and the steps to reproduce the problem. Cheers, Matthias On 06/22/2015 06:31 PM, valenty gonzalez wrote: Hi, I have been using the offline editing plugin and i have detected a problem. Using PostGIS like data source, the plugin creates sqlite database. But the problem is, that the relationship between feature on postgis and sqlite its alterate. In the table logs_fid the field values 'remote_fid' don't correspond with the correct value for 'offline_fid' Finally Synchronize works fine, but data is send to the wrong feature. Regards Valenty ___ 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] Slow insert to GRASS SQLite db from QGIS
Solved. I forgot db_begin_transaction. Sorry for noise. Radim On Mon, Jun 22, 2015 at 9:18 PM, Radim Blazek radim.bla...@gmail.com wrote: Vector import to GRASS in QGIS browser is very slow when using SQLite database, about 6s/1000 features. It takes less than 1s with dbf driver or if v.in.ogr + sqlite is used (even if run from GRASS tools). The chain is: qgis.exe - thread - qgis.v.in.exe - sqlite.exe Could it be some SQLite db locking? Somehow switched on when sqlite.exe driver is started from multi thread app? qgis.v.in.exe is C++ MSVC. Any idea? Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Potentially serious performance regression in new geometry - should 2.10 be delayed?
Hi all, Unfortunately, we've become aware of a serious performance regression caused by the new geometry engine. Basically, the situation is that for all geometry operations which rely on geos (think buffers, splits, spatial relation operations such as intersects and within,... ) the geometry now needs to be converted into a geos representation with *every* operation. In the old geometry engine this conversion was done once, and the result stored so that follow up operations would not need to recalculate it. This potentially has huge impacts on the performance of common tasks such as selecting all features which intersect a geometry. I've had a look, and unfortunately it's not trivial to fix this. I think the correct solution to this is to: - make QgsGeometryEngine accept and return QgsGeometry containers, not QgsAbstractGeometryV2 - store the generated geos representation of geometries within QgsGeometryPrivate inside the QgsGeometry container. This way it will be reusable between different geometry operations, and shared when QgsGeometry objects are copied. This will also have the benefit that if a geometry is prepared using geos then subsequent geos operations performed on that QgsGeometry and its shared copies will be much faster. - make QgsGeometry a friend class of QgsGeo, so that it can access QgsGeometryPrivate to retrieve or set the geos representation of the geometry as required An alternative (short term) solution would be to just cache the geos representation when geometry operations are called through the older QgsGeometry modification/relationship operations. This would be easier, but means that the API of QgsGeometryEngine will be stuck with the current design, and we won't be able to properly fix this until breaking the api for 3.0. Either way, I doubt this can be addressed within the remaining 3 days we have until release. Should we delay to address this? Release with the regression? Or am I missing something and there's an easier solution we could implement? Or even possibly this additional cost of recalculating the geos representation is trivial and can be ignored (maybe someone could test this with a little repeated intersection script)? Thoughts? Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Hierarchy of new geometry classes
Hi Recently I have been looking a bit at the new geometry classes and there is one thing I do not understand: if QgsLineStringV2 is derived from QgsCurveV2 and QgsPolygonV2 is derived from QgsSurfaceV2, why is not the same approach used for multi-part geometries? Currently QgsMultiLineStringV2 and QgsMultiPolygonV2 are subclasses of QgsGeometryCollectionV2 - but why they are not derived from QgsMultiCurveV2 and QgsMultiSurfaceV2 respectively? It looks like OGR uses that approach too (multi-polygon from multi-surface and multi-linestring from multi-curve): http://www.gdal.org/classOGRGeometry.html Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Potentially serious performance regression in new geometry - should 2.10 be delayed?
Hi Agreed with Nyall. Apart from the above mentioned problems, there are newly introduced performance regressions with snapping: the cached geometries in 2.10 take double the amount of memory they used in 2.8, and snapping got much slower with more complex layers (compared to 2.8) - e.g. with [1]. The extra memory consumption is caused by the fact that providers provide geometry in WKB representation, which is then converted to new representation and WKB is kept. We should use just one representation and drop the usage of the other one - that means stop using WKB in providers and common code paths, so the WKB representation does not even get created (and cached). One heretic idea at the end - what others think about postponing the release of the new geometry architecture to 2.12 so that there is more time to address the current issues (fix performance, fix high memory consumption, clean up API, write unit tests). It seems to me that some of the issues would be difficult to address even if the release of 2.10 is moved by another week or so. Regards Martin [1] http://www.iucnredlist.org/spatial-data/MAMMALS_TERRESTRIAL.zip On Tue, Jun 23, 2015 at 10:09 AM, Nyall Dawson nyall.daw...@gmail.com wrote: Hi all, Unfortunately, we've become aware of a serious performance regression caused by the new geometry engine. Basically, the situation is that for all geometry operations which rely on geos (think buffers, splits, spatial relation operations such as intersects and within,... ) the geometry now needs to be converted into a geos representation with *every* operation. In the old geometry engine this conversion was done once, and the result stored so that follow up operations would not need to recalculate it. This potentially has huge impacts on the performance of common tasks such as selecting all features which intersect a geometry. I've had a look, and unfortunately it's not trivial to fix this. I think the correct solution to this is to: - make QgsGeometryEngine accept and return QgsGeometry containers, not QgsAbstractGeometryV2 - store the generated geos representation of geometries within QgsGeometryPrivate inside the QgsGeometry container. This way it will be reusable between different geometry operations, and shared when QgsGeometry objects are copied. This will also have the benefit that if a geometry is prepared using geos then subsequent geos operations performed on that QgsGeometry and its shared copies will be much faster. - make QgsGeometry a friend class of QgsGeo, so that it can access QgsGeometryPrivate to retrieve or set the geos representation of the geometry as required An alternative (short term) solution would be to just cache the geos representation when geometry operations are called through the older QgsGeometry modification/relationship operations. This would be easier, but means that the API of QgsGeometryEngine will be stuck with the current design, and we won't be able to properly fix this until breaking the api for 3.0. Either way, I doubt this can be addressed within the remaining 3 days we have until release. Should we delay to address this? Release with the regression? Or am I missing something and there's an easier solution we could implement? Or even possibly this additional cost of recalculating the geos representation is trivial and can be ignored (maybe someone could test this with a little repeated intersection script)? Thoughts? Nyall ___ 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] Potentially serious performance regression in new geometry - should 2.10 be delayed?
+1 to full postpone for me. I don't like the idea of shipping something that is slower and snapping is slow. Those are core features of a GIS. Nathan On Tue, 23 Jun 2015 3:22 pm Nyall Dawson nyall.daw...@gmail.com wrote: On 23 June 2015 at 13:42, Martin Dobias wonder...@gmail.com wrote: One heretic idea at the end - what others think about postponing the release of the new geometry architecture to 2.12 so that there is more time to address the current issues (fix performance, fix high memory consumption, clean up API, write unit tests). It seems to me that some of the issues would be difficult to address even if the release of 2.10 is moved by another week or so. I'd be a cautious +1 to this - but I'm also concerned about the impact of reverting this work now. Scary stuff, but like you said, I'm not confident we can get the new geometry work into a release-ready shape in 3 days... (Also, who is expected to do this? AFAIK all the sponsored bug fixing has been exhausted for 2.10). Nyall ___ 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] Potentially serious performance regression in new geometry - should 2.10 be delayed?
Out of curiosity, how long of a delay do you estimate would be needed to fix things? 4 weeks, 8 weeks? On 23 Jun 2015 09:09, Nyall Dawson nyall.daw...@gmail.com wrote: Hi all, Unfortunately, we've become aware of a serious performance regression caused by the new geometry engine. Basically, the situation is that for all geometry operations which rely on geos (think buffers, splits, spatial relation operations such as intersects and within,... ) the geometry now needs to be converted into a geos representation with *every* operation. In the old geometry engine this conversion was done once, and the result stored so that follow up operations would not need to recalculate it. This potentially has huge impacts on the performance of common tasks such as selecting all features which intersect a geometry. I've had a look, and unfortunately it's not trivial to fix this. I think the correct solution to this is to: - make QgsGeometryEngine accept and return QgsGeometry containers, not QgsAbstractGeometryV2 - store the generated geos representation of geometries within QgsGeometryPrivate inside the QgsGeometry container. This way it will be reusable between different geometry operations, and shared when QgsGeometry objects are copied. This will also have the benefit that if a geometry is prepared using geos then subsequent geos operations performed on that QgsGeometry and its shared copies will be much faster. - make QgsGeometry a friend class of QgsGeo, so that it can access QgsGeometryPrivate to retrieve or set the geos representation of the geometry as required An alternative (short term) solution would be to just cache the geos representation when geometry operations are called through the older QgsGeometry modification/relationship operations. This would be easier, but means that the API of QgsGeometryEngine will be stuck with the current design, and we won't be able to properly fix this until breaking the api for 3.0. Either way, I doubt this can be addressed within the remaining 3 days we have until release. Should we delay to address this? Release with the regression? Or am I missing something and there's an easier solution we could implement? Or even possibly this additional cost of recalculating the geos representation is trivial and can be ignored (maybe someone could test this with a little repeated intersection script)? Thoughts? Nyall ___ 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] Building plugin for Print Composer
Hi Jakob, A workaround would be to have a plugin that creates a new composer view object: *custom_composer = self.iface.createNewComposer(My Composer)* Then get a reference to the main window in the composer view: *main_window = custom_composer.composerWindow()* Then you can either add a new toolbar (and required actions) or append an action to the main toolbar. Have a look at the ComposerWrapper class for something similar we implemented for designing charts in the composer: https://gist.github.com/gkahiu/06a43a589f9441736397 Hope this is helpful. Cheers, John On Mon, Jun 22, 2015 at 2:07 PM, G. Allegri gioha...@gmail.com wrote: You can act on it but you can't custom gui widgets to the Composer interface. I cannot check the code right know. I listen to a specific (existing) composition opening but if I remember correctly you can watch the Composer opening too. Il 22/giu/2015 17:19, Jakob Lanstorp jlanst...@gmail.com ha scritto: Hi Giovanni, thanks for the update. Another solution would be to catch the event when a user starts an existing print composer. Cannot in doc for the pyqgis API find anything for this. Anyone who know is one can listens for a print composer to startup by the user and act on it. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187p5212221.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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Using environment variables in path definitions in QGIS
Hi Stefan - Thanks for the answer. My Plan B was to manually create a QGIS2.ref, which is identical with the original qgis2.ini, but with every occurrence of the program path and the user profile path replaced with references to environment variable names. And then use the sed editor to exchange the variable names in qgis2.ref with the actual paths on-the-fly under start-up. More or less the solution you suggested. Sed is luckily included in the OSGeo4W package by default, so I'll have a go on plan B :-) And I will add a request about environment variable substitution to the existing issue 12623. Regards Bo Victor Thomsen AestasGIS Denmark On 22-06-2015 11:55, Blumentrath, Stefan wrote: See also: http://hub.qgis.org/issues/12623 Maybe it is a bit tricky for a general solution, since variables are defined and named differently on the different OSes?... As a workaround you could probably put a string replacement procedure into your QGIS.bat? We used e.g. a #USERPROFILE# string, as a placeholder, which got replaced when a custom QGIS2 folder template - containing the QGIS.ini - was copied to a new user... Not too trivial to replace a string in a text-file on Windows using batch (I understood from my colleagues)... Cheers Stefan -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Bo Victor Thomsen Sent: 22. juni 2015 11:32 To: qgis-developer@lists.osgeo.org Subject: [Qgis-developer] Using environment variables in path definitions in QGIS To the QGIS developers list - I have a goal of making a fully portable Windows edition of QGIS. Fully portable means that I simply can install QGIS by copying the QGIS program directory to a location on the users PC and start QGIS by double clicking on the QGIS.bat file in the ..\bin directory. I've reached 95% of my target by using the OSGeo4W installation as a template and making some modification the the start-up bat file. Mostly by using the --configpath qualifier to 1) redefine the location of the QGIS user directory .qgis2 and 2) not using the registry to save option values. By using the --configpath qualifier QGIS creates and uses the .qgis2\QGIS\QGIS2.ini file to store option values normally located in the registry. Some of these values are path definitions: example: Configuration\SAGA_FOLDER=C:/OSGeo4W/apps\\saga Configuration\GRASS_WIN_SHELL=C:/OSGeo4W/apps\\msys Configuration\R_SCRIPTS_FOLDER=C:\\OSGeo4W\\.qgis2\\processing\\rscripts I would like to use environment variables as part of the path definition in the ini file like this: Configuration\SAGA_FOLDER=%OSGEO4W_HOME%/apps\\saga Configuration\GRASS_WIN_SHELL=%OSGEO4W_HOME%/apps\\msys Configuration\R_SCRIPTS_FOLDER=%QGIS_USERDIR%\\processing\\rscripts (OSGEO4W_HOME and QGIS_USERDIR is environment variables, that contains the path for the QGIS program directory and the QGIS user directory) The problem is, that QGIS doesn't interpret the %..% as a environment variable and replace it with the value of the variable but simply interprets it literally resulting in paths containing % - signs and environment variable names. Is there a method to get QGIS to interpret the environment variable and replace it with the content of the variable ? Or should a put it on the wish list in the bug tracker ? Regards Bo Victor Thomsen AestasGIS Denmark ___ 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] Q/A Compiler Warnings
On 06/22/2015 02:03 PM, Nyall Dawson wrote: On 16 June 2015 at 21:54, Matthias Kuhn matth...@opengis.ch wrote: In the quest for an always closer-to-perfection state of code, some goblins tried to get the warning count (on gcc and clang) yesterday as close to zero as possible. This was done in order to allow you (as a developer) to see if your code changes cause warnings without scrolling through heaps of meaningless warnings. Thanks goblins! Your work in much appreciated :) At the moment most of the warnings left originate from the geometry refactoring and point to empty methods which have not yet been implemented. These warnings point to real problems and should be fixed as soon as possible, in order to have some time left before release to be able to test the fixes before the release. @Marco, what is your schedule concerning these? I've just pushed some fixes to master which reimplement these stubbed methods and comment out some of the unimplemented new methods. 2.10 release was approaching too close for comfort to leave these in! @Marco Please let me know if I've made any errors doing this... Thanks Nyall. With a warning count of 0... The plan is to let travis test for warnings and if there are warnings mark the build red. With this in place, an author of a commit will be required to spend some thoughts on a warning and take care of it before merging into master. As an example, if you deprecate a method, you will have to check where it is used, where it can be updated to its successor and where it's required to use the deprecated method and appropriately put macros there. IMO this workflow should be preferred to merging code which produces warnings of which the community (i.e. somebody out there) will have to take care of. Big +1 from me to this! ... this is now merged and we now have an excellent signal/noise ratio in the compiler warning pane. Cheers signature.asc Description: OpenPGP digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
