Re: [Qgis-developer] Re: [Qgis-user] QGIS Trac to Redmine migration update

[Alex Mandel]

The system seems to have picked a different login id for your email
address. I just changed it to match your osgeo-id. Try logging in now.

Thanks,
Alex

PS: now to go see if we have a valid smtp configured...

On 06/13/2011 11:22 PM, Radim Blazek wrote:
> Hi,
> 
> I am not able to login to hub.qgis.org. If I try to login on
> hub.qgis.org/login with my valid OSGEO login, it brings me to
> 'Register' page (still hub.qgis.org/login) and it tells me "Email has
> already been taken". The first time I tried to login, it told me
> something like "Your first name must not be empty" and I blindly
> filled in the first name and clicked 'Submit'. So maybe I have created
> on hub.qgis.org another login with the same email which is now in
> conflict with that from OSGEO? I have not recieved any email from
> hub.qgis.org however. If I created such account, how can I delete it?
> 
> Radim
> 
> On Sun, Jun 5, 2011 at 12:56 PM, Tim Sutton  wrote:
>> Dear all
>>
>> The bulk of the migration has been carried out. The new tracker is
>> available at[1]. There are still quite a number of outstanding issues.
>> If you are logging in for the first time, I encourage you to first
>> peruse our redmine project ticket queue[2] to familiarise yourself
>> with known issues.  The trac project remains in a read only state, and
>> unless testing over the next day or so reveals a critical issue with
>> the redmine deployment, we will ask for automatic redirection of users
>> from the old trac site to the new redmine site. I have also
>> reorganised the projects a little more logically and made other
>> general cleanups to the redmine instance. If you do encounter issues,
>> please file at ticket in the redmine specific project [2] linked
>> below.
>>
>>
>> [1] http://hub.qgis.org/projects/quantum-gis
>> [2] http://hub.qgis.org/projects/qgis-redmine/issues
>>
>> Once this is out of the way we will forge on with the QGIS 1.7 release!
>>
>> Regards
>>
>>
>>
>> --
>> 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-user mailing list
>> qgis-u...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
> ___
> 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] Re: [Qgis-user] QGIS Trac to Redmine migration update

[Radim Blazek]

Hi,

I am not able to login to hub.qgis.org. If I try to login on
hub.qgis.org/login with my valid OSGEO login, it brings me to
'Register' page (still hub.qgis.org/login) and it tells me "Email has
already been taken". The first time I tried to login, it told me
something like "Your first name must not be empty" and I blindly
filled in the first name and clicked 'Submit'. So maybe I have created
on hub.qgis.org another login with the same email which is now in
conflict with that from OSGEO? I have not recieved any email from
hub.qgis.org however. If I created such account, how can I delete it?

Radim

On Sun, Jun 5, 2011 at 12:56 PM, Tim Sutton  wrote:
> Dear all
>
> The bulk of the migration has been carried out. The new tracker is
> available at[1]. There are still quite a number of outstanding issues.
> If you are logging in for the first time, I encourage you to first
> peruse our redmine project ticket queue[2] to familiarise yourself
> with known issues.  The trac project remains in a read only state, and
> unless testing over the next day or so reveals a critical issue with
> the redmine deployment, we will ask for automatic redirection of users
> from the old trac site to the new redmine site. I have also
> reorganised the projects a little more logically and made other
> general cleanups to the redmine instance. If you do encounter issues,
> please file at ticket in the redmine specific project [2] linked
> below.
>
>
> [1] http://hub.qgis.org/projects/quantum-gis
> [2] http://hub.qgis.org/projects/qgis-redmine/issues
>
> Once this is out of the way we will forge on with the QGIS 1.7 release!
>
> Regards
>
>
>
> --
> 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-user mailing list
> qgis-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Preparing for the release announcement - plugin manager site

[Alessandro Pasotti]

2011/6/13 Chris Crook 

> Just wondering how the new plugins repository relates to the existing user
> contributed plugins repo.
>
> Should we move plugins to the new one, and if so should we delete them from
> the existing repository, or is it fine to have two versions of the same
> plugin?
>


Hi,

please copy or move your plugins to the new site (we are actively working on
the development of the new site) and file a ticket on
http://hub.qgis.org/projects/qgis-django/issues if you find any issue.

Please notice that if you are not a staff or "trusted" user your plugins
will not be immediately published and a notification email will be sent to
all staff members.

Once a staff member will flag you as "trusted" you will be able to publish
your plugins.

The new site also supports:

* plugins icons
* tags classification (will be available in QGIS desktop)
* revisions (experimental  and stable)


--
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] qgis-mapserver: user authentication

[Giovanni Manghi]

Hi all,

On Thu, 2011-06-09 at 16:33 +0200, Paolo Cavallini wrote:
> Hi all.
> We are interested in an extension of current qgis-mapserver, allowing 
> different users
> (or groups of) to see different layers (or different projects).
> Is anyone working on that, or willing to collaborate on a mainstream solution?


what we need to develop is quite simple (to explain). Users should be
able to register/login in the webclient (users data stored in a
geometryless table in the qgis project?), then, depending on what user
group the user belong, show certain layers/groups in the TOC of the web
client. User data (name, address, etc.) should be stored after the login
to allow use them in the print layouts.

One way or another we will have to develop something like that, so we
would prefer to do it the right way, upstream and in a way that can be
useful to as much people as possible.

If anyone is interested in collaborate please us know.

Cheers

-- Giovanni --


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] a SQL console as new feature

[Nathan Woodrow]

Not really what Simon is getting at.  I guess not many people on here are
MapInfo users as well.  MapInfo's SQL allows you to query any datasource
using SQL, so you could do Select * From table1,Table2 where
table1.comecolumn > 10.

Where table2 is a shape file and table1 is a tab file.

@Simon Yes I think you "could" do it via a plugin although I'm not sure how
it would go on speed.  And stuff like this should really be built into the
program.  I'll investigate the plugin route if only as a prototype.

- Nathan

On Tue, Jun 14, 2011 at 9:18 AM, Noli Sicad  wrote:

> There is a new plugin - a console, Fast SQL Layer for QGIS.
>
> Have you seen this?
>
> http://underdark.wordpress.com/2011/05/25/fast-sql-layer-for-qgis/
>
> Noli
>
> On 6/14/11, Simon Georget  wrote:
> > Hi,
> >
> > Sorry to reply lately and thanks for your interest on this topic.
> > Nathan has done a good description of my request and reading from you
> make
> > me think it is not impossible.
> >
> > Do you think this can be developed as plugin?
> > If yes, I would be happy to work with some of you interested but
> > unfortunetly I don't think I could handle that alone, since I don't know
> the
> > QGIS API yet, I don't speak  fluently python (but I can play with it) and
> I
> > don't have that much time.
> >
> > Just let me know
> >
> > Regards,
> > simon
> >
> >
> >
> > On Wed, May 25, 2011 at 3:08 PM, Nathan Woodrow 
> wrote:
> >
> >> Thanks Martin,
> >>
> >> I'll check them out.  I have seen them before but never really looked
> into
> >> them.
> >>
> >> - Nathan
> >>
> >> On Wed, May 25, 2011 at 11:06 PM, Martin Dobias
> >> wrote:
> >>
> >>> QgsSearchString
> >>
> >>
> >>
> >> ___
> >> 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] a SQL console as new feature

[Noli Sicad]

There is a new plugin - a console, Fast SQL Layer for QGIS.

Have you seen this?

http://underdark.wordpress.com/2011/05/25/fast-sql-layer-for-qgis/

Noli

On 6/14/11, Simon Georget  wrote:
> Hi,
>
> Sorry to reply lately and thanks for your interest on this topic.
> Nathan has done a good description of my request and reading from you make
> me think it is not impossible.
>
> Do you think this can be developed as plugin?
> If yes, I would be happy to work with some of you interested but
> unfortunetly I don't think I could handle that alone, since I don't know the
> QGIS API yet, I don't speak  fluently python (but I can play with it) and I
> don't have that much time.
>
> Just let me know
>
> Regards,
> simon
>
>
>
> On Wed, May 25, 2011 at 3:08 PM, Nathan Woodrow  wrote:
>
>> Thanks Martin,
>>
>> I'll check them out.  I have seen them before but never really looked into
>> them.
>>
>> - Nathan
>>
>> On Wed, May 25, 2011 at 11:06 PM, Martin Dobias
>> wrote:
>>
>>> QgsSearchString
>>
>>
>>
>> ___
>> 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 Processing Framework

[Camilo Polymeris]

On Mon, Jun 13, 2011 at 10:15 AM, MALIK Julien  wrote:
> Hello,

Hello, Julien.
You bring up some very important points.

> Here are some remarks :
>
> - It's good to have deleted the Library class. I had no use of it. This
> makes the code much more simpler.
>
> - Is the Plugin class really necessary ? It does nothing now. Maybe it's
> better to remove it also, so each plugin can do what he wants during the
> import (maybe also create a specific gui for its own "general
> configuration"). The only thing important to be a "processing plugin" would
> be to register itself to the framework during initGui() and deregister
> itself in unload(). I think it would be more coherent with the way Qgis
> manages plugins (you could more easily enable/disable one of the
> implementations in the plugin manager, probably better for updates too)

Yes, you are correct, the processing.Plugin class does nothing -- does
no harm either, but agree on removing it.

> - I think a lot currently happen in the constructors and during the
> different module imports (loading of all the modules with their
> description/params/etc), and it would be good to lower it down.
> Currently we register "modules" to the framework.
> Could we instead register one main object which can be queried for a list of
> available modules (their names, description, tags, docs,...), for a list of
> general info to keep track of its provenance (is it "Saga", "OTB", ..., so
> that the framework knows easily how to differenciate them), and can create
> actual ModuleInstance on demand ? The idea would be that the framework ask
> things to the different implementations when it needs to, and not the other
> way around (as it is a singleton, i think it is safer that way)
> Also, IMHO the details of the different parameters of a module should not be
> taken into account as long as we don't create an instance of this module.

Also remove the arguments from the processing. Module constructor, and
have e.g. saga.Module override paramters(), name(), tags(), etc, so
that the relevant code only gets executed when necessary.
Each plugin would then be responsible for registering/deregistering
it's modules. Either passing a list or a callback to the framework.

On the provenance: I just had the saga implementation add a 'saga' tag
to every module. I think that's the simplest solution. It doesn't show
up currently, because, every module having that tag it is deemed
irrelevant by the framework.

> - about the gui part : should it be possible to create the specific widget
> for a parameter for which the framework does not provide a default ? i think
> so. Maybe it would make sense that each ModuleInstance can be queried for
> the widget, a default implementation being provided for all standard types.
> Even for the standard provided widgets, it could be nice to be able to
> simply subclass them to add our own things (not sure about this).

Implement parameter.widget(value) in a subclass if you want custom
widgets. That function should get called by
processingplugin.Dialog.widgetByType(), if present. Haven't tried it
yet, though.

Open for discussion if you think this is not the best way to handle this.

> - is there a need for keeping 2 modules (processing and processingplugin) ?
> can a plugin depend on another plugin (in my otb plugin can I "import
> processingplugin") ? if yes, putting everything in one plugin will make it
> more easy to distribute a version of the code (as long as it is python...).

But, YOU introduced 'processingplugin'! :D

I think it is a good idea to keep them both: QGIS plugins are
inherently GUI-related, they have a initGui method, after all. But,
the QGIS processing framework should work in a GUI agnostic way, so
that it will be useful in other environments, too. Having processing
for the logic & processingplugin for the GUI, forces us to keep both
aspects separated.

Perhaps the names are too similar, confusing... rename
processingplugin to processingPanel or processingGUI or something?

> - the panel should be more tied to the framework singleton : when a new
> plugin is loaded/unloaded, it should be possible to update the Panel for
> example (putting the gui initialization outside of the Panel constructor may
> help)

I am not sure of what you mean: I precisely tried to separate the
framework from the panel. What would be A Good Thing, I think, is
reimplementing the panel with QTreeView and the framework as a
ItemModel. That way the panel would get updated whenever the framework
changes.
What do you think?

> - the panel does not provide an easy way to differenciate between the
> different implementations (saga/otb...). Maybe a tag could be used for it,
> or maybe it should be given a different meaning (like the "main tag"). For
> later, you might want to add an easy way to enable/disable all the
> OTB/Saga/Gdal/ by just clicking on an icon ?

Agree: tags. Standard tags for now, I think. If we see the need to
introduce 'special tags' we can alway

Re: [Qgis-developer] Preparing for the release announcement - plugin manager site

[Alex Mandel]

Yes, please move your plugin over.
No need to delete it off the current site, at least not at this time.
Eventually that site will get turned off once the all the plugins are
moved and QGIS ships with the correct url to the new site.

Thanks,
Alex

On 06/13/2011 10:57 AM, Chris Crook wrote:
> Just wondering how the new plugins repository relates to the existing user 
> contributed plugins repo.
> 
> Should we move plugins to the new one, and if so should we delete them from 
> the existing repository, or is it fine to have two versions of the same 
> plugin?
> 
> Cheers
> Chris
> 
> ___
> From: Tim Sutton [li...@linfiniti.com]
> Sent: 13 June 2011 09:23
> To: qgis-developer
> Subject: [Qgis-developer] Preparing for the release announcement
> 
> Hi All
> 
> - Alessandro's new plugin manager site http://plugins.qgis.org
> 
> If you have time, could you take a moment to test these sites by:
> 
> - Upload any plugins you want to share to the http://plugins.qgis.org
> __
> 
> This message contains information, which is confidential and may be subject 
> to legal privilege. 
> If you are not the intended recipient, you must not peruse, use, disseminate, 
> distribute or copy this message.
> If you have received this message in error, please notify us immediately 
> (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message.
> LINZ accepts no responsibility for changes to this email, or for any 
> attachments, after its transmission from LINZ.
> 
> Thank you.
> __
> ___
> 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] Preparing for the release announcement - plugin manager site

[Chris Crook]

Just wondering how the new plugins repository relates to the existing user 
contributed plugins repo.

Should we move plugins to the new one, and if so should we delete them from the 
existing repository, or is it fine to have two versions of the same plugin?

Cheers
Chris

___
From: Tim Sutton [li...@linfiniti.com]
Sent: 13 June 2011 09:23
To: qgis-developer
Subject: [Qgis-developer] Preparing for the release announcement

Hi All

- Alessandro's new plugin manager site http://plugins.qgis.org

If you have time, could you take a moment to test these sites by:

- Upload any plugins you want to share to the http://plugins.qgis.org
__

This message contains information, which is confidential and may be subject to 
legal privilege. 
If you are not the intended recipient, you must not peruse, use, disseminate, 
distribute or copy this message.
If you have received this message in error, please notify us immediately (Phone 
0800 665 463 or i...@linz.govt.nz) and destroy the original message.
LINZ accepts no responsibility for changes to this email, or for any 
attachments, after its transmission from LINZ.

Thank you.
__
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] a SQL console as new feature

[Simon Georget]

Hi,

Sorry to reply lately and thanks for your interest on this topic.
Nathan has done a good description of my request and reading from you make
me think it is not impossible.

Do you think this can be developed as plugin?
If yes, I would be happy to work with some of you interested but
unfortunetly I don't think I could handle that alone, since I don't know the
QGIS API yet, I don't speak  fluently python (but I can play with it) and I
don't have that much time.

Just let me know

Regards,
simon



On Wed, May 25, 2011 at 3:08 PM, Nathan Woodrow  wrote:

> Thanks Martin,
>
> I'll check them out.  I have seen them before but never really looked into
> them.
>
> - Nathan
>
> On Wed, May 25, 2011 at 11:06 PM, Martin Dobias wrote:
>
>> QgsSearchString
>
>
>
> ___
> 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] Integrating OSSIM with QGIS

[Paolo Cavallini]

Il 13/06/2011 16:34, MALIK Julien ha scritto:

> The OrfeoToolbox has a similar pipeline concept which would be nice to make 
> available
> from the framework. Having another software with the same need will be 
> valuable, if
> not mandatory, to build the proper high level interface for this concept.

I think also the capability of piping together GRASS commands would be valuable.
Of course, piping all modules regardless of their origin would be *the* real 
killer.
All the best.

-- 
Paolo Cavallini: 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] Integrating OSSIM with QGIS

[MALIK Julien]

Hello

(4) In OSSIM we have a concept of image chains and connectable  
objects. You can wire up all kinds of filters and equations into a  
workflow to create an output image. The image chain can be  
represented using an array of key value pairs. Does the provider  
interface provide a mechanism for passing this type of information?


The concept of chains should be included in
https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework in my
opinion. So that chains can be created using data and tools from
various providers and packages.  Or at least, the framework should be
designed so, that it will allow later addition of chains on some upper
level.




As a first step, it will be interesting to know how the independent  
ossim processing modules can fit into the processing framework which  
is currently being built.
The OrfeoToolbox has a similar pipeline concept which would be nice to  
make available from the framework. Having another software with the  
same need will be valuable, if not mandatory, to build the proper high  
level interface for this concept.

Also, are you aware of http://trac.osgeo.org/ossim/wiki/GsocPyOssim ?

Regards,
Julien





This message was sent using IMP, the Internet Messaging Program.


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Processing Framework

[MALIK Julien]

Hello,

Here are some remarks :

- It's good to have deleted the Library class. I had no use of it.  
This makes the code much more simpler.


- Is the Plugin class really necessary ? It does nothing now. Maybe  
it's better to remove it also, so each plugin can do what he wants  
during the import (maybe also create a specific gui for its own  
"general configuration"). The only thing important to be a "processing  
plugin" would be to register itself to the framework during initGui()  
and deregister itself in unload(). I think it would be more coherent  
with the way Qgis manages plugins (you could more easily  
enable/disable one of the implementations in the plugin manager,  
probably better for updates too)


- I think a lot currently happen in the constructors and during the  
different module imports (loading of all the modules with their  
description/params/etc), and it would be good to lower it down.

Currently we register "modules" to the framework.
Could we instead register one main object which can be queried for a  
list of available modules (their names, description, tags, docs,...),  
for a list of general info to keep track of its provenance (is it  
"Saga", "OTB", ..., so that the framework knows easily how to  
differenciate them), and can create actual ModuleInstance on demand ?  
The idea would be that the framework ask things to the different  
implementations when it needs to, and not the other way around (as it  
is a singleton, i think it is safer that way)
Also, IMHO the details of the different parameters of a module should  
not be taken into account as long as we don't create an instance of  
this module.


- about the gui part : should it be possible to create the specific  
widget for a parameter for which the framework does not provide a  
default ? i think so. Maybe it would make sense that each  
ModuleInstance can be queried for the widget, a default implementation  
being provided for all standard types. Even for the standard provided  
widgets, it could be nice to be able to simply subclass them to add  
our own things (not sure about this).


- is there a need for keeping 2 modules (processing and  
processingplugin) ? can a plugin depend on another plugin (in my otb  
plugin can I "import processingplugin") ? if yes, putting everything  
in one plugin will make it more easy to distribute a version of the  
code (as long as it is python...).


- the panel should be more tied to the framework singleton : when a  
new plugin is loaded/unloaded, it should be possible to update the  
Panel for example (putting the gui initialization outside of the Panel  
constructor may help)


- the panel does not provide an easy way to differenciate between the  
different implementations (saga/otb...). Maybe a tag could be used for  
it, or maybe it should be given a different meaning (like the "main  
tag"). For later, you might want to add an easy way to enable/disable  
all the OTB/Saga/Gdal/ by just clicking on an icon ?


- I/O : how will this be handled ? I'm asking this related to the  
recent mails with interest for providing ossim image chains in Qgis.
If it must support module chaining, then there is a need for an  
abstraction of the i/o mechanism. is it the qgis dataproviders ? a  
module can take a raster/vector dataprovider as input and can output a  
raster/vector dataprovider ?


Keep up the good work !
Julien


Quoting Camilo Polymeris :


Applied your patches to my repo, Julien, thanks a lot!

What is your opinion on the function of the "QGIS Processing *plugin*"
-- just showing the panel? Or should perhaps everything gui-related be
moved into the plugin? Is it really necessary, couldn't the framework
singleton could just register the panel & associated menu items?

I intend to soon publish a prototype of the plugin(s) on the faunalia
repo, so that we'll hopefully have more feedback.

Regards,



Camilo







This message was sent using IMP, the Internet Messaging Program.


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] WMS Python again...

[Thomas Gratier]

Hello list,

I was looking for pyqgis cookbook and on wms step, I'm stuck in my test.
I search in archives and see
http://osgeo-org.1803224.n2.nabble.com/Re-RE-Qgis-user-WMS-in-python-td2039236.htmland
http://osgeo-org.1803224.n2.nabble.com/Re-WMS-in-python-td2048465.html
but the first link is the cookbook recipe and the FRMT sample won't work too
for me.
It's related to my install? only my code ? Someone get clues to solve this,
please?
You will find below my tests both in command line and qgis python console.
I'm working on Ubuntu 10.04 and my Qgis (1.6) is from on
https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable

Regards

ThomasG
GIS specialist

# IN COMMAND LINE

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from qgis.core import *
from qgis.gui import *
import os
# Import our GUI
# Environment variable QGISHOME must be set to the install directory
# before running the application
qgis_prefix = os.getenv("QGISHOME") # Set to /usr (on Ubuntu 10.04)

QgsApplication.setPrefixPath(qgis_prefix, True)
QgsApplication.initQgis()

# Cookbook sample
url = 'http://wms.jpl.nasa.gov/wms.cgi'
layers = ['global_mosaic']
styles = ['pseudo']
format = 'image/jpeg'
crs = 'EPSG:4326'
rlayer = QgsRasterLayer(0, url, 'some layer name', 'wms', layers, format,
crs) # Freeze here
QgsMapLayerRegistry.instance().addMapLayer(rlayer)
if not rlayer.isValid():
  print "Layer failed to load!"

# Test with GDAL driver
rLayer2 =
QgsRasterLayer('/home/thomas/git/frmt_wms_onearth_global_mosaic.xml','Test')
# using file from http://www.gdal.org/frmt_wms_onearth_global_mosaic.xml
QgsMapLayerRegistry.instance().addMapLayer(rlayer2)

QgsApplication.exitQgis()

# QGIS PYTHON CONSOLE

# Cookbook sample
url = 'http://wms.jpl.nasa.gov/wms.cgi'
layers = ['global_mosaic']
styles = ['pseudo']
format = 'image/jpeg'
crs = 'EPSG:4326'
rlayer = QgsRasterLayer(0, url, 'some layer name', 'wms', layers, format,
crs) # Freeze here
rlayer.isValid() # Return true
QgsMapLayerRegistry.instance().addMapLayer(rlayer) # Don't see anything
rendering
#or
qgis.utils.iface.addRasterLayer(url, 'some layer name', 'wms', layers,
styles, format, crs)

# Test with GDAL driver
rLayer2 =
QgsRasterLayer('/home/thomas/git/frmt_wms_onearth_global_mosaic.xml','Test')
# using file from http://www.gdal.org/frmt_wms_onearth_global_mosaic.xml #
Failed with layer is not defined
QgsMapLayerRegistry.instance().addMapLayer(rlayer2)
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Processing Framework

[Paolo Cavallini]

Il 13/06/2011 02:03, Camilo Polymeris ha scritto:
>> Or should perhaps everything gui-related be
>> moved into the plugin?
> 
> Did this. It is probably cleaner to keep gui code out of the framework.

Sounds reasonable to me.
Thanks.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer