[QGIS-Developer] Plugin [1616] Hqgis approval notification.

[noreply]

Plugin Hqgis approval by pcav.
The plugin version "[1616] Hqgis 0.4.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/Hqgis/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Accessing GRASS GIS addons from within QGIS

[Nikos Alexandris]

* Nyall Dawson  [2019-02-07 17:05:14 +1000]:


On Thu, 7 Feb 2019 at 01:41, Nikos Alexandris  wrote:


2) For the Processing Toolbox, my understanding is that it requires
significant effort to reflect the logic of a GRASS GIS module using
QGIS' Processing interface to GRASS GIS.  Am I wrong?

If I go for the Processing option, however, is it possible to inegrate a
GRASS GIS add-on under the QGIS' Processing GRASS provider, at run-time?

Essentially, is it possible to write (new) "description" files under
`python/plugins/processing/algs/grass7/description/` which are likely
placed under directories owned by the root/admin user?



If none of the above can ensure access to a GRASS GIS add-on through
QGIS, one that is to be installed using `g.extension` after having
installed QGIS and GRASS GIS, what would you then recommend?


My recommendation:

I would implement expose your GRASS add-on as its own processing
provider. You would base this almost entirely off the existing
processing grass provider, but with its own set of description files
exposing only your add on modules. You should be able to do this by
importing the existing grass provider classes, and overwriting the
provider code to have a new ID/name/icon/etc.

This would also make it easy to redistribute - you'd wrap your
provider into a plugin, and then could distribute via the normal
plugin channels. And if you do it right (and only import existing
processing grass code, minimising the copy/paste of this code), then
you're provider will automatically inherit any future fixes and
features added to the main grass provider.


Dear Nyal,

thank you for your time and the recommendation.  I guess this is
currently the only reasonable approach to distribute the "provider" and the
plugin.

Kind regards, Nikos


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Updating a WMS layer's legend with the same style as the one used by the data provider

[Ricardo Filipe Soares Garcia da]

Hi all

I have a working python code snippet that enables updating a WMS layer with
a different named style.

It basically manipulates the raster provider's `dataSourceUri` property,
replacing the `style=` with a different substring. and then it calls for a
reload of the data and triggers a repaint of the layer. Something like this:

```
provider = layer.dataProvider()
original_uri = provider.dataSourceUri()
new_uri = modify_uri(original_uri)
provider.setDataSourceUri(new_uri)
provider.reloadData()
provider.dataChanged.emit()
```

It is working fine and the layer is shown with the updated style. Now I'd
like to have also the layer's legend be refreshed with the correct style.

Is this possible?

I've tried

```
iface.layerTreeView().refreshLayerSymboogy(layer.id())
```

This does not work, I am monitoring the WMS server's logs and I don't see
any new `GetLegendGraphic` request being issued.

Thanks in advance

-- 
___ ___ __
Ricardo Garcia Silva
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [292] ZoomRC approval notification.

[noreply]

Plugin ZoomRC approval by pcav.
The plugin version "[292] ZoomRC 0.6.1" is now approved
Link: http://plugins.qgis.org/plugins/zoomrc/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1605] Local Dominance Visualisation approval notification.

[noreply]

Plugin Local Dominance Visualisation approval by pcav.
The plugin version "[1605] Local Dominance Visualisation 1.0.1 Experimental" is 
now approved
Link: http://plugins.qgis.org/plugins/local_dominance/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1605] Local Dominance Visualisation approval notification.

[noreply]

Plugin Local Dominance Visualisation approval by pcav.
The plugin version "[1605] Local Dominance Visualisation 0.1.1 Experimental" is 
now approved
Link: http://plugins.qgis.org/plugins/local_dominance/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] 2.18 and redmine - some questions

[DelazJ]

Hi,

Le lun. 21 janv. 2019 à 00:49, Jürgen E. Fischer  a écrit :

>
> Hi Nyall,
>
> On Mon, 21. Jan 2019 at 07:34:20 +1000, Nyall Dawson wrote:
> > 1. Can we remove the 2.x options from affected versions for new
> > tickets, so that users can no longer file bugs against these versions?
>
> Done.
>
> > 2. Is there anyway to mass-update bug reports? I'd like to see any
> > open bug which is has an affected version of 2.x changed to
> > "feedback", with a message "please test with QGIS 3.4 -- 2.18 is no
> > longer supported". Is this kind of thing possible?
>
> In the issue list there is a context menu.  Done.
>
> It looks like some 2.18.x or (old)master reports did not get the updates.
See eg https://issues.qgis.org/issues/16937 or
https://issues.qgis.org/issues/16434 or https://issues.qgis.org/issues/16497
and more... unless I misunderstand what was done.

Regards,
Harrissou

> > Potentially we can mass close nearly 1000 bugs by doing this and then
> > (automatically?) closing after a month if no feedback is obtained.
>
> Not sure if there is a automatism for this.  Bu we can filter issues and
> mass
> update them.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
> Datenschutzerklaerung: https://www.norbit.de/83/
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Server WMSRequestDefinedDataSources configuration option

[Alessandro Pasotti]

Hi Marco,

thank you for the clarifications, I think that if that option is not
implemented in the current server version we should drop it, I'll take care
of it.



On Fri, Feb 8, 2019 at 11:00 AM Marco Hugentobler <
marco.hugentob...@sourcepole.ch> wrote:

> Hi Alessandro
> Am 08.02.19 um 08:33 schrieb Alessandro Pasotti:
>
> Hi all,
>
> I've found this WMSRequestDefinedDataSources option in the code (exposed
> in the Server GUI settings as "Allow defining datasources in server
> requests"), it is apparently unused.
>
> First question: what was it for?
>
> It was possible to request dynamically created vector and raster layers by
> giving path/datasource information to the server (tags RemoteRDS /
> RemoveVDS as SLD extension). To avoid potential security risks, the option
> 'Allow defining datasources in server requests' is off by default.
>
>
> Second question: ok to remove it or is anybody willing to add an
> implementation in a reasonable time?
>
>
> We don't use it in the current projects, so I don't have a strong opinion
> here.
>
>
> Regards,
>
> Marco
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
> ___
> QGIS-Developer mailing listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, switzerlandmarco.hugentob...@sourcepole.ch 
> http://www.sourcepole.ch
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Server WMSRequestDefinedDataSources configuration option

[Marco Hugentobler]

Hi Alessandro

Am 08.02.19 um 08:33 schrieb Alessandro Pasotti:

Hi all,

I've found this WMSRequestDefinedDataSources option in the code 
(exposed in the Server GUI settings as "Allow defining datasources in 
server requests"), it is apparently unused.


First question: what was it for?


It was possible to request dynamically created vector and raster layers 
by giving path/datasource information to the server (tags RemoteRDS / 
RemoveVDS as SLD extension). To avoid potential security risks, the 
option 'Allow defining datasources in server requests' is off by default.




Second question: ok to remove it or is anybody willing to add an 
implementation in a reasonable time?



We don't use it in the current projects, so I don't have a strong 
opinion here.



Regards,

Marco




--
Alessandro Pasotti
w3: www.itopen.it 

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Module not recognized in Python

[Paul Riedel]

The files are unzipped into \omf\ and they have an __init__.py file in 
that folder, it should at least FIND it...


Am 06.02.2019 um 15:34 schrieb Richard Duivenvoorde:

On 2/6/19 12:04 PM, Paul Riedel wrote:

Dear Devs.

Kind of a help request here. Usually I would ask in a Discord or some
other chat program but there doesn't seem to be one?
I am trying to write a plugin to import Open Mining Format data into
QGIS(and maybe export it??)
Anyway, I went through the process of setting up a new plugin through
the Plugin Creator Plugin, went through the hassle of doing the
resources on Windows by doing
https://gis.stackexchange.com/questions/273552/pyrcc5-is-not-recognized-as-an-internal-or-external-command

since OS4Geo-shell doesn't recognize the bin and has no access to the
.exe for some reason.

So the plugin initializes and shows in QGIS.
Now, I copied the OMF library files into my plugin folder so now it
contains
python\plugins\omf_loader\omf\
However, upon trying to import the library by calling "import omf" or
"from . import omf" in the "run" Method, I get the error that the
library can not be found.
This is weird since I had a look at other plugins and they also use
local imports for helper functions...


Can you provide any help?

Hi Paul,

besides the mailinglist there is a irc channel and a gitter channel
(with a bridge to the irc and vv):
https://gitter.im/qgis/QGIS

But indeed this should work, something like

from .omf.base import UidModel

maybe?
Are you sure you have the python files unzipped there?


Regards,

Richard Duivenvoorde

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] The correct import Qt5 in plugins

[Richard Duivenvoorde]

On 2/7/19 9:51 PM, Xavier Corredor Llano wrote:
> On Thursday, 7 February 2019 13:00:48 -05 matteo wrote:
>> better to use
>>
>> from qgis.PyQt import uic
>>
>> so it is QGIS directly that handles the correct PyQt version to import
> 
> that's make sense, thanks Matteo for your answer.
> 
> Regards,
> Xavier Corredor Ll.

@Xavier: some historical background: with the move from qt4->qt5 even
simple plugins written for both python2 and python3 could not be run in
both QGIS/Qt versions because there was always this

from PyQt{VERSION} import QtX

in the Plugins

By abstracting out the version we 'hide' this and make an upcoming Qt
upgrade easier.
It was also possible to fix some things in between.

Regards,

Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer