[QGIS-Developer] Plugin [1287] qpals approval notification.

[noreply]

Plugin qpals approval by zimbogisgeek.
The plugin version "[1287] qpals 1.5.1" is now approved
Link: http://plugins.qgis.org/plugins/qpals/
___
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] AppImage packaging of Qgis?

[Patrick Dunford]

Is there a consensus on the pros and cons of the three different systems 
mentioned so far?



On 20/11/17 20:21, Luca Manganelli wrote:
On Mon, Nov 20, 2017 at 8:19 AM, Patrick Dunford 
mailto:enzedrailm...@gmail.com>> wrote:


Good day

Is there any consideration to using AppImage packaging for Qgis in
future.

Obviously we see the ability to have multiple versions installed
and be
able choose between them as a key advantage of AppImage.


+
​1. For me it's a fantastic idea! We should consider also flatpak, 
snap...​





___
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] AppImage packaging of Qgis?

[Richard Duivenvoorde]

On 20-11-17 08:19, Patrick Dunford wrote:
> Good day
> 
> Is there any consideration to using AppImage packaging for Qgis in future.
> 
> Obviously we see the ability to have multiple versions installed and be
> able choose between them as a key advantage of AppImage.

Matthias did some experiments:

https://github.com/qgis/QGIS/pull/3784

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

Re: [QGIS-Developer] OTF layer reprojection not working in latest master ?

[Patrick Dunford]

Oh, I'm just giving you the opportunity to say "this is not a bug, it's 
expected the project file format has changed" or something like that?



On 20/11/17 20:22, Andreas Neumann wrote:


Hi Patrick,

Can you please file an issue report and provide some sample data and 
project to demonstrate the issue?


It would help the devs to fix this issue, if it is reproducible.

Thanks,

Andreas

On 2017-11-20 08:18, Patrick Dunford wrote:


I have a project that (I just discovered) has some layers in EPSG 4326,

the project is EPSG 3857

When I changed the project from EPSG 4326 to EPSG 3857 these layers were
being reprojected on the fly, all the others were resaved into EPSG 3857

Everything has been working fine on 2.14, 2.16, 2.18 and all the masters
up till now, when I just installed the latest master f1c3692. these
layers are not visible in the canvas. I assume this must be an issue
with OTF reprojection. All the other layers that don't rely on OTF are
displayed.



___
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] OTF layer reprojection not working in latest master ?

[Andreas Neumann]

Hi Patrick, 

Can you please file an issue report and provide some sample data and
project to demonstrate the issue? 

It would help the devs to fix this issue, if it is reproducible. 

Thanks, 

Andreas 

On 2017-11-20 08:18, Patrick Dunford wrote:

> I have a project that (I just discovered) has some layers in EPSG 4326,
> 
> the project is EPSG 3857
> 
> When I changed the project from EPSG 4326 to EPSG 3857 these layers were
> being reprojected on the fly, all the others were resaved into EPSG 3857
> 
> Everything has been working fine on 2.14, 2.16, 2.18 and all the masters
> up till now, when I just installed the latest master f1c3692. these
> layers are not visible in the canvas. I assume this must be an issue
> with OTF reprojection. All the other layers that don't rely on OTF are
> displayed.
> 
> ___
> 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] AppImage packaging of Qgis?

[Luca Manganelli]

On Mon, Nov 20, 2017 at 8:19 AM, Patrick Dunford 
wrote:

> Good day
>
> Is there any consideration to using AppImage packaging for Qgis in future.
>
> Obviously we see the ability to have multiple versions installed and be
> able choose between them as a key advantage of AppImage.
>

+
​1. For me it's a fantastic idea! We should consider also flatpak, snap...​
___
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] AppImage packaging of Qgis?

[Patrick Dunford]

Good day

Is there any consideration to using AppImage packaging for Qgis in future.

Obviously we see the ability to have multiple versions installed and be
able choose between them as a key advantage of AppImage.

Thoughts?


___
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] OTF layer reprojection not working in latest master ?

[Patrick Dunford]

I have a project that (I just discovered) has some layers in EPSG 4326,

the project is EPSG 3857

When I changed the project from EPSG 4326 to EPSG 3857 these layers were
being reprojected on the fly, all the others were resaved into EPSG 3857

Everything has been working fine on 2.14, 2.16, 2.18 and all the masters
up till now, when I just installed the latest master f1c3692. these
layers are not visible in the canvas. I assume this must be an issue
with OTF reprojection. All the other layers that don't rely on OTF are
displayed.



___
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] Preview job and slow datasources

[Patrick Dunford]

I heard these suggestions, but my project has a very short life, so I 
haven't got the time to experiment really.



On 17/11/17 23:38, Even Rouault wrote:


On vendredi 17 novembre 2017 23:14:19 CET Patrick Dunford wrote:

> I understand (especially with the other comments about the functionality

> and having to wait for images to be retrieved from servers) what you

> guys are trying to achieve with this feature, but in my project the

> rasters I have loaded cover hundreds of square kilometres, and Qgis

> caches all of them, regardless of how far they are from the particular

> point where I am working on a map.

>

If your rasters are in the same projection and same resolution, did 
you consider building a virtual .VRT catalog from them ? (or group 
them in catalogs per projection and resolution). That could reduce the 
number of layers.


> On 17/11/17 21:56, Alessandro Pasotti wrote:

> > Maybe a crazy idea, but if this proves to be an issue, what about a

> > monitoring process that prompts the user to disable this feature when

> > memory goes over a certain threshold?

> >

> > On Fri, Nov 17, 2017 at 8:21 AM, Patrick Dunford

> >

> > mailto:enzedrailm...@gmail.com>> wrote:

> > Most of them are geoJpeg, there are a smaller number of geoTiff

> >

> > On 17/11/17 20:10, Matthias Kuhn wrote:

> >> Thanks, that's an interesting information.

> >>

> >> What datatype are your rasters?

> >>

> >> On 11/17/2017 03:53 AM, Patrick Dunford wrote:

> >>> With the second command

> >>>

> >>> iface.mapCanvas().setPreviewJobsEnabled(False)

> >>>

> >>> when I run that command it drops back to 16 GB

> >>>

> >>> On 16/11/17 23:15, Matthias Kuhn wrote:

>  Hi Patrick,

> 

>  Would be interesting to do this test with previews enabled and

>  disabled. Then we'll see if it's actually the previews or some

>  other mechanism that is causing this.

> 

>  IIRC only a composite image is saved in the preview jobs and

>  not each layer separately, but that's just what I remember and

>  not evidence based.

> 

>  You can enable them in the python console with

> 

>      iface.mapCanvas().setPreviewJobsEnabled(True)

> 

>  and disable with

> 

>      iface.mapCanvas().setPreviewJobsEnabled(False)

> 

>  Thanks for a feedback

> 

>  Matthias

> 

>  On 11/16/2017 08:42 AM, Patrick Dunford wrote:

> > In my current project using Qgis 2.99, turning off the rasters

> > uses 16 GB, turning them on uses 52 GB

> >

> > I do not believe it is independent from the number of layers

> > that are being displayed.

> >

> > Previous versions of the software did not cache every single

> > raster (the number of rasters actually being displayed on the

> > canvas at any one time is a small fraction of the total number

> > in the project)

> >

> > On 16/11/17 20:11, Matthias Kuhn wrote:

> >> Hi Patrick,

> >>

> >> This uses some memory (~ canvas width pixels * canvas height

> >> pixels * 8 preview images * 32 bit RGBA), so let's assume 50

> >> MB to 100 MB.

> >>

> >> This consumption is independent from the number or type of

> >> layers.

> >>

> >> Matthias

> >>

> >> On 11/16/2017 08:02 AM, Patrick Dunford wrote:

> >>> So to put it another way this is the reason why Qgis wants

> >>> to use a huge amount of memory (40 GB) when I have a lot of

> >>> raster images loaded in the background.

> >>>

> >>> On 16/11/17 18:56, Tim Sutton wrote:

>  Hi

> 

> > On 16 Nov 2017, at 04:35, Patrick Dunford

> > mailto:enzedrailm...@gmail.com>>

> > wrote:

> >

> > What is this "preview job" function?

> 

>  Its application logic to prefetch / pre-render offscreen

>  content in anticipation of user panning the map.

> 

>  Regards

> 

>  Tim

> 

> > ___

> > 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

> > 

> 

>  —

> 

> 

> 

> 

> 

> 

>  *Tim Sutton*

> 

>  *Co-founder:*Kartoza

>  *Project chair:*QGIS.org 

> 

>  Visit http://kartoza.com  to find out

>  about open source:

> 

>  Desktop GIS programming services

>  Geospatial web development

Re: [QGIS-Developer] Qt4 Designer - custom widgets - Manjaro

[Denis Rouzaud]

Hi Anjo,
Can you look in the about menu, there is a plugin entry, see if qgis custom
widgets are listed there as broken.
If so, can you try
ldd   /lib64/qt4/plugins/designerlibqgis_customwidgets.so

Cheers
Denis

Le dim. 19 nov. 2017 à 12:00, anjo.weichbrodt  a
écrit :

> Hi Matthias,
>
> libqgis_customwidgets.so seems to be in the right location.
>
> [anjo@anjo-pc ~]$ cd  /lib64/qt4/plugins/designer/
> [anjo@anjo-pc designer]$ ls
> libpyqt4.so   libqt3supportwidgets.so
> libqdeclarativeview.solibqwebview.so
> libqgis_customwidgets.so  libqwt_designer_plugin.so
> libqgis_customwidgets.so.2.18.14  libqwt_polar_designer_plugin.so
> libqscintillaplugin.so
>
> Other suggestions?
> Thanks,
> Anjo
>
>
>
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> ___
> 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 plugins and thread safety

[Martin Dobias]

Hi Alessandro

On Sun, Nov 19, 2017 at 10:34 AM, Alessandro Pasotti  wrote:
> Hi,
>
> mi recent experiments with multi-threaded python wrappers for QGIS server
> showed a critical flaw in my original implementation of the server plugins.
>
> First, I want to stress that this is not a problem in FCGI server
> implementation but only if the server is used directly from python in a
> multi threaded server implementation.
>
> The problem is that the server interface that exposes the request handler is
> a static property of the interface, that is changed on every request.
> This means that there is a race condition in setting/accessing the handler
> from a plugin filter, and that a plugin filter might access to the handler
> for a wrong request.

I think this is probably just the tip of the iceberg: most of the
classes in qgis_core are not thread-safe, and I believe the
implementation of server's services is not expected to be run in
multiple threads at once either. So even though things in theory could
work if requests are handled in multiple threads, most likely there
will be crashes. Even though map rendering was made to run safe in
multiple worker threads, there is still the assumption that the map
rendering is started from the main thread where all the objects live
(I'm talking about the QObject-based classes). Dealing with objects
like map layers or project in non-main thread is likely to end up
badly.

I would say for now we should simply stick with handling only one
request per server process at a time - just like how it is done with
the FastCGI implementation.

Cheers
Martin
___
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 plugins and thread safety

[David Marteau]

Hi,

IMHO, The multi process approach has to be preferred over  multi-threading

Some thought about it:

Forking sever instance for each request is imho a bad idea as it is not 
scalable and defeat resource  control.

I think that it is not a problem  by itself to consider the server engine as 
single worker process:  there is numerous cases where it is much better handled 
using appropriates tools:

- Use supervisor with fcgi prefork to handle a pool of server (not sure is is 
appropriate here)
- Embed the server in a asynchronous framework (like tornado, or python 3 
asyncio) and use multiprocessing to handle your server workers.
- Embed as wsgi  application and use gunicorn mumérous options to handle 
requests queues and the number workers.
…


David. 


IMHO this can be handled in much better way with other tools:

> Le 19 nov. 2017 à 10:34, Alessandro Pasotti  a écrit :
> 
> Hi,
> 
> mi recent experiments with multi-threaded python wrappers for QGIS server 
> showed a critical flaw in my original implementation of the server plugins.
> 
> First, I want to stress that this is not a problem in FCGI server 
> implementation but only if the server is used directly from python in a multi 
> threaded server implementation.
> 
> The problem is that the server interface that exposes the request handler is 
> a static property of the interface, that is changed on every request.
> This means that there is a race condition in setting/accessing the handler 
> from a plugin filter, and that a plugin filter might access to the handler 
> for a wrong request.
> 
> The solution is to pass the request handler (or the request and/or response 
> objects depending on the filter) to the plugin filters and leave the 
> interface for static properties only.
> 
> This would be a big API change for the server interface and filters and I'm 
> not sure we have time/resources to do that now.
> 
> As an alternative we could simply document the issue and change the testing 
> code to create a new server instance to server every request (to be verified, 
> and with consitent performance degradation).
> 
> What's your opinion about this issue?
> 
> BTW,  tomorrow I'll file a ticket for this problem.
> 
> -- 
> 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

___
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] Qt4 Designer - custom widgets - Manjaro

[anjo.weichbrodt]

Hi Matthias,

libqgis_customwidgets.so seems to be in the right location.

[anjo@anjo-pc ~]$ cd  /lib64/qt4/plugins/designer/
[anjo@anjo-pc designer]$ ls
libpyqt4.so   libqt3supportwidgets.so
libqdeclarativeview.solibqwebview.so
libqgis_customwidgets.so  libqwt_designer_plugin.so
libqgis_customwidgets.so.2.18.14  libqwt_polar_designer_plugin.so
libqscintillaplugin.so

Other suggestions?
Thanks,
Anjo



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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 plugins and thread safety

[Alessandro Pasotti]

Maybe I've found a simple and effective no-API-break solution: I'm working
on a QThreadStorage based implementation of the server iface request
handler that might be the simplest solution to this issue.

Btw this is only one of the most obvious issues in the server thread
safety, there are certainly more areas that need to be checked before we
can say that QgsServer class it thread-safe.

Happy sunday :)



On Sun, Nov 19, 2017 at 10:34 AM, Alessandro Pasotti 
wrote:

> Hi,
>
> mi recent experiments with multi-threaded python wrappers for QGIS server
> showed a critical flaw in my original implementation of the server plugins.
>
> First, I want to stress that this is not a problem in FCGI server
> implementation but only if the server is used directly from python in a
> multi threaded server implementation.
>
> The problem is that the server interface that exposes the request handler
> is a static property of the interface, that is changed on every request.
> This means that there is a race condition in setting/accessing the handler
> from a plugin filter, and that a plugin filter might access to the handler
> for a wrong request.
>
> The solution is to pass the request handler (or the request and/or
> response objects depending on the filter) to the plugin filters and leave
> the interface for static properties only.
>
> This would be a big API change for the server interface and filters and
> I'm not sure we have time/resources to do that now.
>
> As an alternative we could simply document the issue and change the
> testing code to create a new server instance to server every request (to be
> verified, and with consitent performance degradation).
>
> What's your opinion about this issue?
>
> BTW,  tomorrow I'll file a ticket for this problem.
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>



-- 
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 plugins and thread safety

[Luigi Pirelli]

I didn't follow, shared cache is a solved problem for the server?
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 19 November 2017 at 10:34, Alessandro Pasotti  wrote:
> Hi,
>
> mi recent experiments with multi-threaded python wrappers for QGIS server
> showed a critical flaw in my original implementation of the server plugins.
>
> First, I want to stress that this is not a problem in FCGI server
> implementation but only if the server is used directly from python in a
> multi threaded server implementation.
>
> The problem is that the server interface that exposes the request handler is
> a static property of the interface, that is changed on every request.
> This means that there is a race condition in setting/accessing the handler
> from a plugin filter, and that a plugin filter might access to the handler
> for a wrong request.
>
> The solution is to pass the request handler (or the request and/or response
> objects depending on the filter) to the plugin filters and leave the
> interface for static properties only.
>
> This would be a big API change for the server interface and filters and I'm
> not sure we have time/resources to do that now.
>
> As an alternative we could simply document the issue and change the testing
> code to create a new server instance to server every request (to be
> verified, and with consitent performance degradation).
>
> What's your opinion about this issue?
>
> BTW,  tomorrow I'll file a ticket for this problem.
>
> --
> 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
___
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] QGIS Server plugins and thread safety

[Alessandro Pasotti]

Hi,

mi recent experiments with multi-threaded python wrappers for QGIS server
showed a critical flaw in my original implementation of the server plugins.

First, I want to stress that this is not a problem in FCGI server
implementation but only if the server is used directly from python in a
multi threaded server implementation.

The problem is that the server interface that exposes the request handler
is a static property of the interface, that is changed on every request.
This means that there is a race condition in setting/accessing the handler
from a plugin filter, and that a plugin filter might access to the handler
for a wrong request.

The solution is to pass the request handler (or the request and/or response
objects depending on the filter) to the plugin filters and leave the
interface for static properties only.

This would be a big API change for the server interface and filters and I'm
not sure we have time/resources to do that now.

As an alternative we could simply document the issue and change the testing
code to create a new server instance to server every request (to be
verified, and with consitent performance degradation).

What's your opinion about this issue?

BTW,  tomorrow I'll file a ticket for this problem.

-- 
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