Re: [Qgis-developer] RFC for python server plugins ready for voting
Am 03.10.2014, 18:13 Uhr, schrieb Alessandro Pasotti apaso...@gmail.com: this afternoon at the HF in Essen we had a meeting about my proposal to implement python plugins for the server side https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4 The RFC is now open for voting, please give some feed-back! I guess I missed it but where should we vote? Here: https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4/files ? Thanks and best wishes, Anita -- anitagraser.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Unable to load GdalTools plugin. The required osgeo [python-gdal] module is missing.
Hi, Some problems with OSGeo4W nightly: Unable to load GdalTools plugin. The required osgeo [python-gdal] module is missing. Install it and try again. In the OSGeo4W installer, there is no python-gdal, only gdal-python and it's installed in version 1.11.1-1. This breaks the Gdal Tools plugin. Additionally, I also get an error related to Processing and mission osgeo module: Couldn't load plugin 'processing' from ['C:/OSGeo4W/apps/qgis-dev/./python', 'C:/Users/Anita/.qgis2/python', 'C:/Users/Anita/.qgis2/python/plugins', 'C:/OSGeo4W/apps/qgis-dev/./python/plugins', 'C:\OSGeo4W\apps\Python27\lib\site-packages\distribute-0.6.49-py2.7.egg', 'C:\OSGeo4W\bin\python27.zip', 'C:\OSGeo4W\apps\Python27\DLLs', 'C:\OSGeo4W\apps\Python27\lib', 'C:\OSGeo4W\apps\Python27\lib\plat-win', 'C:\OSGeo4W\apps\Python27\lib\lib-tk', 'C:\OSGeo4W\bin', 'C:\OSGeo4W\apps\Python27', 'C:\OSGeo4W\apps\Python27\lib\site-packages', 'C:\OSGeo4W\apps\Python27\lib\site-packages\GDAL-1.11.1-py2.7-win32.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\PIL', 'C:\OSGeo4W\apps\Python27\lib\site-packages\jinja2-2.7.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\markupsafe-0.23-py2.7-win32.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\python_dateutil-2.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\pytz-2014.2-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\win32', 'C:\OSGeo4W\apps\Python27\lib\site-packages\win32\lib', 'C:\OSGeo4W\apps\Python27\lib\site-packages\Pythonwin', 'C:\OSGeo4W\apps\Python27\lib\site-packages\Shapely-1.2.18-py2.7-win32.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\six-1.6.1-py2.7.egg', 'C:\OSGeo4W\apps\Python27\lib\site-packages\wx-2.8-msw-unicode', 'C:\OSGeo4W\apps\qgis-dev\python\plugins\fTools\tools'] Traceback (most recent call last): File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 185, in loadPlugin __import__(packageName) File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File C:/OSGeo4W/apps/qgis-dev/./python/plugins\processing\__init__.py, line 29, in from processing.tools.general import * File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File C:/OSGeo4W/apps/qgis-dev/./python/plugins\processing\tools\general.py, line 29, in from processing.core.Processing import Processing File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File C:/OSGeo4W/apps/qgis-dev/./python/plugins\processing\core\Processing.py, line 48, in from processing.algs.qgis.QGISAlgorithmProvider import QGISAlgorithmProvider File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File C:/OSGeo4W/apps/qgis-dev/./python/plugins\processing\algs\qgis\QGISAlgorithmProvider.py, line 89, in from RasterLayerStatistics import RasterLayerStatistics File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File C:/OSGeo4W/apps/qgis-dev/./python/plugins\processing\algs\qgis\RasterLayerStatistics.py, line 36, in from processing.tools import raster File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File C:/OSGeo4W/apps/qgis-dev/./python/plugins\processing\tools\raster.py, line 30, in from osgeo import gdal File C:/OSGeo4W/apps/qgis-dev/./python\qgis\utils.py, line 460, in _import mod = _builtin_import(name, globals, locals, fromlist, level) ImportError: No module named osgeo Python version: 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] QGIS version: 2.5.0-Master Master, 30dd6e7 Python path: ['C:/OSGeo4W/apps/qgis-dev/./python', u'C:/Users/Anita/.qgis2/python', u'C:/Users/Anita/.qgis2/python/plugins', 'C:/OSGeo4W/apps/qgis-dev/./python/plugins', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\distribute-0.6.49-py2.7.egg', 'C:\\OSGeo4W\\bin\\python27.zip', 'C:\\OSGeo4W\\apps\\Python27\\DLLs', 'C:\\OSGeo4W\\apps\\Python27\\lib', 'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win', 'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin', 'C:\\OSGeo4W\\apps\\Python27', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\GDAL-1.11.1-py2.7-win32.egg', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg',
Re: [Qgis-developer] RFC for python server plugins ready for voting
2014-10-04 11:35 GMT+02:00 Anita Graser anitagra...@gmx.at: Am 03.10.2014, 18:13 Uhr, schrieb Alessandro Pasotti apaso...@gmail.com: this afternoon at the HF in Essen we had a meeting about my proposal to implement python plugins for the server side https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4 The RFC is now open for voting, please give some feed-back! I guess I missed it but where should we vote? Here: https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4/files ? Thanks and best wishes, Anita I'm sorry, but I also have no clue about the voting process, I just understood that I had to make a pull request for the RFC and that's what I did. Maybe a +/- 1/0 on the mailing list would be sufficient. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RFC for python server plugins ready for voting
Yes a vote here or on the pull request is fine. Only PSC votes count towards a pass and fail. Nathan On Oct 4, 2014 7:55 PM, Alessandro Pasotti apaso...@gmail.com wrote: 2014-10-04 11:35 GMT+02:00 Anita Graser anitagra...@gmx.at: Am 03.10.2014, 18:13 Uhr, schrieb Alessandro Pasotti apaso...@gmail.com : this afternoon at the HF in Essen we had a meeting about my proposal to implement python plugins for the server side https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4 The RFC is now open for voting, please give some feed-back! I guess I missed it but where should we vote? Here: https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4/files ? Thanks and best wishes, Anita I'm sorry, but I also have no clue about the voting process, I just understood that I had to make a pull request for the RFC and that's what I did. Maybe a +/- 1/0 on the mailing list would be sufficient. -- Alessandro Pasotti w3: www.itopen.it ___ 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] RFC for python server plugins ready for voting
The slides dont say nothing about the optionality of this. Should be possible to disable all the python side using some compile settings ? like disable-python-server-side ? Or enable it only for speciic project. So avoid to have more insances. Something with python capability and other without python capability ? Aso a last question is the accounting. At least of lesser site, the usual user accounting is using single-sign-on solutions with https. Is this supported ?. Obviously it should supported directly from qgis-server otherwise it is exposed to the man in the middle attack. A. 2014-10-03 18:13 GMT+02:00 Alessandro Pasotti apaso...@gmail.com: Hello, this afternoon at the HF in Essen we had a meeting about my proposal to implement python plugins for the server side https://github.com/qgis/QGIS-Enhancement-Proposals/pull/4 I've collected your comments and finalized the proposal with the more complete implementation, that will offer much more flexibility for plugins to implement new features and modify existing ones. If you like you can read the slides online here: http://www.itopen.it/qgis-server-plugins/ The RFC is now open for voting, please give some feed-back! Thanks! -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RFC for python server plugins ready for voting
2014-10-04 13:17 GMT+02:00 Andrea Peri aperi2...@gmail.com: The slides dont say nothing about the optionality of this. Should be possible to disable all the python side using some compile settings ? Of course yes. like disable-python-server-side ? Or enable it only for speciic project. This could be easily implemented at the webserver level or directly inside the plugins in case of need. So avoid to have more insances. Something with python capability and other without python capability ? Aso a last question is the accounting. The plugin support has no direct implications with authentication or authorization. What the plugins will implement (and how they'll do it) is far beyond the scope of my RFC. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] OSX packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. I have seen Boundless is offering a nice bundled package for OSX: do we have any plan to use that one, or to merge their work with that of kingchaos, or any other option? All the best, and thanks. - -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQwDnAACgkQ/NedwLUzIr617gCeMoi0TLu/xgPmHYOdIF1h0Ga6 iRMAn1y1Fi6/Wz7sP+P65Vxq9KJzCV7a =rC85 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OSX packages
Hi Paolo, On Sat, Oct 4, 2014 at 9:12 AM, Paolo Cavallini cavall...@faunalia.it wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. I have seen Boundless is offering a nice bundled package for OSX: do we have any plan to use that one, or to merge their work with that of kingchaos, or any other option? Disclosure: I am currently working for Boundless, helping with their new QGIS support offering [0]. While the Boundless QGIS OS X package is standalone, offering a nice drag-drop install, there are several reasons why the QGIS project may not wish to rely upon it for its general OS X release. * It is branded as a third-party distribution (see splash screen). * It is produced by a commercial third-party entity using their resources and on their schedule. * It may be built from custom branches that include interim features not present in the official releases. Each of these points makes sense for an entity looking to make inroads towards enterprise adoption of QGIS, but are not, or may not be, in line with the QGIS project's goals, per se. There may also be the appearance of a conflict of interest, or unfair advantage, if QGIS releases for any OS come from a particular commercial entity who offers paid support. However, this does seem to work with Canonical and Ubuntu, for example. If the PSC wishes so, I could offer to be a liaison with Boundless and present such a OS X general release proposal to them. With regards as to the reason why the Boundless QGIS offering is a nice, tidy package, it stems from the work their packager, Michael Weisman, has done. After the release of 2.6, I believe he and I will look at how to push his CMake bundling changes (using CMake's BundleUtilities [2]) upstream to master. Once such a bundling setup is in core, anyone can produce a standalone QGIS bundle from the standard source tree, including the QGIS project itself. For the past year or so, I have been working on a project towards this goal, OSGe4Mac [3]. Based upon the Homebrew Mac OS X packager [4] (e.g. apt-get for Mac), it allows for quickly building all QGIS dependencies, in support for bundling and other goals. This will have the following advantages: * QGIS stable and nightlies can readily be built, packaged and released on OSGeo resources, by any Mac developer. * Dependencies can quickly be provisioned to a Mac OS X virtual machine for continuous integration setups. * A fairly complete OSGeo toolset can be released as a single DMG (Mac disk image), aiding workshops, etc. * An OSGeo4Mac installer (very similar to OSGeo4W) can be built off of Qt's Installer framework [5] to do on-line or locally distributed Mac OS X installs. Towards this goal, I have been in contact with the OSGeo System Administration Committee chair, Alex Mandel, about setting up a **Mac build server**. I am willing to donate all of the necessary Mac OS X software and pre-configured virtual machines (all the work I am already doing on my Macs for the QGIS nightlies). Would the QGIS PSC be interested in providing any financial support towards buying a Mac Mini build server for OSGeo, used initially for building QGIS? Anything in the $1,000-2,000 USD range would greatly help out. I will be adding the proposal to the 2014 infrastructure plan [6]. [0] http://boundlessgeo.com/2014/09/announcing-qgis-support/ [2] http://www.cmake.org/cmake/help/v3.0/module/BundleUtilities.html [3] https://github.com/OSGeo/homebrew-osgeo4mac [4] https://github.com/Homebrew/homebrew [5] https://qt-project.org/doc/qtinstallerframework-1.5/index.html [6] http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2014 Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota All the best, and thanks. - -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQwDnAACgkQ/NedwLUzIr617gCeMoi0TLu/xgPmHYOdIF1h0Ga6 iRMAn1y1Fi6/Wz7sP+P65Vxq9KJzCV7a =rC85 -END PGP SIGNATURE- ___ 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] [HackFest] Synthesis of fTools discussion
Hello, We had a discussion about the futur of ftools plugins here at Essen. This email aims to sum up the discussion to get more feedback. # Some Context Camptocamp wants to contribute to the ftools plugin for one of our customer. We have some issues on this plugin on which we want to work on with the community. The community (Victor and Alexander mostly I guess, may be other dev) worked to port ftools feature into processing. We have now two parts of code to maintain. # Issues * Interface improvement * performance issue * missing feature in processing algorithme * translatable algorithme # Interface improvement Tim worked on this for the inasafe project in order to improve ui in processing. There are also some possibilities to create custom interface for each algorithm. # Performance issue The Python code could be improved to get better performance. Some other possibilities could be to port the code to C library or to use GEOS library (Martin tested this with some good performance improvement). # Missing features This is not a technology problem, just need some love from someone. As soon as all feature from ftools will be in processing plugin we can think about the futur of ftools: do we need to completly remove it or to plug-in ftools features to processing one, or other? Though? # Translation Thanks to Alexander, the processing plugin is now translatable, just need some love from our translator community after updating transifex. I hope my synthesis is not wrong or misleading, please correct me in this case. All comments are welcome. Y. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Unable to load GdalTools plugin. The required osgeo [python-gdal] module is missing.
a ticket has been opened but refused because this error refers to osgeo4w. http://hub.qgis.org/issues/11314 s. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Unable-to-load-GdalTools-plugin-The-required-osgeo-python-gdal-module-is-missing-tp5165887p5165958.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] [HackFest] Synthesis of fTools discussion
Hi Yves, 2014-10-04 18:33 GMT+03:00 Yves Jacolin yjaco...@free.fr: The community (Victor and Alexander mostly I guess, may be other dev) worked to port ftools feature into processing. Actually almost all fTools algoritms already available via Processing, only few are missed. This missed algs now also ported, but not commited into master because of feature freeze. # Performance issue The Python code could be improved to get better performance. Some other possibilities could be to port the code to C library or to use GEOS library (Martin tested this with some good performance improvement). Just remebered that some fTools algorithms were ported to C++ by Carson Farmer (original fTools author) several years ago. One can find this algorithms in QGIS analysis library, look at QgsOverlayAnalyzer [0] and QgsGeometryAnalyzer [1]. Maybe it is better to update this code instead of writing new one. # Missing features This is not a technology problem, just need some love from someone. As soon as all feature from ftools will be in processing plugin we can think about the futur of ftools: do we need to completly remove it or to plug-in ftools features to processing one, or other? Though? As I said, almost all fTools functionality already available and missed algorithms are ready to merge. Regarding fTools (and maybe GDAL Tools) removal, I think we need to wait until Processing can completely replace this plugins. [0] http://qgis.org/api/classQgsOverlayAnalyzer.html [1] http://qgis.org/api/classQgsGeometryAnalyzer.html -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RFC for python server plugins ready for voting
+1 for the observer pattern. Having the ability to install middlewares within the flow would be great. In this case I would suggest to consider the opportunity to choose the plugin execution order (i.e. plugin1 request processing should happen before plugin2, etc.). +0 in case of the 404 method is employed. In this case I prefer to use an app out of qgis server... Il 04/ott/2014 14:52 Alessandro Pasotti apaso...@gmail.com ha scritto: 2014-10-04 13:17 GMT+02:00 Andrea Peri aperi2...@gmail.com: The slides dont say nothing about the optionality of this. Should be possible to disable all the python side using some compile settings ? Of course yes. like disable-python-server-side ? Or enable it only for speciic project. This could be easily implemented at the webserver level or directly inside the plugins in case of need. So avoid to have more insances. Something with python capability and other without python capability ? Aso a last question is the accounting. The plugin support has no direct implications with authentication or authorization. What the plugins will implement (and how they'll do it) is far beyond the scope of my RFC. -- Alessandro Pasotti w3: www.itopen.it ___ 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] RFC for python server plugins ready for voting
This require to define a distinct aliasing on webserver for every service. And not allow to have one unique URL for all the services. This is good for who have one only service, but not good for who plan to serve many services. A. Il 04/10/2014 14:52, Alessandro Pasotti ha scritto: like disable-python-server-side ? Or enable it only for speciic project. This could be easily implemented at the webserver level or directly inside the plugins in case of need. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
