Re: [QGIS-Developer] PyQGIS unavailable at QGIS startup time on OSGeo4W

[Eric Lemoine]

On Wed, 2 Oct 2019 12:32:21 +0200
Jürgen E. Fischer  wrote:

> Hi Eric,
> 
> On Wed, 02. Oct 2019 at 11:32:36 +0200, Eric Lemoine wrote:
> > Hi QGIS devs!
> > 
> > I need to use a PyQGIS startup script (set via the PYQGIS_STARTUP
> > envvar). And I want to do "import qgis" from that startup script!
> > 
> > It works on Linux, because PyQGIS is installed in the system-wide
> > Python environment. So no problem here.
> > 
> > But it doesn't work with OSGeo4W. OSGeo4W installs PyQGIS in
> > C:/OSGeo4W64/apps/qgis/python, and that path isn't in sys.path when
> > my startup script is executed.
> > 
> > The C:\OSGeo4W64\bin\qgis-bin.env file indeed does not set
> > PYTHONPATH. Likewise, the C:\OSGeo4W64\bin\py3_env.bat file, which
> > C:\OSGeo4W64\bin\qgis.bat includes, has "SET
> > PYTHONPATH=" (PYTHONPATH set to nothing).
> > 
> > What do you think? Shouldn't OSGeo4W set PYTHONPATH to
> > "%OSGEO4W_ROOT%\apps\qgis\python;%PYTHONPATH%" in py3_env.bat and
> > qgis-bin.env for startup scripts to be able to import and use the
> > qgis module?  
> 
> No. py3_env.bat belongs to osgeo4w's python and just switches to
> python3.  It shouldn't know about qgis.  It's used with everything
> that use python3 (eg. several qgis versions).


Ok right.


> 
> Not sure why PYQGIS_STARTUP is used that early.  The python path is
> added shortly after it was referenced:
> 
> https://github.com/qgis/QGIS/blob/master/src/python/qgspythonutilsimpl.cpp#L98


Yep saw that. And I was wondering too.



> So other platforms should have the same issue.


Except that there's no probleme on Linux, because PyQGIS is installed
globally in the main Python environment.

So Jürgen, would you suggest to change the QGIS code?

-- 
Éric Lemoine
Oslandia

___
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] PyQGIS unavailable at QGIS startup time on OSGeo4W

[Eric Lemoine]

Hi QGIS devs!

I need to use a PyQGIS startup script (set via the PYQGIS_STARTUP
envvar). And I want to do "import qgis" from that startup script!

It works on Linux, because PyQGIS is installed in the system-wide
Python environment. So no problem here.

But it doesn't work with OSGeo4W. OSGeo4W installs PyQGIS in
C:/OSGeo4W64/apps/qgis/python, and that path isn't in sys.path when my
startup script is executed.

The C:\OSGeo4W64\bin\qgis-bin.env file indeed does not set PYTHONPATH.
Likewise, the C:\OSGeo4W64\bin\py3_env.bat file, which
C:\OSGeo4W64\bin\qgis.bat includes, has "SET PYTHONPATH=" (PYTHONPATH
set to nothing).

What do you think? Shouldn't OSGeo4W set PYTHONPATH to
"%OSGEO4W_ROOT%\apps\qgis\python;%PYTHONPATH%" in py3_env.bat and
qgis-bin.env for startup scripts to be able to import and use the qgis
module?

Thanks!

-- 
Éric Lemoine
Oslandia

___
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 issue: bounding box issues

[Eric Lemoine]

On Thu, 9 May 2019 11:51:25 +0200
René-Luc Dhont  wrote:

> In QGIS Server, the layer extent is used to restrict the rendering to 
> the WMS layer extent.

I don't observe this.  I'd be interested to know where is the QGIS
(Server) code this restriction is implemented.  Thank you.




-- 
Éric Lemoine
Oslandia


pgpi4RQdajRWr.pgp
Description: OpenPGP digital signature
___
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 issue: bounding box issues

[Eric Lemoine]

On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann  wrote:

> Hi QGIS (server) devs,

Hi Andreas

> 
> We came across issues around calculating bounding boxes in QGIS
> server.
> 
> 1. Layers with only one point feature:
> 
> If a layer contains only one single point feature, QGIS server 
> calculates a bounding box where the minx equals maxx and miny equals 
> maxy, so resulting in a bounding box without a width and height.
> Sounds logical to QGIS server developers,


Yes. The BBOX of a point has minx=maxx and miny=maxy.  Even PostGIS says
so :)


> but combined with the fact
> that QGIS server doesn't take into account rendered symbol sizes
> (another issue we have, see issue nr 2), it means that no WMS client
> will ever see this one single symbol rendered, which can't be the
> solution here ...


If the GetMap request's BBOX param is set to the layer extent (the
BBOX with no dimension here) then it makes sense that there's nothing
rendered in the resulting image.  If the GetMap request's BBOX param is
set to a BBOX that contains the layer extent then the point should be
rendered in the resulting image.

So to me this is a client issue, not a QGIS Server issue.


> 2. Layer bounding boxes do not take into account rendered symbol
> sizes:
> 
> Please have a look at 
> http://www.carto.net/neumann/temp/qgis_server_bounding_box_issue.png
> - The green rectangle and the green arrows are not part of the QGIS
> server rendering, but they are added as an annotation to the rendered
> QGIS server graphics, to highlight the issues.


What software do you use on the client side?  Does the green
rectangle correspond to the BBOX requested by the client?  And does the
requested BBOX equal the layer extent in this case?  Or does it contain
the layer extent?

I may be wrong but I understand that the requested BBOX (the green
rectangle) is the layer extent.  And in that case it makes sense that
the symbols are cut for points that are closed to the boundaries.  Again
it's a client issue.


> Here we have the issue that QGIS server only uses the "raw" geometry
> of point symbols without taking into account rendered symbol sizes.
> Now, I do understand that calculating symbol sizes is scale dependent
> and there is no single solution to that, but again, I think the
> current behavior of QGIS server (simply cutting off symbols at layer
> bounding boxes) is not a good and nice behavior. At least, I think
> the author of the WMS service should have a chance to define an extra
> margin to be added to the bounding boxes of the raw geometries of the
> point layer, either as a "per project" or "per layer" QGIS server
> configuration.
> 
> @Andrea: I wonder what Geoserver does in such cases?
> 
> Any thoughts how to solve these issues? The current behavior of QGIS 
> server is not satisfactory to me, for both cases.

I'd like to better understand the issues that you're seeing but from
what I currently understand the behavior of QGIS Server is correct. 
Happy to be proven otherwise :)

Cheers,


-- 
Éric Lemoine
Oslandia


pgpYckP65NICZ.pgp
Description: OpenPGP digital signature
___
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 deployment

[Eric Lemoine]

> Hi all,
> 
> I'm not a sysadmin but for our customers I'd like find the better way
> for deploy QGIS-server 3.
> 
> I try at least 3 ways:
> 
> 1) Apache2 + libapache2-mod-fcgid


There is Apache2 + mod_proxy_fcgi that you could use as well. As
opposed to mod_fcgid, mod_proxy_fcgi requires that you use your own
method for starting the FastCGI process(es) (QGIS Server here). In this
regard mod_proxy_fcgi is very similar to NGINX-based setups.


> 2) Nginx + fcgiwrap

I recently added a note to the QGIS Server docs [0] that recommends
against fcgiwrap. fcgiwrap is very slow, because it creates a new QGIS
Server process on each request!

[0]


> 
> 3) Nginx + QGIS-Server working by socket/service (systemd)


I like this one a lot, because it doesn't require anything else than
systemd, which has become very very common on Linux distros. I even
wrote a blog post about it :-) See [1].

[1]



> 
> By delveloper side, what do you think is the best?


As already said I like the systemd-only method because it doesn't
require more than systemd, which you probably already have and use on
your Linux system.

spawn-fcgi works great as well, but you will need to use something like
supervisord, or write a systemd system unit for it.


> 
> I'd like to much 3) solution, but I found some problems, in
> particular, how many sockects I've to create watching at my server?
> (Number of processors )


I'd recommend using one QGIS Server process per processor, or even a
few more for more parallelism during I/O operations. For example with 4
processors I think you can use 6-8 QGIS Server processes.


> For 1) and 2) have you experiences on performance and tuning?

Don't use 2 :-) I don't have much experience with 1 so I won't comment.
But Patrick's suggestions sound very good to me :)

One final note: at Oslandia we either use NGINX + systemd, or NGINX +
spawn-fcgi when running QGIS Server in Docker container. If you want
to use Docker I'd recommend taking a look at [2], which explains how we
build and run QGIS Server using Docker.

[2] 

Good luck!

-- 
Éric Lemoine
Oslandia
+33 1 86 95 95 55


pgpLGpuheJdzp.pgp
Description: OpenPGP digital signature
___
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