[Qgis-developer] adding python interpreter to QGis mapserver to expose analysis routines

G. Allegri giohappy at gmail.com
Wed Oct 19 18:17:59 EDT 2011


That would ne a very interesting architecture Martin.
Each Service would manage its on requirements, for example its own internal
bindings to Python or whatever.
I'm not sure about the "fastgi nature" of the services. The server has a an
fcgi interface, ok, but the services should be indipendent from this
specific interface. The Server could be deployed in a different fashion, but
the services should ignore this.

giovanni

2011/10/19 Martin Dobias <wonder.sk at gmail.com>

> Hi Giovanni and Radim
>
> On Wed, Oct 19, 2011 at 12:24 PM, G. Allegri <giohappy at gmail.com> wrote:
> > I was thinking to both the ways:
> >  - expose geoprocessing directly through QGIS MS (either C++ plugins or
> > Python plugins)
> >  - provide a Python mapscripting for QGIS MS (as you're saying)
> > I think the two ways are complementary.
> > The latter would let you "control" QGIS MS, and proxy requests, exactly
> the
> > same as Mapserver/Mapscript.
> > The first one would let you also expose code written for QGis Desktop.
> For
> > example, you could expose the features provided by the Processing
> Framework
> > (OTB, SAGA, etc.), or the code inside QGis Analysis.
>
> A nice low-level solution would be to introduce a new class to
> qgis_core library that would take care of fastcgi functionality (e.g.
> QgsFastCgiServer) and an abstract interface for web-based services
> (e.g. QgsFastCgiService) for communication between the fastcgi server
> and the concrete service. One or more services could be registered to
> the fastcgi server and it would redirect the request to the services.
> Our WMS server would be therefore become a service running on top of
> QgsFastCgiServer, the mapserver executable would just create fastcgi
> server instance, add WMS service and start the server.
>
> With QgsFastCgiServer developers could implement basically any
> functionality they want. A simple WPS service could be built on top of
> the processing framework. Or a service that first does some
> processing, then renders the map and returns it (this would be the
> MapScript equivalent, right?)
>
> To use python we would need python wrapper of the server and service
> classes, something that could be done very easily.
>
> The WMS service could be probably made extensible, too, but the number
> of possible use cases would be probably smaller in order to stay
> compatible with WMS standard.
>
> Regards
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20111020/388a98f5/attachment.html


More information about the Qgis-developer mailing list