Re: [Qgis-developer] SAGA Interface
>> What I don't understand is: we'd have the same problems using python. >> There are, as far as I know, no Python-saga packages. >> Debian's libsaga[2], for instance, does *not* include python bindings. >> That means we'd have to compile & ship the python-saga binding >> ourselves, anyway. Or am I missing something? > > This should be solved from the saga side, providing a package for it. That could be an option, yes. But they haven't done it, and I don't know if they would be interested. One of us could step up and offer packaging to SAGA, but I am not that experienced in packaging issues and distro-related complications. The saga wiki suggest using saga_cmd through python, which would need no recompilation, but would limit us to non-interactive plugins. Maybe that isn't so much of an issue, and would be easier. > Let me try to explain: > First case: C++ plugin; this requires recompilation of QGIS, so we have > two options: > - include the plugin in qgis-trunk, and add the dependency on saga; this > is unlikely to be accepted by most core qgis-devs, I guess What about including it in trunk, but only load the plugin if the dependencies are satisfied? Would the devs be ok with that? Provided the quality of the plugin is acceptable, of course. I also wouldn't require a *full* saga installation, if I am not mistaken. Only libsaga. > - leave the plugin outside qgis, and require the recompilation for each > and every platform, and for each release of qgis; furthermore, osgeo4w > users will not be able to use it with qgis-dev. > > Second case: Python plugin. The user will be able to install it or not, > provided he has saga with its py bindings installed on its system. This > will work with all versions of qgis (>=minimum version, as defined in > the plugin), on all OS. > There is a third case: Using saga_cmd through python. This is the easiest in term of programming effort, I think. But is limited to non-interactive plugins, as I said before, and but would require a full saga installation. > Speed shouldn't be a problem, as the plugin istelf should do very little > calculations, only calling saga commands with the appropriate > parameters, as it happens with the GRASS and the GdalTools plugins. I agree speed isn't a problem. > Am I wrong? You are right, and bring up some interesting arguments. You are starting to convince me. :) Maybe I could even start with saga_cmd only (option 3) and later add support for interactive modules using the python api (if available), option 2. What do you think of that? Less elegant than a C++ solution, but much easier. If I go this route, what would the recommended exchange formats for raster/grid and vector/shape be? Many thanks for your comments, I feel this has been a productive discussion. Regards, Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Il giorno gio, 31/03/2011 alle 10.19 -0400, Camilo Polymeris ha scritto: > What I don't understand is: we'd have the same problems using python. > There are, as far as I know, no Python-saga packages. > Debian's libsaga[2], for instance, does *not* include python bindings. > That means we'd have to compile & ship the python-saga binding > ourselves, anyway. Or am I missing something? This should be solved from the saga side, providing a package for it. Let me try to explain: First case: C++ plugin; this requires recompilation of QGIS, so we have two options: - include the plugin in qgis-trunk, and add the dependency on saga; this is unlikely to be accepted by most core qgis-devs, I guess - leave the plugin outside qgis, and require the recompilation for each and every platform, and for each release of qgis; furthermore, osgeo4w users will not be able to use it with qgis-dev. Second case: Python plugin. The user will be able to install it or not, provided he has saga with its py bindings installed on its system. This will work with all versions of qgis (>=minimum version, as defined in the plugin), on all OS. Speed shouldn't be a problem, as the plugin istelf should do very little calculations, only calling saga commands with the appropriate parameters, as it happens with the GRASS and the GdalTools plugins. Am I wrong? All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] libmysqlclient error when compiling
Hi Carlos, On Fri, 01. Apr 2011 at 18:00:53 +0200, Carlos Dávila wrote: > I'm getting the following error compiling qgis with ccmake > /usr/lib/gcc/i486-linux-gnu/4.5.2/../../../../lib/libgdal1.7.0.so: > undefined reference to `__cxa_pure_virtual@libmysqlclient_16' > How can I fix it? Sounds like a problem with you GDAL installation. It's not a QGIS problem. Maybe reinstalling gdal or the mysql libraries (or downgrading) helps. > BTW all links to qgis manuals in > http://qgis.org/en/documentation/manuals.html seem to be temporarily > unavailable Not reproducable here either. But those point to download.osgeo.org, which seems unavailable from some networks for some undetermined reason. download2.osgeo.org should work. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
Hi Giovanni, the plugin is in code.google (http://code.google.com/p/qgis-saga-plugin/). It Is very experimental and rough ! Anyway, the code makes a query to the saga-api and collect all the module for each library for build a complex menu in qgis. The select of a non interactive module print in stdout the output of "saga_cmd 'library_name' 'module_name' -h". I'm working to build a GUI "on the fly" from that output. Yes, the user need to compile saga with python interface but in future I think that the maintainer can build an xml file with library, modules and parameters structure from a query to saga_api. We can read the xml file and use the information for a plugin saga_api independent , using saga_cmd command. In that way, the user needs only set path for saga_api and install plugin with only the xml. With a new saga version, the maintainer generate a new xml file and puts it in plugin. The C++ approach is realy more perfomance but is more complex and and my C++ knowledge isn't so good. Il 31/03/2011 0.35, G. Allegri ha scritto: Hi Gianluca, I can't say how much I could dedicate to that, but if you could put it on GitHub I could find some time to contribute. I don't think I can invest time on the low level development, but with Python I think I could give some time. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] libmysqlclient error when compiling
I'm getting the following error compiling qgis with ccmake /usr/lib/gcc/i486-linux-gnu/4.5.2/../../../../lib/libgdal1.7.0.so: undefined reference to `__cxa_pure_virtual@libmysqlclient_16' collect2: ld returned 1 exit status make[2]: *** [src/app/qgis] Error 1 make[1]: *** [src/app/CMakeFiles/qgis.dir/all] Error 2 make: *** [all] Error 2 How can I fix it? BTW all links to qgis manuals in http://qgis.org/en/documentation/manuals.html seem to be temporarily unavailable ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] bug in SpatiaLite 3D
Hi Devs, I've quite casually discovered that the SpatiaLite Data Provider is actually unable to access any 3D layer (no error occurs, but no geometry is shown at all). I've already patched the data provider so to correctly support 3D geometries as well. Anyway, this one doesn't seems to be an high priority bug (nobody noticed this before: I suppose 3D layers are very rarely used). Considering the current "freeze" I suppose it would be better waiting until v.1.7 will be released before committing this patch into the SVN. Any comment from you is surely welcome. bye Sandro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Fwd: Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
sending this to the list, as I accidentally sent it only to Jürgen. Andreas Original Message Subject: Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule Date: Fri, 01 Apr 2011 16:24:24 +0200 From: Andreas Neumann To: Jürgen E. Fischer Not necessarily, but it would have the following advantages: * the users would not have to manually get those three separate libraries * the libraries would be stripped down to the necessary (e.g. OL can be half the size of the regular full version), same for ExtJS and GeoExt * the libraries in our svn would be tested to work with each other. When one of the three libraries changes to a new version we would check them for compatibility and only replace them in our repository if they work. It happened in the past, that a newer SVN trunk version of OL would break some functionality. On the other hand it is the question whether we are allowed to keep separate versions in our SVN? Would the licenses of OL, GeoExt and Ext/Sencha allow that? Andreas On Fri, 1 Apr 2011 16:00:11 +0200, Jürgen E. Fischer wrote: Hi Andreas, On Fri, 01. Apr 2011 at 15:45:04 +0200, Andreas Neumann wrote: I would propose to place it next to the documentation: https://svn.osgeo.org/qgis/trunk/webclient Currently the webclient is 3.7MB, about 600 files, but most of it is just OpenLayers, Ext and GeoExt. I can strip it more down to the necessary resources (maybe down to 2mb, 150 files). The libraries (OL, Ext, GeoExt) contain both deployment and debug versions. Do we also need the libraries in SVN? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Hi Andreas, On Fri, 01. Apr 2011 at 15:45:04 +0200, Andreas Neumann wrote: > I would propose to place it next to the documentation: > https://svn.osgeo.org/qgis/trunk/webclient > Currently the webclient is 3.7MB, about 600 files, but most of it is > just OpenLayers, Ext and GeoExt. I can strip it more down to the > necessary resources (maybe down to 2mb, 150 files). The libraries (OL, > Ext, GeoExt) contain both deployment and debug versions. Do we also need the libraries in SVN? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Hi Marco, On Fri, 01. Apr 2011 at 15:17:50 +0200, Marco Hugentobler wrote: > I don't really have a strong opinion on where the webclient would be located > in svn ( webclient in https://svn.osgeo.org/qgis/webclient vs. > https://svn.osgeo.org/qgis/trunk/qgis/webgis_client). Me neither. > The directory above would save some bandwidth for most people that compile > the > code, the directory below has better visibility. > Don't know what the number of files is in the webclient. If there are lots of > files, I'd tend to https://svn.osgeo.org/qgis/webclient, otherwise to > https://svn.osgeo.org/qgis/trunk/qgis/webgis_client The only things webclient and the rest share are the icons, isn't it? Not duplicating that would possibly be a minor plus. Another thing might be that the webclient follows development stuff in server, so it might be nice to have new features on both ends in possibly one commit. That might make maintance easier. What would be the downside of trunk - assuming that the webclient isn't huge? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
I would propose to place it next to the documentation: https://svn.osgeo.org/qgis/trunk/webclient Currently the webclient is 3.7MB, about 600 files, but most of it is just OpenLayers, Ext and GeoExt. I can strip it more down to the necessary resources (maybe down to 2mb, 150 files). The libraries (OL, Ext, GeoExt) contain both deployment and debug versions. If we decide to bundle it, I would propose not to bundle it with 1.7, but wait for 1.8. I think it should be more thoroughly tested and those users who want to test it can easily extract it from SVN. At a later stage we can still discuss how we want to deliver the webclient. Andreas On Fri, 1 Apr 2011 15:17:50 +0200, Marco Hugentobler wrote: I don't really have a strong opinion on where the webclient would be located in svn ( webclient in https://svn.osgeo.org/qgis/webclient vs. https://svn.osgeo.org/qgis/trunk/qgis/webgis_client). The directory above would save some bandwidth for most people that compile the code, the directory below has better visibility. Don't know what the number of files is in the webclient. If there are lots of files, I'd tend to https://svn.osgeo.org/qgis/webclient, otherwise to https://svn.osgeo.org/qgis/trunk/qgis/webgis_client Regards, Marco Am Freitag, 1. April 2011, um 14.37:15 schrieb Paolo Cavallini: Il giorno ven, 01/04/2011 alle 13.27 +0200, Andreas Neumann ha scritto: > I think it makes sense to separate the two completely. Most QGIS > > desktop users won't care about a webgis client. And some QGIS Server > users may want to run their own webgis viewer or use QGIS Server just as > a regular WMS. Sorry to insist -I do not want to bother. We currently have many functions that are of limited, specialized use. I think our current approach (keep everything in one place, and leave to packagers the choice of splitting packages) is more sane. For instance, in Debian we have: === p libqgis-dev - Quantum GIS - development files i A libqgis1.7.0 - Quantum GIS - shared libraries i A python-qgis - Python bindings to Quantum GIS i A python-qgis-common - Python bindings to Quantum GIS - architecture-independent fi i qgis - Geographic Information System (GIS) p qgis-api-doc - Quantum GIS API documentation i A qgis-common - Quantum GIS - architecture-independent data i qgis-mapserver - Quantum GIS mapserver i qgis-plugin-grass - GRASS plugin for Quantum GIS i qgis-plugin-grass-common - GRASS plugin for Quantum GIS - architecture-independent data i A qgis-providers - collection of data providers to Quantum GIS i A qgis-providers-common - collection of data providers to Quantum GIS - architecture-i p qgis-sqlanywhere1.7.0 - Quantum GIS sql anywhere plugin and provider === so most users will not install, e.g. qgis-sqlanywhere1.7.0, etc. I think the same could apply to the webgis. All the best. > It will be easy to install and configure, and hopefully well > > documented, though. > > But I doubt that it will satisfy everybody's need. > > Andreas > > On Fri, 01 Apr 2011 13:17:41 +0200, Paolo Cavallini wrote: > > Il giorno ven, 01/04/2011 alle 13.11 +0200, Andreas Neumann ha > > > > scritto: > >> Paolo, the qgis webclient, although it works with QGIS server, will > >> not > >> > >> be delivered by default with QGIS. It will reside in a parallel > >> repository, just like the QGIS documentation or the articles. > >> > >> Besides > >> > >> Jürgens work on the WMS server tab in the project properties it has > >> > >> no > >> > >> influence on QGIS desktop. So no need to hold back because of my > >> webclient. > >> > >> User will need to check out qgis webclient manually. It will not be > >> delivered together with QGIS. > > > > Why so? Wouldn't it be better (and simpler for users) to keep > > everything > > in one place? > > All the best. -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
I don't really have a strong opinion on where the webclient would be located in svn ( webclient in https://svn.osgeo.org/qgis/webclient vs. https://svn.osgeo.org/qgis/trunk/qgis/webgis_client). The directory above would save some bandwidth for most people that compile the code, the directory below has better visibility. Don't know what the number of files is in the webclient. If there are lots of files, I'd tend to https://svn.osgeo.org/qgis/webclient, otherwise to https://svn.osgeo.org/qgis/trunk/qgis/webgis_client Regards, Marco Am Freitag, 1. April 2011, um 14.37:15 schrieb Paolo Cavallini: > Il giorno ven, 01/04/2011 alle 13.27 +0200, Andreas Neumann ha scritto: > > I think it makes sense to separate the two completely. Most QGIS > > > > desktop users won't care about a webgis client. And some QGIS Server > > users may want to run their own webgis viewer or use QGIS Server just as > > a regular WMS. > > Sorry to insist -I do not want to bother. We currently have many > functions that are of limited, specialized use. I think our current > approach (keep everything in one place, and leave to packagers the > choice of splitting packages) is more sane. > For instance, in Debian we have: > === > p libqgis-dev - Quantum GIS - development files > i A libqgis1.7.0 - Quantum GIS - shared libraries > i A python-qgis - Python bindings to Quantum GIS > i A python-qgis-common - Python bindings to Quantum GIS - > architecture-independent fi > i qgis - Geographic Information System (GIS) > p qgis-api-doc - Quantum GIS API documentation > i A qgis-common - Quantum GIS - architecture-independent data > i qgis-mapserver - Quantum GIS mapserver > i qgis-plugin-grass - GRASS plugin for Quantum GIS > i qgis-plugin-grass-common - GRASS plugin for Quantum GIS - > architecture-independent data > i A qgis-providers - collection of data providers to Quantum GIS > i A qgis-providers-common - collection of data providers to Quantum GIS > - architecture-i > p qgis-sqlanywhere1.7.0 - Quantum GIS sql anywhere plugin and provider > === > so most users will not install, e.g. qgis-sqlanywhere1.7.0, etc. > I think the same could apply to the webgis. > All the best. > > > It will be easy to install and configure, and hopefully well > > > > documented, though. > > > > But I doubt that it will satisfy everybody's need. > > > > Andreas > > > > On Fri, 01 Apr 2011 13:17:41 +0200, Paolo Cavallini wrote: > > > Il giorno ven, 01/04/2011 alle 13.11 +0200, Andreas Neumann ha > > > > > > scritto: > > >> Paolo, the qgis webclient, although it works with QGIS server, will > > >> not > > >> > > >> be delivered by default with QGIS. It will reside in a parallel > > >> repository, just like the QGIS documentation or the articles. > > >> > > >> Besides > > >> > > >> Jürgens work on the WMS server tab in the project properties it has > > >> > > >> no > > >> > > >> influence on QGIS desktop. So no need to hold back because of my > > >> webclient. > > >> > > >> User will need to check out qgis webclient manually. It will not be > > >> delivered together with QGIS. > > > > > > Why so? Wouldn't it be better (and simpler for users) to keep > > > everything > > > in one place? > > > All the best. -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.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
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Il giorno ven, 01/04/2011 alle 13.27 +0200, Andreas Neumann ha scritto: > I think it makes sense to separate the two completely. Most QGIS > desktop users won't care about a webgis client. And some QGIS Server > users may want to run their own webgis viewer or use QGIS Server just as > a regular WMS. Sorry to insist -I do not want to bother. We currently have many functions that are of limited, specialized use. I think our current approach (keep everything in one place, and leave to packagers the choice of splitting packages) is more sane. For instance, in Debian we have: === p libqgis-dev - Quantum GIS - development files i A libqgis1.7.0 - Quantum GIS - shared libraries i A python-qgis - Python bindings to Quantum GIS i A python-qgis-common - Python bindings to Quantum GIS - architecture-independent fi i qgis - Geographic Information System (GIS) p qgis-api-doc - Quantum GIS API documentation i A qgis-common - Quantum GIS - architecture-independent data i qgis-mapserver - Quantum GIS mapserver i qgis-plugin-grass - GRASS plugin for Quantum GIS i qgis-plugin-grass-common - GRASS plugin for Quantum GIS - architecture-independent data i A qgis-providers - collection of data providers to Quantum GIS i A qgis-providers-common - collection of data providers to Quantum GIS - architecture-i p qgis-sqlanywhere1.7.0 - Quantum GIS sql anywhere plugin and provider === so most users will not install, e.g. qgis-sqlanywhere1.7.0, etc. I think the same could apply to the webgis. All the best. > It will be easy to install and configure, and hopefully well > documented, though. > > But I doubt that it will satisfy everybody's need. > > Andreas > > On Fri, 01 Apr 2011 13:17:41 +0200, Paolo Cavallini wrote: > > Il giorno ven, 01/04/2011 alle 13.11 +0200, Andreas Neumann ha > > scritto: > >> Paolo, the qgis webclient, although it works with QGIS server, will > >> not > >> be delivered by default with QGIS. It will reside in a parallel > >> repository, just like the QGIS documentation or the articles. > >> Besides > >> Jürgens work on the WMS server tab in the project properties it has > >> no > >> influence on QGIS desktop. So no need to hold back because of my > >> webclient. > >> > >> User will need to check out qgis webclient manually. It will not be > >> delivered together with QGIS. > > > > Why so? Wouldn't it be better (and simpler for users) to keep > > everything > > in one place? > > All the best. > -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Hi Paolo, I think it makes sense to separate the two completely. Most QGIS desktop users won't care about a webgis client. And some QGIS Server users may want to run their own webgis viewer or use QGIS Server just as a regular WMS. It will be easy to install and configure, and hopefully well documented, though. But I doubt that it will satisfy everybody's need. Andreas On Fri, 01 Apr 2011 13:17:41 +0200, Paolo Cavallini wrote: Il giorno ven, 01/04/2011 alle 13.11 +0200, Andreas Neumann ha scritto: Paolo, the qgis webclient, although it works with QGIS server, will not be delivered by default with QGIS. It will reside in a parallel repository, just like the QGIS documentation or the articles. Besides Jürgens work on the WMS server tab in the project properties it has no influence on QGIS desktop. So no need to hold back because of my webclient. User will need to check out qgis webclient manually. It will not be delivered together with QGIS. Why so? Wouldn't it be better (and simpler for users) to keep everything in one place? All the best. -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Il giorno ven, 01/04/2011 alle 13.11 +0200, Andreas Neumann ha scritto: > Paolo, the qgis webclient, although it works with QGIS server, will not > be delivered by default with QGIS. It will reside in a parallel > repository, just like the QGIS documentation or the articles. Besides > Jürgens work on the WMS server tab in the project properties it has no > influence on QGIS desktop. So no need to hold back because of my > webclient. > > User will need to check out qgis webclient manually. It will not be > delivered together with QGIS. Why so? Wouldn't it be better (and simpler for users) to keep everything in one place? All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python plugin: how to set a symbol for a layer?
Hi Luca, On Fri, Apr 1, 2011 at 9:14 AM, wrote: > I've searched across documentation and mailing list, but I didn't found a > page explaining how to set a symbol. > create your style within QGis and save it as e.g. "point.qml" in your plugin folder, then load it using this snapshot: import os.path style_path = os.path.join( os.path.dirname(__file__), "point.qml" ) (errorMsg, result) = vectorLayer.loadNamedStyle( style_path ) So to change the style of the layer it consists just in a file replacing without any change in your code. Cheers. > For example: > > - point layer: I want to use a circle with width 0.5 and gray colour with > black border; > - line layer: width 1 and continous green line > > any hint? > > Thank you in advance. > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS webclient into svn
Am Freitag, 1. April 2011, um 11.12:30 schrieb Paolo Cavallini: > Il giorno gio, 31/03/2011 alle 21.51 +0200, Andreas Neumann ha scritto: > > Yes - the printing widget takes the layout from the print composer > > layouts in the .qgs project files. > > Thanks Andreas for explaining. > If you think it is production ready, I would suggest to commit it before > the release of 1.7. It is based on solid code (geoext), and should not > interfere with the rest of QGIS. > Objections? > All the best. +1 Agreed. It is completely separated from other code, so feature / string freeze should not be apply to it. Marco -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.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
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Hi, Paolo, the qgis webclient, although it works with QGIS server, will not be delivered by default with QGIS. It will reside in a parallel repository, just like the QGIS documentation or the articles. Besides Jürgens work on the WMS server tab in the project properties it has no influence on QGIS desktop. So no need to hold back because of my webclient. User will need to check out qgis webclient manually. It will not be delivered together with QGIS. Andreas On Fri, 01 Apr 2011 12:58:27 +0200, Paolo Cavallini wrote: Il giorno ven, 01/04/2011 alle 12.47 +0200, Tim Sutton ha scritto: we lift the string freeze again but maintain the feature freeze in place. I will update the release checklist with new timings over teh weekend. Hi all. As I wrote, I would suggest to lift the feature freeze for Andreas' work on the webgis client, if he's ok with this. This move is highly unlikely to have any impact on the rest, and would be a great addition. All the best. -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Il giorno ven, 01/04/2011 alle 12.47 +0200, Tim Sutton ha scritto: > we lift the string freeze again but maintain the feature freeze in > place. I will update the release checklist with new timings over teh > weekend. Hi all. As I wrote, I would suggest to lift the feature freeze for Andreas' work on the webgis client, if he's ok with this. This move is highly unlikely to have any impact on the rest, and would be a great addition. All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Please vote: Proposed extension to 1.7 release schedule
Hi All It seems those who care have had their say, and those that don't haven't :-) So it looks like a majority of people opt for 3 - dedicate the hackfest to bug fixing and release after. As such I will suggest we lift the string freeze again but maintain the feature freeze in place. I will update the release checklist with new timings over teh weekend. Best regards Tim On Thu, Mar 31, 2011 at 5:35 PM, Mayeul Kauffmann wrote: > Hi, > My preference: option 3 + Marco's suggestion > > Still, there are more people "voting" than people going to the hackfest! > There were at least 2 messages saying that debugging is not fun (and, > no, it is not fun!). And Marco is right about discussing future > development directions. For me those taking the time to go to Lisbon > should do what they prefer to do, not what the majority of developers > prefer. > My preference is still option 3 (+ Marco's suggestion), but whatever the > decision of participants would be, thanks in advance for the good work > and have fun! > Mayeul > > > Le jeudi 31 mars 2011 à 09:34 +0200, Marco Hugentobler a écrit : >> Hi Tim >> >> 3 for me too (assuming there is still space to discuss future development >> directions at the hackfest). >> >> Regards, >> Marco >> >> Am Donnerstag, 31. März 2011, um 08.54:11 schrieb Tim Sutton: >> > Hi all >> > >> > There has been some discussion on this list about extending the >> > release schedule for 1.7. The proposals are: >> > >> > >> > 1) Continue with release schedule as is (aiming for mid-april release >> > announcement with branching on 7 April) >> > >> > 2) Extend the release schedule and lift the string freeze until after >> > the hackfest. We would then spend **a day** of the hackfest tidying up >> > QGIS 1.7 and then branch at the end of that day and finalise >> > translation in that branch while we continue to hack new features into >> > trunk for the rest of the hackfest. Planned tag for release would be a >> > week after the hackfest. >> > >> > 3) Extend the release schedule and lift the string freeze until after >> > the hackfest. We would then spend **all** of the hackfest tidying up >> > QGIS 1.7 and then impose a string freeze straight after the hackfest >> > with a planned branch for release a week later. >> > >> > >> > >> > Please cast your vote and have your say. >> > >> > My vote: option 3 >> > >> > Regards >> > >> > Tim >> >> > > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] win standalone from trunk
Hi 2011/4/1 Jürgen E. : > Hi Paolo, > > On Fri, 01. Apr 2011 at 11:20:20 +0200, Paolo Cavallini wrote: >> Is there an howto to build a standalone installer for win, based on >> trunk? > > The INSTALL document should have all necessary information. > Paolo its actually embarrasingly easy with Jurgens revised version of the INSTALL docs (since a few months now)if you can disregard the fact that you need to cross over to the dark side to do it Regards Tim > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 > Software Engineer D-26506 Norden http://www.norbit.de > > -- > norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH > Rheinstrasse 13, 26506 Norden > GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] win standalone from trunk
Hi Paolo, On Fri, 01. Apr 2011 at 11:20:20 +0200, Paolo Cavallini wrote: > Is there an howto to build a standalone installer for win, based on > trunk? The INSTALL document should have all necessary information. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] win standalone from trunk
Hi all. Is there an howto to build a standalone installer for win, based on trunk? All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS webclient into svn
Il giorno gio, 31/03/2011 alle 21.51 +0200, Andreas Neumann ha scritto: > Yes - the printing widget takes the layout from the print composer > layouts in the .qgs project files. Thanks Andreas for explaining. If you think it is production ready, I would suggest to commit it before the release of 1.7. It is based on solid code (geoext), and should not interfere with the rest of QGIS. Objections? All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Python plugin: how to set a symbol for a layer?
Hi, I've searched across documentation and mailing list, but I didn't found a page explaining how to set a symbol. For example: - point layer: I want to use a circle with width 0.5 and gray colour with black border; - line layer: width 1 and continous green line any hint? Thank you in advance. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
