Re: [QGIS-Developer] QGIS Server and the Grants programme

[Jose Mercedes Venegas Acevedo]

Good day I think that being able to publish a project directly through QGIS
Server just by mounting the QGis project done on the desktop is just
fantastic if those tiny great details of QGIS Server were fixed would
definitely take off tremendously

Maybe integrating the lizmap plugin into the QGis core and giving the user
the possibility to choose their project to publish in an interface similar
to lizmap or perhaps with the qgis web client 2 project would make users
start looking seriously at QGIS Server and surely many would run to migrate
immediately because it would simplify many things in addition to giving a
lot of power to both qgis desktop and qgis server.

It is just an opinion that could be valued I only speak Spanish so I copied
the original text below in case something was not translated correctly with
google translate

Buen dia yo creo que el hecho de poder publicar un proyecto directamente a
traves de QGIS Server con solo montar el proyecto QGis hecho en el desktop
es simplemente fantastico si se arreglaran esos minusculos grandes detalles
de QGIS Server definitivamente despegaria tremendamente

Quiza integrar el plugin de lizmap al core de QGis y darle al usuario la
posibilidad de elegir su proyecto a publicar en una interfaz similar a
lizmap o quiza con el proyecto qgis web client 2 haria que los usuarios
empezaran a mirar muy seriamenet a QGIS Server y seguramente muchos
correrian a migrar de inmediato porque se simplificaria muchas cosas ademas
de darle muchisima potencia tanto a qgis desktop como qgis server.



El mar., 9 jun. 2020 a las 14:38, Andreas Neumann ()
escribió:

> Hi Henrik,
>
> Good idea. Now that Windows server has a Linux subsystem and docker, the
> easiest thing would be to use docker, I think. That way you would have
> the exact same setup like on Linux. No more strange Windows problems.
>
> It might be one path to use to tackle the windows installation problem,
> but it wouldn't be the only one.
>
> Alessandro: will you suggest dates for a meeting - perhaps by starting
> with a Doodle to see when most interested people would be available?
>
> Andreas
>
> Am 09.06.20 um 20:56 schrieb Henrik Larsson:
> > Hi,
> > I believe that a better deployment process for Server on Windows might
> > be one way for little a bigger market share. I think that there are
> > more people than me that uses Desktop today next to the Esri platform
> > that would gladly start to switch over to Server as a wms provider if
> > posible.
> >
> > A dedicated online meeting is a really nice idea (where do I attend?) .
> >
> > Regards Henrik
> >
> > Den 2020-06-09 kl. 09:24, skrev Alessandro Pasotti:
> >> Thank you Jonathan for raising the discussion, I think this should be
> >> a good opportunity to focus on how we can gain a bigger "market share"
> >> and restart investing on the server with both time and funds.
> >>
> >> Full disclaimer: I'm a QGIS server developer.
> >>
> >> It would be probably useful to start a discussion about how we can
> >> make QGIS Server better and what makes it lag behind "competitors",
> >> both FOSS and proprietary.
> >>
> >> - Is it missing features?
> >> - performances/scalability?
> >> - standard compliance?
> >> - missing protocols (WPS...)?
> >> - documentation/examples?
> >> - ease of deployment/maintenance?
> >> - security auditing?
> >> - plain marketing?
> >>
> >> I've personally found exceptionally productive the QGIS Server Meeting
> >> we had in Lion a few years back (that ultimately led to a deep
> >> refactoring of the server), I think we should organize a dedicated
> >> (online) meeting with the interested parties to start a discussion and
> >> share ideas.
> >>
> >> Regards
> >>
> >>
> >> On Tue, Jun 9, 2020 at 9:09 AM Andreas Neumann 
> >> wrote:
> >>> Hi Jonathan,
> >>>
> >>> You keep repeating yourself. You started the exact same discussion a
> >>> year ago.
> >>>
> >>> You have a valid point, of course, I don't argue that. But if you
> >>> think about small organizations  that do not have a lot of personal
> >>> (or financial) resources, it would be a lot of burden to invest
> >>> twice the time in styling: once for QGIS desktop and another time
> >>> again for UMN mapserver and Geoserver. Even if SLD output from QGIS
> >>> improved (also thanks to efforts of Andrea Aime and others), it
> >>> still can't transport everything. If it would, then I would better
> >>> agree with your argument.
> >>>
> >>> For such smaller organization, speed (and I know that UMN and
> >>> Geoserver are a bit faster than QGIS server) is not the only
> >>> important thing - it is also their personal and financial resources
> >>> and complexity of their software landscape.
> >>>
> >>> And QGIS server has some other unique selling points: the
> >>> proprietary GetPrint command that doesn't have a match in Geoserver
> >>> or UMN, the ability to create Atlases from server, and who knows, in
> >>> the future perhaps QGIS server can run processing models.
> >>>
> >>> Greetings,

[QGIS-Developer] Plugin [629] Networks approval notification.

[noreply]

Plugin Networks approval by zimbogisgeek.
The plugin version "[629] Networks 2.4.4" is now approved
Link: http://plugins.qgis.org/plugins/networks/
___
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 [2086] Open reblock approval notification.

[noreply]

Plugin Open reblock approval by zimbogisgeek.
The plugin version "[2086] Open reblock 0.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/open_reblock/
___
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 [1943] OneAtlas approval notification.

[noreply]

Plugin OneAtlas approval by zimbogisgeek.
The plugin version "[1943] OneAtlas 1.1.2" is now approved
Link: http://plugins.qgis.org/plugins/oneatlas-qgis-plugin-1_0_1/
___
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 [1815] OpenEO approval notification.

[noreply]

Plugin OpenEO approval by zimbogisgeek.
The plugin version "[1815] OpenEO 0.9 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/openeo-qgis-plugin-master/
___
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 [1364] UMEP approval notification.

[noreply]

Plugin UMEP approval by zimbogisgeek.
The plugin version "[1364] UMEP 3.14" is now approved
Link: http://plugins.qgis.org/plugins/UMEP/
___
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 and the Grants programme

[Andreas Neumann]

Hi Henrik,

Good idea. Now that Windows server has a Linux subsystem and docker, the 
easiest thing would be to use docker, I think. That way you would have 
the exact same setup like on Linux. No more strange Windows problems.


It might be one path to use to tackle the windows installation problem, 
but it wouldn't be the only one.


Alessandro: will you suggest dates for a meeting - perhaps by starting 
with a Doodle to see when most interested people would be available?


Andreas

Am 09.06.20 um 20:56 schrieb Henrik Larsson:

Hi,
I believe that a better deployment process for Server on Windows might 
be one way for little a bigger market share. I think that there are 
more people than me that uses Desktop today next to the Esri platform 
that would gladly start to switch over to Server as a wms provider if 
posible.


A dedicated online meeting is a really nice idea (where do I attend?) .

Regards Henrik

Den 2020-06-09 kl. 09:24, skrev Alessandro Pasotti:

Thank you Jonathan for raising the discussion, I think this should be
a good opportunity to focus on how we can gain a bigger "market share"
and restart investing on the server with both time and funds.

Full disclaimer: I'm a QGIS server developer.

It would be probably useful to start a discussion about how we can
make QGIS Server better and what makes it lag behind "competitors",
both FOSS and proprietary.

- Is it missing features?
- performances/scalability?
- standard compliance?
- missing protocols (WPS...)?
- documentation/examples?
- ease of deployment/maintenance?
- security auditing?
- plain marketing?

I've personally found exceptionally productive the QGIS Server Meeting
we had in Lion a few years back (that ultimately led to a deep
refactoring of the server), I think we should organize a dedicated
(online) meeting with the interested parties to start a discussion and
share ideas.

Regards


On Tue, Jun 9, 2020 at 9:09 AM Andreas Neumann  
wrote:

Hi Jonathan,

You keep repeating yourself. You started the exact same discussion a 
year ago.


You have a valid point, of course, I don't argue that. But if you 
think about small organizations  that do not have a lot of personal 
(or financial) resources, it would be a lot of burden to invest 
twice the time in styling: once for QGIS desktop and another time 
again for UMN mapserver and Geoserver. Even if SLD output from QGIS 
improved (also thanks to efforts of Andrea Aime and others), it 
still can't transport everything. If it would, then I would better 
agree with your argument.


For such smaller organization, speed (and I know that UMN and 
Geoserver are a bit faster than QGIS server) is not the only 
important thing - it is also their personal and financial resources 
and complexity of their software landscape.


And QGIS server has some other unique selling points: the 
proprietary GetPrint command that doesn't have a match in Geoserver 
or UMN, the ability to create Atlases from server, and who knows, in 
the future perhaps QGIS server can run processing models.


Greetings,

Andreas

On 2020-06-08 22:42, Jonathan Moules wrote:

Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list 
about which mapping servers are the most deployed. For those who 
haven't seen it, QGIS Server has about 60 public deployments (1% of 
all of them), and it serves 11,924 datasets (0.5% of all public 
geospatial WMS/WFS/WCS/WMTS datasets).


Potentially controversial here and I appreciate it's not a 
competition, but given the low uptake of QGIS Server compared to 
other Open Source offerings (GeoServer: 964 deployments, 963,603 
datasets; MapServer: 544 deployments, 389,709 datasets), is QGIS 
Server something the grant program should be funding? There are 
three Server proposals totalling €10,000, 22% of the fund.


Now, before you get the pitchforks out(!), please consider the 
following:


* Zero sum game - Any money spent on QGIS Server cannot be spent on 
QGIS Desktop. (The grants mostly aren't things that will improve the 
shared QGIS Core). (This reasoning also follows through to OSGeo 
funds).


* Multiple solutions - Open Source (and OSGeo) already has a very 
healthy ecosystem of mapping servers - does it need another one?


* Limited number of users benefited - I don't have stats for it, but 
QGIS Desktop is probably the most popular Open Source Desktop GIS, 
and is certainly going to have many orders of magnitude more users 
than QGIS Server.


* Playing to your strengths - QGIS' strength is it's Desktop and 
it's generally good practice to play to your strengths.



So given the above, and that QGIS is already "winning" as an Open 
Source Desktop (great job!), I'd like to suggest it's not a good 
idea to dilute the limited resources by spending them on QGIS 
Server. Instead it seems that far more people would benefit if that 
money was spent on Desktop, especially the bug fixing programme.


Or alternatively, given the "Unique Selling Point" of QGIS Server is 
its 

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Henrik Larsson]

Hi,
I believe that a better deployment process for Server on Windows might 
be one way for little a bigger market share. I think that there are more 
people than me that uses Desktop today next to the Esri platform that 
would gladly start to switch over to Server as a wms provider if posible.


A dedicated online meeting is a really nice idea (where do I attend?) .

Regards Henrik

Den 2020-06-09 kl. 09:24, skrev Alessandro Pasotti:

Thank you Jonathan for raising the discussion, I think this should be
a good opportunity to focus on how we can gain a bigger "market share"
and restart investing on the server with both time and funds.

Full disclaimer: I'm a QGIS server developer.

It would be probably useful to start a discussion about how we can
make QGIS Server better and what makes it lag behind "competitors",
both FOSS and proprietary.

- Is it missing features?
- performances/scalability?
- standard compliance?
- missing protocols (WPS...)?
- documentation/examples?
- ease of deployment/maintenance?
- security auditing?
- plain marketing?

I've personally found exceptionally productive the QGIS Server Meeting
we had in Lion a few years back (that ultimately led to a deep
refactoring of the server), I think we should organize a dedicated
(online) meeting with the interested parties to start a discussion and
share ideas.

Regards


On Tue, Jun 9, 2020 at 9:09 AM Andreas Neumann  wrote:

Hi Jonathan,

You keep repeating yourself. You started the exact same discussion a year ago.

You have a valid point, of course, I don't argue that. But if you think about 
small organizations  that do not have a lot of personal (or financial) 
resources, it would be a lot of burden to invest twice the time in styling: 
once for QGIS desktop and another time again for UMN mapserver and Geoserver. 
Even if SLD output from QGIS improved (also thanks to efforts of Andrea Aime 
and others), it still can't transport everything. If it would, then I would 
better agree with your argument.

For such smaller organization, speed (and I know that UMN and Geoserver are a 
bit faster than QGIS server) is not the only important thing - it is also their 
personal and financial resources and complexity of their software landscape.

And QGIS server has some other unique selling points: the proprietary GetPrint 
command that doesn't have a match in Geoserver or UMN, the ability to create 
Atlases from server, and who knows, in the future perhaps QGIS server can run 
processing models.

Greetings,

Andreas

On 2020-06-08 22:42, Jonathan Moules wrote:

Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list about which 
mapping servers are the most deployed. For those who haven't seen it, QGIS 
Server has about 60 public deployments (1% of all of them), and it serves 
11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).

Potentially controversial here and I appreciate it's not a competition, but 
given the low uptake of QGIS Server compared to other Open Source offerings 
(GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
389,709 datasets), is QGIS Server something the grant program should be 
funding? There are three Server proposals totalling €10,000, 22% of the fund.

Now, before you get the pitchforks out(!), please consider the following:

* Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
Desktop. (The grants mostly aren't things that will improve the shared QGIS 
Core). (This reasoning also follows through to OSGeo funds).

* Multiple solutions - Open Source (and OSGeo) already has a very healthy 
ecosystem of mapping servers - does it need another one?

* Limited number of users benefited - I don't have stats for it, but QGIS 
Desktop is probably the most popular Open Source Desktop GIS, and is certainly 
going to have many orders of magnitude more users than QGIS Server.

* Playing to your strengths - QGIS' strength is it's Desktop and it's generally 
good practice to play to your strengths.


So given the above, and that QGIS is already "winning" as an Open Source 
Desktop (great job!), I'd like to suggest it's not a good idea to dilute the limited 
resources by spending them on QGIS Server. Instead it seems that far more people would 
benefit if that money was spent on Desktop, especially the bug fixing programme.

Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
integration with QGIS Desktop, those resources could be used to further improve 
interoperability with GeoServer/MapServer/deegree/etc. Those are all successful mature 
OSGeo projects that excel at serving maps, have an architecture designed for it, and 
already have huge install bases.

TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should play to 
its strengths and focus its limited funds there to benefit the most users.

I shall now retreat to my bunker. :-)

Cheers,
Jonathan

Note: The above only applies to the Grant program and 

Re: [QGIS-Developer] webp for qgis server ?

[Even Rouault]

Matthias,

thanks for the analysis. There are however a few unexpected results.

1) I'd expect gpkg pyramid_JPEG and COG_JPEG to have very similar sizes, even 
COG_JPEG 
being potentially slightly smaller.
And I'd also expect COG_JPEG to be slighly faster (but with less confidence 
that my 
statement about size)

Has by chance the source raster an alpha band ? In which case gpkg_pyramid_JPEG 
would 
have dropped it, whereas COG_JPEG will encode it as DEFLATE compressed mask, 
but still 
the difference is surprising

Another explanation might be the block size. GPKG defaults to 256x256 tiles, 
whereas 
COG_JPEG to 512x512. Perhaps that affect compression efficiency. And 
performance? 
(depends if your bench maintains the GDAL raster opened between requests or not)

If you didn't specify quality settings, both COG_JPEG and GPKG JPEG should use 
the same 
quality of 75%

2) For the same compression type, block sizes and number of overviews, MBTiles 
(the report 
doesn't specify the compression scheme for it) and GeoPacakge should also have 
similar sizes 
and performance. They are really close brothers, with just a few systems tables 
different.

Even

> Hi all,
> 
> At OPENGIS.ch we have recently looked into different raster formats. The
> results can be read here:
> https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-fo
> r-qfield/
> 
> Not that surprising, but one of the interesting findings was that webp
> is very efficient. Low filesize, reasonable rendering performance,
> support for transparency. In short, it has all the potential for being
> used as default transport format for WM(T)S.
> 
> Looking at our server implementation, this format is not supported. Did
> someone ever think about or even look into that?
> 
> Regards


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
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 update no approved

[Fredrik Lindberg]

Hi,

I submitted an update of a plugin last friday ([1364] UMEP) but it is still not 
approved. I dont see any other messages from you. What has happened?


best regards,

Fredrik
___
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] webp for qgis server ?

[Matthias Kuhn]

Thanks for the excellent questions Even

Lucie has done the analysis and has all the parameters. She is not in 
the office these days. Once she is back I hope she can share the 
parameters and potentially also add a couple of additional rows to the 
table with improved parameters.


Sorry that I can't help more right now.

Matthias

On 6/9/20 1:56 PM, Even Rouault wrote:


Matthias,

thanks for the analysis. There are however a few unexpected results.

1) I'd expect gpkg pyramid_JPEG and COG_JPEG to have very similar 
sizes, even COG_JPEG being potentially slightly smaller.


And I'd also expect COG_JPEG to be slighly faster (but with less 
confidence that my statement about size)


Has by chance the source raster an alpha band ? In which case 
gpkg_pyramid_JPEG would have dropped it, whereas COG_JPEG will encode 
it as DEFLATE compressed mask, but still the difference is surprising


Another explanation might be the block size. GPKG defaults to 256x256 
tiles, whereas COG_JPEG to 512x512. Perhaps that affect compression 
efficiency. And performance? (depends if your bench maintains the GDAL 
raster opened between requests or not)


If you didn't specify quality settings, both COG_JPEG and GPKG JPEG 
should use the same quality of 75%


2) For the same compression type, block sizes and number of overviews, 
MBTiles (the report doesn't specify the compression scheme for it) and 
GeoPacakge should also have similar sizes and performance. They are 
really close brothers, with just a few systems tables different.


Even

> Hi all,

>

> At OPENGIS.ch we have recently looked into different raster formats. The

> results can be read here:

> 
https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-fo


> r-qfield/

>

> Not that surprising, but one of the interesting findings was that webp

> is very efficient. Low filesize, reasonable rendering performance,

> support for transparency. In short, it has all the potential for being

> used as default transport format for WM(T)S.

>

> Looking at our server implementation, this format is not supported. Did

> someone ever think about or even look into that?

>

> Regards

--

Spatialys - Geospatial professional services

http://www.spatialys.com

___
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] webp for qgis server ?

[Matthias Kuhn]

Hi Andreas,

On 6/9/20 1:47 PM, Andreas Neumann wrote:


Hi Marco,

I agree. WebP would be interesting. It could potentially replace both 
png and jpeg - if encoding and decoding is fast and if filesize can 
compete. The good thing of WebP compared with JPEG is that it supports 
transparency.



Exactly  !


According to your brief study, it seems to score well regarding file 
size, but not so well performance wise - correct?


Encoding and decoding performance seems to be a bit worse. But this 
could be compensated by the smaller size and faster transfer.


The performance that you measure - is this about time to create the 
files - right?



The times are rendering times (decoding).


What about opening and rendering on the client? That's the other side 
of the medal.


Does qt support WebP?


Yes


Regarding your blog post: can you perhaps better explain what PNG_JPEG 
means? A PNG as a container with JPEG compression inside? Or what is it?


Have a look at the GDAL driver page 
https://gdal.org/drivers/raster/gpkg.html


[ ... ] PNG tiles will be used to store tiles that are not completely 
opaque [ ... ]


Regarding tif: could you share your creation parameters? In my 
experience tiff performs much better than what you experience (both in 
file size and speed) if you use proper compression and creation 
parameters. E.g. you can use JPEG compression inside tiff and then you 
should have more or less the same file size as with jpeg. tiff is just 
the container, but there are thousand of combinations of creation 
options that have a very, very significant impact on perfomance and 
file size.


Can you ask this question directly as a comment on the blog post? Lucie 
who is not in the office created the post and has all the parameters.


Bests

Matthias


Thanks,

Andreas

On 2020-06-09 13:26, Matthias Kuhn wrote:


Hi all,

At OPENGIS.ch we have recently looked into different raster formats. 
The results can be read here: 
https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-for-qfield/


Not that surprising, but one of the interesting findings was that 
webp is very efficient. Low filesize, reasonable rendering 
performance, support for transparency. In short, it has all the 
potential for being used as default transport format for WM(T)S.


Looking at our server implementation, this format is not supported. 
Did someone ever think about or even look into that?


Regards

--
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 

___
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] GeoSeer ogc services data harvesting

[Andreas Neumann]

On 2020-06-09 13:46, Jonathan Moules wrote:

Hi Andreas, 

Interesting. 


Behind the scenes, GeoSeer one-way hashes the GetCapabilities documents and 
that hash is used as the document key. Identical GetCapabilities documents 
therefore get the same key and thus only appear once in the final index. But 
one single character different in the entire document and it's a completely 
different hash.


Yes - they are not 100% identical. E.g. the "OnlineResource" would be
different, but all the rest would be identical. I know exceptions here
and there ... difficult topic. 





Andreas___
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] webp for qgis server ?

[Andreas Neumann]

Hi Marco, 


I agree. WebP would be interesting. It could potentially replace both
png and jpeg - if encoding and decoding is fast and if filesize can
compete. The good thing of WebP compared with JPEG is that it supports
transparency. According to your brief study, it seems to score well
regarding file size, but not so well performance wise - correct? The
performance that you measure - is this about time to create the files -
right? What about opening and rendering on the client? That's the other
side of the medal. 

Does qt support WebP? 


Regarding your blog post: can you perhaps better explain what PNG_JPEG
means? A PNG as a container with JPEG compression inside? Or what is it?


Regarding tif: could you share your creation parameters? In my
experience tiff performs much better than what you experience (both in
file size and speed) if you use proper compression and creation
parameters. E.g. you can use JPEG compression inside tiff and then you
should have more or less the same file size as with jpeg. tiff is just
the container, but there are thousand of combinations of creation
options that have a very, very significant impact on perfomance and file
size. 

Thanks, 

Andreas 


On 2020-06-09 13:26, Matthias Kuhn wrote:

Hi all, 

At OPENGIS.ch we have recently looked into different raster formats. The results can be read here: https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-for-qfield/ 

Not that surprising, but one of the interesting findings was that webp is very efficient. Low filesize, reasonable rendering performance, support for transparency. In short, it has all the potential for being used as default transport format for WM(T)S. 

Looking at our server implementation, this format is not supported. Did someone ever think about or even look into that? 


Regards

--

Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 [1]
[2] 
___

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




Links:
--
[1] tel:+41764356763
[2] http://www.opengis.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] GeoSeer ogc services data harvesting

[Jonathan Moules]

Hi Andreas,

Interesting.

Behind the scenes, GeoSeer one-way hashes the GetCapabilities documents 
and that hash is used as the document key. Identical GetCapabilities 
documents therefore get the same key and thus only appear once in the 
final index. But one single character different in the entire document 
and it's a completely different hash.


There's also de-duplication at the endpoint, service, and dataset levels 
using a similar mechanism. GeoSeer also de-duplicates across services. 
I.e. if something is served from the same place as both WMS and WFS, we 
glue them together.


The problem with using DNS is that you get organisations the size of 
NOAA/USGS and they have deployments across various subdomains that are 
doing different (but similar) things. You also get a kind of opposite - 
a single domain belonging to a geospatial "cloud" hosting provider that 
has lots of layers that have the same names and similar metadata because 
all their local-government customers are sharing their own 
fire-stations/roads etc.


There are all manner of ways in which server admins and data custodians 
make this more complicated than it seems. :-)


Cheers,

Jonathan


On 2020-06-09 12:25, Andreas Neumann wrote:


Hi Jonathan,

Thanks for sharing this information. I don't know anything better.

While looking at some services that I know personally, I also found 
out that others services are listed twice, because a machine might 
have a DNS alias. That is also something to consider - perhaps sort 
out machines that have identical GetCapabilities responses and just 
the DNS name varies.


I agree, the numbers probably wouldn't change significantly.

Thanks and greetings,

Andreas

On 2020-06-09 13:14, Jonathan Moules wrote:


Hi Andreas,
Sure, happy to share.
There's a little on the About page: https://www.geoseer.net/about.php 
and then scattered around blog posts (the ones with the "GeoSeer" tag 
are probably best for that: https://www.geoseer.net/blog/?t=GeoSeer 
), but put simply - We scrape a lot of different sources and metadata 
catalogs and get the services from them. Then we request not only the 
GetCapabilities that was declared, but also make educated guesses as 
to what else might be on the box and request those too.


It's not perfect, but to the best of my knowledge it's by far the 
largest such index in the world, and more importantly, it's 
*current*. Everything in there responded with a valid GetCapabilities 
document with at least one meaningful named dataset when it was last 
scraped within the last few weeks.


Pertaining to your given services, GeoSeer has:
http://geoweb.so.ch/wms/sogis_natgef.wms? and a few others on that 
sub-domain, as well as some on the subdomain: 
http://www.sogis1.so.ch/cgi-bin/sogis/sogis_natgef.wms? - both are 
now defunct I see which is why they're not in the database.


Thanks for the URL, I've added it for scraping.

So I wonder how many other QGIS server installations may not be in 
your database?
Alas that's a "unknown unknown"; there's no way to know (I can't 
think of a way to find out anyway; suggestions welcome). However the 
vast majority of the time when I come across a new service manually 
(i.e. from following various mailing lists like this), it turns out 
it's already in the index, so I think it's reasonably comprehensive 
at this point.


While missing servers may change the absolute number of QGIS 
Installations, they're very unlikely to change the proportions. For a 
sample-size this large I'd expect the proportions to remain largely 
the same, certainly for deployments.


Hope that's of interest and answers the question,
Cheers,
Jonathan


On 2020-06-09 10:45, Andreas Neumann wrote:


Hi Jonathan,

Can you share with us how you harvest your information on available 
public OGC services? You probably have that information published 
somewhere - so if you could point me towards this URL, it would help.


I noticed that all of the services of our province (my employer) 
can't be found, as an example.


Here is the start point:

https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/geoportal/geodienste/wms-web-map-service/

and the GetCapabilities link:

https://geo.so.ch/api/wms?SERVICE=WMS=GetCapabilities=1.3.0

So I wonder how many other QGIS server installations may not be in 
your database? Of course I know you don't claim full coverage, but 
it would still be good to know how you harvest your data.


Thanks for clarifying and greetings,

Andreas

___
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] webp for qgis server ?

[Matthias Kuhn]

Hi all,

At OPENGIS.ch we have recently looked into different raster formats. The 
results can be read here: 
https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-for-qfield/


Not that surprising, but one of the interesting findings was that webp 
is very efficient. Low filesize, reasonable rendering performance, 
support for transparency. In short, it has all the potential for being 
used as default transport format for WM(T)S.


Looking at our server implementation, this format is not supported. Did 
someone ever think about or even look into that?


Regards

--
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 
___
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] GeoSeer ogc services data harvesting

[Andreas Neumann]

Hi Jonathan, 

Thanks for sharing this information. I don't know anything better. 


While looking at some services that I know personally, I also found out
that others services are listed twice, because a machine might have a
DNS alias. That is also something to consider - perhaps sort out
machines that have identical GetCapabilities responses and just the DNS
name varies. 

I agree, the numbers probably wouldn't change significantly. 

Thanks and greetings, 

Andreas 


On 2020-06-09 13:14, Jonathan Moules wrote:


Hi Andreas,
Sure, happy to share.
There's a little on the About page: https://www.geoseer.net/about.php and then scattered 
around blog posts (the ones with the "GeoSeer" tag are probably best for that: 
https://www.geoseer.net/blog/?t=GeoSeer ), but put simply - We scrape a lot of different 
sources and metadata catalogs and get the services from them. Then we request not only 
the GetCapabilities that was declared, but also make educated guesses as to what else 
might be on the box and request those too.

It's not perfect, but to the best of my knowledge it's by far the largest such 
index in the world, and more importantly, it's *current*. Everything in there 
responded with a valid GetCapabilities document with at least one meaningful 
named dataset when it was last scraped within the last few weeks.

Pertaining to your given services, GeoSeer has:
http://geoweb.so.ch/wms/sogis_natgef.wms? and a few others on that sub-domain, 
as well as some on the subdomain: 
http://www.sogis1.so.ch/cgi-bin/sogis/sogis_natgef.wms? - both are now defunct 
I see which is why they're not in the database.

Thanks for the URL, I've added it for scraping.


So I wonder how many other QGIS server installations may not be in your 
database?

Alas that's a "unknown unknown"; there's no way to know (I can't think of a way 
to find out anyway; suggestions welcome). However the vast majority of the time when I 
come across a new service manually (i.e. from following various mailing lists like this), 
it turns out it's already in the index, so I think it's reasonably comprehensive at this 
point.

While missing servers may change the absolute number of QGIS Installations, 
they're very unlikely to change the proportions. For a sample-size this large 
I'd expect the proportions to remain largely the same, certainly for 
deployments.

Hope that's of interest and answers the question,
Cheers,
Jonathan

On 2020-06-09 10:45, Andreas Neumann wrote: 


Hi Jonathan,

Can you share with us how you harvest your information on available public OGC 
services? You probably have that information published somewhere - so if you 
could point me towards this URL, it would help.

I noticed that all of the services of our province (my employer) can't be 
found, as an example.

Here is the start point:

https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/geoportal/geodienste/wms-web-map-service/

and the GetCapabilities link:

https://geo.so.ch/api/wms?SERVICE=WMS=GetCapabilities=1.3.0

So I wonder how many other QGIS server installations may not be in your 
database? Of course I know you don't claim full coverage, but it would still be 
good to know how you harvest your data.

Thanks for clarifying and greetings,

Andreas___
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] GeoSeer ogc services data harvesting

[Jonathan Moules]

Hi Andreas,
Sure, happy to share.
There's a little on the About page: https://www.geoseer.net/about.php 
and then scattered around blog posts (the ones with the "GeoSeer" tag 
are probably best for that: https://www.geoseer.net/blog/?t=GeoSeer ), 
but put simply - We scrape a lot of different sources and metadata 
catalogs and get the services from them. Then we request not only the 
GetCapabilities that was declared, but also make educated guesses as to 
what else might be on the box and request those too.


It's not perfect, but to the best of my knowledge it's by far the 
largest such index in the world, and more importantly, it's *current*. 
Everything in there responded with a valid GetCapabilities document with 
at least one meaningful named dataset when it was last scraped within 
the last few weeks.


Pertaining to your given services, GeoSeer has:
http://geoweb.so.ch/wms/sogis_natgef.wms? and a few others on that 
sub-domain, as well as some on the subdomain: 
http://www.sogis1.so.ch/cgi-bin/sogis/sogis_natgef.wms? - both are now 
defunct I see which is why they're not in the database.


Thanks for the URL, I've added it for scraping.

> So I wonder how many other QGIS server installations may not be in 
your database?
Alas that's a "unknown unknown"; there's no way to know (I can't think 
of a way to find out anyway; suggestions welcome). However the vast 
majority of the time when I come across a new service manually (i.e. 
from following various mailing lists like this), it turns out it's 
already in the index, so I think it's reasonably comprehensive at this 
point.


While missing servers may change the absolute number of QGIS 
Installations, they're very unlikely to change the proportions. For a 
sample-size this large I'd expect the proportions to remain largely the 
same, certainly for deployments.


Hope that's of interest and answers the question,
Cheers,
Jonathan


On 2020-06-09 10:45, Andreas Neumann wrote:


Hi Jonathan,

Can you share with us how you harvest your information on available 
public OGC services? You probably have that information published 
somewhere - so if you could point me towards this URL, it would help.


I noticed that all of the services of our province (my employer) can't 
be found, as an example.


Here is the start point:

https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/geoportal/geodienste/wms-web-map-service/

and the GetCapabilities link:

https://geo.so.ch/api/wms?SERVICE=WMS=GetCapabilities=1.3.0

So I wonder how many other QGIS server installations may not be in 
your database? Of course I know you don't claim full coverage, but it 
would still be good to know how you harvest your data.


Thanks for clarifying and greetings,

Andreas


___
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 and the Grants programme

[Nyall Dawson]

On Tue, 9 Jun 2020 at 20:07, Andreas Neumann  wrote:
>
> Hi Nyall,
>
> Thanks for clarifying - I am relieved by your further statements ;-)
>
> I don't know a good replacement of ArcGIS Server portal (or whatever that 
> product is called currently). I agree that it would be great if there would 
> be a good replacement for that - and that would need further funding - and 
> perhaps a good collaboration between more than one of the OSGEO/QGIS 
> developer companies. I fear that any of the available OSGeo/QGIS companies on 
> it's own is too small to cover that fully. It probably needs something larger 
> on top of it, with the smaller already existing companies bringing in their 
> individual expertise to that larger entity. QGIS cloud from Sourepole was a 
> good start some years ago, but it would have to grow faster than it currently 
> does, and that would require a larger entity than Sourcepole (or most other 
> similar companies) are. And of course also more paying customers.

Just to clarify further -- I'm mostly talking about a
private/on-premises offering, rather than a SAAS type offering. Of
course, if someone wanted to take the components and offer as a paid
cloud service (as Sourcepole does/did), then that's great! But it
shouldn't be the initial goal...

nyall

>
> The building blocks are mostly there, yes.
>
> Andreas
>
>
> On 2020-06-09 11:45, Nyall Dawson wrote:
>
> On Tue, 9 Jun 2020 at 09:18, Nyall Dawson  wrote:
>
>
> On Tue, 9 Jun 2020 at 09:12, Tim Sutton  wrote:
>
>
> Hi
>
>
> Nice, thoughtful message below, thanks Jonathon. I wonder what it will take 
> to move the needle above 1%? And whether we should try to use our funds to 
> make that happen. QGIS is surely the most expressive way to do cartography of 
> any GIS out there (acknowledging total bias on my part) and seeing that 
> cartography on the web would surely please many people. Clients like QWC, 
> QWC2 or anything that requires you to hand edit a config file or log into a 
> unix shell to publish map services are probably the main limitation (no 
> offence to those tools). Also the lack of an built in tiling server (with 
> proper metalling and meta buffering) must surely be the other.  Maybe a more 
> useful approach to your discussion below would be to promote funding the 
> elements that add resistance to deploying QGIS server……but then we would be 
> in new feature space and circling back to the idea of not funding QGIS Server 
> with grants…..
>
>
> Something else to consider is whether technologies like WMS are
> ultimately just "dead end" technologies now, and possibly we'd be
> better off focusing on client side rendering of vector features from a
> server (QGIS or other), and providing a library which can do
> client-side rendering of vector tiles from QGIS symbology in as close
> to 1:1 as possible...
>
>
> Re-reading my message, I think it comes across unintentionally
> critical. I was actually just "pondering aloud"!
>
> I definitely agree that there's a strong use case for a server
> component which "just works" with QGIS, and I would hate to see this
> efforts abandoned. Indeed, my personal opinion is that what osgeo is
> really lacking is a unified solution to desktop/web/mobile. We have
> all the raw building blocks, but there's just no direct equivalent of
> ArcGIS portal where end users can easily publish datasets and maps.
> Boundless was filling this gap with their offerings, but that's a
> thing of the past now, and no-one has really stepped up to fill this
> need. Possibly geonode + QGIS server backend is the closest we get,
> but that's still needing significant investment before it's a really
> compelling competitor.
>
> I'd really love to hear what solutions others deploy when they're
> asked by a client to replace an ArcGIS desktop + Portal environment.
> Perhaps there's actually a need for **more** investment in QGIS server
> to fund development of a Portal style geo-cms, tightly integrated with
> QGIS desktop (and QField/Input)*.
>
> Nyall
>
> * minus the completely broken-by-design security and data management
> models used by Portal
>
>
>
>
>
>
>
>
> Nyall
>
>
>
> Regards
>
> Tim
>
> On 8 Jun 2020, at 21:42, Jonathan Moules  wrote:
>
> Hi List,
> Some of you may have seen my blog post on the OSGeo-Discuss list about which 
> mapping servers are the most deployed. For those who haven't seen it, QGIS 
> Server has about 60 public deployments (1% of all of them), and it serves 
> 11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).
>
> Potentially controversial here and I appreciate it's not a competition, but 
> given the low uptake of QGIS Server compared to other Open Source offerings 
> (GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
> 389,709 datasets), is QGIS Server something the grant program should be 
> funding? There are three Server proposals totalling €10,000, 22% of the fund.
>
> Now, before you get the pitchforks out(!), please 

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Andreas Neumann]

Hi Nyall, 

Thanks for clarifying - I am relieved by your further statements ;-) 


I don't know a good replacement of ArcGIS Server portal (or whatever
that product is called currently). I agree that it would be great if
there would be a good replacement for that - and that would need further
funding - and perhaps a good collaboration between more than one of the
OSGEO/QGIS developer companies. I fear that any of the available
OSGeo/QGIS companies on it's own is too small to cover that fully. It
probably needs something larger on top of it, with the smaller already
existing companies bringing in their individual expertise to that larger
entity. QGIS cloud from Sourepole was a good start some years ago, but
it would have to grow faster than it currently does, and that would
require a larger entity than Sourcepole (or most other similar
companies) are. And of course also more paying customers. 

The building blocks are mostly there, yes. 

Andreas 


On 2020-06-09 11:45, Nyall Dawson wrote:

On Tue, 9 Jun 2020 at 09:18, Nyall Dawson  wrote: 
On Tue, 9 Jun 2020 at 09:12, Tim Sutton  wrote: 
Hi


Nice, thoughtful message below, thanks Jonathon. I wonder what it will take to move the needle above 1%? And whether we should try to use our funds to make that happen. QGIS is surely the most expressive way to do cartography of any GIS out there (acknowledging total bias on my part) and seeing that cartography on the web would surely please many people. Clients like QWC, QWC2 or anything that requires you to hand edit a config file or log into a unix shell to publish map services are probably the main limitation (no offence to those tools). Also the lack of an built in tiling server (with proper metalling and meta buffering) must surely be the other.  Maybe a more useful approach to your discussion below would be to promote funding the elements that add resistance to deploying QGIS server……but then we would be in new feature space and circling back to the idea of not funding QGIS Server with grants….. 
Something else to consider is whether technologies like WMS are

ultimately just "dead end" technologies now, and possibly we'd be
better off focusing on client side rendering of vector features from a
server (QGIS or other), and providing a library which can do
client-side rendering of vector tiles from QGIS symbology in as close
to 1:1 as possible...


Re-reading my message, I think it comes across unintentionally
critical. I was actually just "pondering aloud"!

I definitely agree that there's a strong use case for a server
component which "just works" with QGIS, and I would hate to see this
efforts abandoned. Indeed, my personal opinion is that what osgeo is
really lacking is a unified solution to desktop/web/mobile. We have
all the raw building blocks, but there's just no direct equivalent of
ArcGIS portal where end users can easily publish datasets and maps.
Boundless was filling this gap with their offerings, but that's a
thing of the past now, and no-one has really stepped up to fill this
need. Possibly geonode + QGIS server backend is the closest we get,
but that's still needing significant investment before it's a really
compelling competitor.

I'd really love to hear what solutions others deploy when they're
asked by a client to replace an ArcGIS desktop + Portal environment.
Perhaps there's actually a need for **more** investment in QGIS server
to fund development of a Portal style geo-cms, tightly integrated with
QGIS desktop (and QField/Input)*.

Nyall

* minus the completely broken-by-design security and data management
models used by Portal


Nyall


Regards

Tim

On 8 Jun 2020, at 21:42, Jonathan Moules  wrote:

Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list about which 
mapping servers are the most deployed. For those who haven't seen it, QGIS 
Server has about 60 public deployments (1% of all of them), and it serves 
11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).

Potentially controversial here and I appreciate it's not a competition, but 
given the low uptake of QGIS Server compared to other Open Source offerings 
(GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
389,709 datasets), is QGIS Server something the grant program should be 
funding? There are three Server proposals totalling EUR10,000, 22% of the fund.

Now, before you get the pitchforks out(!), please consider the following:

* Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
Desktop. (The grants mostly aren't things that will improve the shared QGIS 
Core). (This reasoning also follows through to OSGeo funds).

* Multiple solutions - Open Source (and OSGeo) already has a very healthy 
ecosystem of mapping servers - does it need another one?

* Limited number of users benefited - I don't have stats for it, but QGIS 
Desktop is probably the most popular Open Source Desktop GIS, and is certainly 
going to have many orders of magnitude 

[QGIS-Developer] GeoSeer ogc services data harvesting

[Andreas Neumann]

Hi Jonathan, 


Can you share with us how you harvest your information on available
public OGC services? You probably have that information published
somewhere - so if you could point me towards this URL, it would help. 


I noticed that all of the services of our province (my employer) can't
be found, as an example. 

Here is the start point: 


https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/geoportal/geodienste/wms-web-map-service/


and the GetCapabilities link: 


https://geo.so.ch/api/wms?SERVICE=WMS=GetCapabilities=1.3.0


So I wonder how many other QGIS server installations may not be in your
database? Of course I know you don't claim full coverage, but it would
still be good to know how you harvest your data. 

Thanks for clarifying and greetings, 


Andreas___
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 and the Grants programme

[Nyall Dawson]

On Tue, 9 Jun 2020 at 09:18, Nyall Dawson  wrote:
>
> On Tue, 9 Jun 2020 at 09:12, Tim Sutton  wrote:
> >
> > Hi
> >
> >
> > Nice, thoughtful message below, thanks Jonathon. I wonder what it will take 
> > to move the needle above 1%? And whether we should try to use our funds to 
> > make that happen. QGIS is surely the most expressive way to do cartography 
> > of any GIS out there (acknowledging total bias on my part) and seeing that 
> > cartography on the web would surely please many people. Clients like QWC, 
> > QWC2 or anything that requires you to hand edit a config file or log into a 
> > unix shell to publish map services are probably the main limitation (no 
> > offence to those tools). Also the lack of an built in tiling server (with 
> > proper metalling and meta buffering) must surely be the other.  Maybe a 
> > more useful approach to your discussion below would be to promote funding 
> > the elements that add resistance to deploying QGIS server……but then we 
> > would be in new feature space and circling back to the idea of not funding 
> > QGIS Server with grants…..
>
> Something else to consider is whether technologies like WMS are
> ultimately just "dead end" technologies now, and possibly we'd be
> better off focusing on client side rendering of vector features from a
> server (QGIS or other), and providing a library which can do
> client-side rendering of vector tiles from QGIS symbology in as close
> to 1:1 as possible...

Re-reading my message, I think it comes across unintentionally
critical. I was actually just "pondering aloud"!

I definitely agree that there's a strong use case for a server
component which "just works" with QGIS, and I would hate to see this
efforts abandoned. Indeed, my personal opinion is that what osgeo is
really lacking is a unified solution to desktop/web/mobile. We have
all the raw building blocks, but there's just no direct equivalent of
ArcGIS portal where end users can easily publish datasets and maps.
Boundless was filling this gap with their offerings, but that's a
thing of the past now, and no-one has really stepped up to fill this
need. Possibly geonode + QGIS server backend is the closest we get,
but that's still needing significant investment before it's a really
compelling competitor.

I'd really love to hear what solutions others deploy when they're
asked by a client to replace an ArcGIS desktop + Portal environment.
Perhaps there's actually a need for **more** investment in QGIS server
to fund development of a Portal style geo-cms, tightly integrated with
QGIS desktop (and QField/Input)*.

Nyall

* minus the completely broken-by-design security and data management
models used by Portal







>
> Nyall
>
>
> >
> > Regards
> >
> > Tim
> >
> > On 8 Jun 2020, at 21:42, Jonathan Moules  
> > wrote:
> >
> > Hi List,
> > Some of you may have seen my blog post on the OSGeo-Discuss list about 
> > which mapping servers are the most deployed. For those who haven't seen it, 
> > QGIS Server has about 60 public deployments (1% of all of them), and it 
> > serves 11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS 
> > datasets).
> >
> > Potentially controversial here and I appreciate it's not a competition, but 
> > given the low uptake of QGIS Server compared to other Open Source offerings 
> > (GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
> > 389,709 datasets), is QGIS Server something the grant program should be 
> > funding? There are three Server proposals totalling €10,000, 22% of the 
> > fund.
> >
> > Now, before you get the pitchforks out(!), please consider the following:
> >
> > * Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
> > Desktop. (The grants mostly aren't things that will improve the shared QGIS 
> > Core). (This reasoning also follows through to OSGeo funds).
> >
> > * Multiple solutions - Open Source (and OSGeo) already has a very healthy 
> > ecosystem of mapping servers - does it need another one?
> >
> > * Limited number of users benefited - I don't have stats for it, but QGIS 
> > Desktop is probably the most popular Open Source Desktop GIS, and is 
> > certainly going to have many orders of magnitude more users than QGIS 
> > Server.
> >
> > * Playing to your strengths - QGIS' strength is it's Desktop and it's 
> > generally good practice to play to your strengths.
> >
> >
> > So given the above, and that QGIS is already "winning" as an Open Source 
> > Desktop (great job!), I'd like to suggest it's not a good idea to dilute 
> > the limited resources by spending them on QGIS Server. Instead it seems 
> > that far more people would benefit if that money was spent on Desktop, 
> > especially the bug fixing programme.
> >
> > Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
> > integration with QGIS Desktop, those resources could be used to further 
> > improve interoperability with GeoServer/MapServer/deegree/etc. Those are 
> > all 

[QGIS-Developer] Plugin [2084] GéoGrandEst approval notification.

[noreply]

Plugin GéoGrandEst approval by zimbogisgeek.
The plugin version "[2084] GéoGrandEst 0.9.1" is now approved
Link: http://plugins.qgis.org/plugins/geograndest/
___
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 and the Grants programme

[Régis Haubourg]

Hi,
I can't agree more with Andreas.

Just note that we have major companies betting on QGIS server for
production use and considering switching from Geoserver to QGIS server to
get rid of the double administration task burden.
They fund progressively what is missing and QGIS.org helps sometimes for
OGC certification testing and documentation but the majority of the fund
are not made by QGIS.org

So yes, we have open ecosystems, I don't get the point of trying to cut
(small) funds on a solution that is useful, supported by users and funders.

Best regards
Régis


Le mar. 9 juin 2020 à 11:12, Andreas Neumann  a écrit :

> Hi Jonathan,
>
> Rest assured - the majority of QGIS funds is already (and has always been
> going) into bug fixing. Again - both Desktop and server users benefit from
> that bug fixing.
>
> We publish our financial reports here:
> https://www.qgis.org/en/site/getinvolved/governance/finance/index.html
>
> If you look into the 2019 report, you can see that around 50% of our funds
> go into bug fixing and quality assurance (in some years even more). Only
> about 10% of our funds went into the grants in 2019. And from these grants,
> server received a small fraction. So, the absolute amounts of investments
> that QGIS.ORG invests into QGIS sever is really negligible.
>
> Most investments done in QGIS server go directly from clients to QGIS
> development companies - and that has nothing to do with QGIS.ORG
>
> If you talk about the number of users of a server installation - I think
> this is debateable: if you only count the admin of a server (regardless of
> which server), then the numbers are low - no matter if we talk about ArcGIS
> server, Geoserver, UMN, QGIS, etc. But every server easily has a hundred or
> sometimes several thousand users who use these services - don't you think.
> If I look at our small province - we have maybe 100 QGIS desktop users, but
> certainly several thousand users who use our Web-GIS and OGC services -
> don't you agree? And our services integrate with a lot of other
> applications that are vital to a province level government. So in this
> perspective, (QGIS)-server installations need to be multiplied with some
> factor to compare it with QGIS desktop user numbers.
>
> Andreas
>
> On 2020-06-09 10:38, Jonathan Moules wrote:
>
> Hi Andreas, (& All),
> A fair point, but I believe this is an important point and this year I do
> have data to back up my point; in fact the grant program is what motivated
> me to finally get around to doing this analysis.
>
> It seems from the replies that while there are a few differentiators, the
> key one is indeed cartography and styling. (There's also an interesting
> conversation about vectors going on there too). Some thoughts:
> * The vast majority of WMS/WMTS layers are not cartographically
> complicated, let alone beautiful. They're "here is a layer with small green
> points for trees", and "this polygon represents conservation areas". You
> can easily play around and see what's out there here:
> http://www.geoseer.net/api-demo/
> * WFS/WCS can't be styled server side.
> * It seems like overkill to create and maintain an entire server
> distribution that fundamentally only solves one (relatively simple compared
> to what QGIS Desktop can do) problem.
> * Rendering is only one part the QGIS package (Analysis, digitisation,
> management, etc.).
>
> If I'm honest, the "competition" on this point isn't really between QGIS
> and MapServer/GeoServer. It's really between QGIS and ArcGIS. Because
> ArcGIS does exactly what QGIS Server seeks to do: offer a single integrated
> solution for Desktop-> Server. And certainly ArcGIS Server does have a huge
> number of deployments (53%), however again, there really aren't many
> cartographically complicated outputs on there. And despite the huge number
> of deployments, most services and datasets are actually served by
> MapServer/GeoServer (about 60% of datasets between them!). Basically ArcGIS
> is deployed by local government and used for bitty-stuff ("here are our
> fire stations"), but if you want a real data-service then you go with
> GeoServer/MapServer/etc.
>
> Most importantly though, I think I haven't conveyed my core point well:
> this really is a zero sum game!
> Even allowing for the above, any funds spent on QGIS Server are not spent
> on QGIS Desktop. There are 60 public facing QGIS Server deployments. Even
> assuming that there's a ratio of 10:1 for private/public servers (made up
> ratio, feels too high), any funding on QGIS Server benefits only hundreds,
> or being very generous, maybe low-thousands number of users. Funding on
> QGIS Desktop however benefits as a *minimum* tens of thousands, potentially
> millions of users (no idea how many QGIS installs there are, I can't find
> the download-stats I remember seeing in the past).
> Heck, even pretending for a second QGIS Server had 100% of the deployments
> (a 100 fold increase!), there would /still/ be orders of 

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Andreas Neumann]

Hi Jonathan, 


Rest assured - the majority of QGIS funds is already (and has always
been going) into bug fixing. Again - both Desktop and server users
benefit from that bug fixing. 


We publish our financial reports here:
https://www.qgis.org/en/site/getinvolved/governance/finance/index.html 


If you look into the 2019 report, you can see that around 50% of our
funds go into bug fixing and quality assurance (in some years even
more). Only about 10% of our funds went into the grants in 2019. And
from these grants, server received a small fraction. So, the absolute
amounts of investments that QGIS.ORG invests into QGIS sever is really
negligible. 


Most investments done in QGIS server go directly from clients to QGIS
development companies - and that has nothing to do with QGIS.ORG 


If you talk about the number of users of a server installation - I think
this is debateable: if you only count the admin of a server (regardless
of which server), then the numbers are low - no matter if we talk about
ArcGIS server, Geoserver, UMN, QGIS, etc. But every server easily has a
hundred or sometimes several thousand users who use these services -
don't you think. If I look at our small province - we have maybe 100
QGIS desktop users, but certainly several thousand users who use our
Web-GIS and OGC services - don't you agree? And our services integrate
with a lot of other applications that are vital to a province level
government. So in this perspective, (QGIS)-server installations need to
be multiplied with some factor to compare it with QGIS desktop user
numbers. 

Andreas 


On 2020-06-09 10:38, Jonathan Moules wrote:


Hi Andreas, (& All),
A fair point, but I believe this is an important point and this year I do have 
data to back up my point; in fact the grant program is what motivated me to 
finally get around to doing this analysis.

It seems from the replies that while there are a few differentiators, the key 
one is indeed cartography and styling. (There's also an interesting 
conversation about vectors going on there too). Some thoughts:
* The vast majority of WMS/WMTS layers are not cartographically complicated, let alone beautiful. 
They're "here is a layer with small green points for trees", and "this polygon 
represents conservation areas". You can easily play around and see what's out there here: 
http://www.geoseer.net/api-demo/
* WFS/WCS can't be styled server side.
* It seems like overkill to create and maintain an entire server distribution 
that fundamentally only solves one (relatively simple compared to what QGIS 
Desktop can do) problem.
* Rendering is only one part the QGIS package (Analysis, digitisation, 
management, etc.).

If I'm honest, the "competition" on this point isn't really between QGIS and 
MapServer/GeoServer. It's really between QGIS and ArcGIS. Because ArcGIS does exactly what QGIS Server 
seeks to do: offer a single integrated solution for Desktop-> Server. And certainly ArcGIS Server 
does have a huge number of deployments (53%), however again, there really aren't many cartographically 
complicated outputs on there. And despite the huge number of deployments, most services and datasets 
are actually served by MapServer/GeoServer (about 60% of datasets between them!). Basically ArcGIS is 
deployed by local government and used for bitty-stuff ("here are our fire stations"), but if 
you want a real data-service then you go with GeoServer/MapServer/etc.

Most importantly though, I think I haven't conveyed my core point well: this 
really is a zero sum game!
Even allowing for the above, any funds spent on QGIS Server are not spent on 
QGIS Desktop. There are 60 public facing QGIS Server deployments. Even assuming 
that there's a ratio of 10:1 for private/public servers (made up ratio, feels 
too high), any funding on QGIS Server benefits only hundreds, or being very 
generous, maybe low-thousands number of users. Funding on QGIS Desktop however 
benefits as a *minimum* tens of thousands, potentially millions of users (no 
idea how many QGIS installs there are, I can't find the download-stats I 
remember seeing in the past).
Heck, even pretending for a second QGIS Server had 100% of the deployments (a 
100 fold increase!), there would /still/ be orders of magnitude more people 
using the not-Server parts of QGIS Desktop by its very nature.

There are 3,102 open issues on the QGIS issue tracker. 95 are labelled regressions, 137 are "high 
priority", and 92 are "crash/data corruption". Just 49 are "Server". I'm not seeking 
to denigrate the project here; QGIS is a extremely complex tool that is an amazing accomplishment and by its 
nature it will have bugs. I raise these numbers to highlight that any money spent on Grants to Server (and 
yes new Desktop features) is money that isn't spent fixing these (I'm aware of the bug-fixing fund). 
Something I think the grant voters should be cognizant of.

Hope that clarifies,
I'll step back now. :-)
Cheers,
Jonathan

On 09/06/2020 08:09, 

[QGIS-Developer] Plugin [1143] PostGIS Sampling Tool approval notification.

[noreply]

Plugin PostGIS Sampling Tool approval by zimbogisgeek.
The plugin version "[1143] PostGIS Sampling Tool 1.5.1" is now approved
Link: http://plugins.qgis.org/plugins/postgis_sampling_tool/
___
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 and the Grants programme

[Jonathan Moules]

Hi Andreas, (& All),
A fair point, but I believe this is an important point and this year I 
do have data to back up my point; in fact the grant program is what 
motivated me to finally get around to doing this analysis.


It seems from the replies that while there are a few differentiators, 
the key one is indeed cartography and styling. (There's also an 
interesting conversation about vectors going on there too). Some thoughts:
* The vast majority of WMS/WMTS layers are not cartographically 
complicated, let alone beautiful. They're "here is a layer with small 
green points for trees", and "this polygon represents conservation 
areas". You can easily play around and see what's out there here: 
http://www.geoseer.net/api-demo/

* WFS/WCS can't be styled server side.
* It seems like overkill to create and maintain an entire server 
distribution that fundamentally only solves one (relatively simple 
compared to what QGIS Desktop can do) problem.
* Rendering is only one part the QGIS package (Analysis, digitisation, 
management, etc.).


If I'm honest, the "competition" on this point isn't really between QGIS 
and MapServer/GeoServer. It's really between QGIS and ArcGIS. Because 
ArcGIS does exactly what QGIS Server seeks to do: offer a single 
integrated solution for Desktop-> Server. And certainly ArcGIS Server 
does have a huge number of deployments (53%), however again, there 
really aren't many cartographically complicated outputs on there. And 
despite the huge number of deployments, most services and datasets are 
actually served by MapServer/GeoServer (about 60% of datasets between 
them!). Basically ArcGIS is deployed by local government and used for 
bitty-stuff ("here are our fire stations"), but if you want a real 
data-service then you go with GeoServer/MapServer/etc.


Most importantly though, I think I haven't conveyed my core point well: 
this really is a zero sum game!
Even allowing for the above, any funds spent on QGIS Server are not 
spent on QGIS Desktop. There are 60 public facing QGIS Server 
deployments. Even assuming that there's a ratio of 10:1 for 
private/public servers (made up ratio, feels too high), any funding on 
QGIS Server benefits only hundreds, or being very generous, maybe 
low-thousands number of users. Funding on QGIS Desktop however benefits 
as a *minimum* tens of thousands, potentially millions of users (no idea 
how many QGIS installs there are, I can't find the download-stats I 
remember seeing in the past).
Heck, even pretending for a second QGIS Server had 100% of the 
deployments (a 100 fold increase!), there would /still/ be orders of 
magnitude more people using the not-Server parts of QGIS Desktop by its 
very nature.


There are 3,102 open issues on the QGIS issue tracker. 95 are labelled 
regressions, 137 are "high priority", and 92 are "crash/data 
corruption". Just 49 are "Server". I'm not seeking to denigrate the 
project here; QGIS is a extremely complex tool that is an amazing 
accomplishment and by its nature it will have bugs. I raise these 
numbers to highlight that any money spent on Grants to Server (and yes 
new Desktop features) is money that isn't spent fixing these (I'm aware 
of the bug-fixing fund). Something I think the grant voters should be 
cognizant of.


Hope that clarifies,
I'll step back now. :-)
Cheers,
Jonathan


On 09/06/2020 08:09, Andreas Neumann wrote:

Hi Jonathan,
You keep repeating yourself. You started the exact same discussion a
year ago.
You have a valid point, of course, I don't argue that. But if you think
about small organizations  that do not have a lot of personal (or
financial) resources, it would be a lot of burden to invest twice the
time in styling: once for QGIS desktop and another time again for UMN
mapserver and Geoserver. Even if SLD output from QGIS improved (also
thanks to efforts of Andrea Aime and others), it still can't transport
everything. If it would, then I would better agree with your argument.
For such smaller organization, speed (and I know that UMN and Geoserver
are a bit faster than QGIS server) is not the only important thing - it
is also their personal and financial resources and complexity of their
software landscape.
And QGIS server has some other unique selling points: the proprietary
GetPrint command that doesn't have a match in Geoserver or UMN, the
ability to create Atlases from server, and who knows, in the future
perhaps QGIS server can run processing models.
Greetings,
Andreas
On 2020-06-08 22:42, Jonathan Moules wrote:


Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list 
about which mapping servers are the most deployed. For those who 
haven't seen it, QGIS Server has about 60 public deployments (1% of 
all of them), and it serves 11,924 datasets (0.5% of all public 
geospatial WMS/WFS/WCS/WMTS datasets).


Potentially controversial here and I appreciate it's not a 
competition, but given the low uptake of QGIS Server compared to 
other Open Source 

[QGIS-Developer] QGIS Server and the Grants programme

[Maaza Mekuria]

ugin version "[383] Buffer by Percentage 0.3.3" is now approved
> Link: http://plugins.qgis.org/plugins/BufferByPercentage/
>
>
> --
>
> Message: 3
> Date: Tue, 9 Jun 2020 00:09:13 +0100
> From: Tim Sutton 
> To: jonathan-li...@lightpear.com
> Cc: QGIS Developer 
> Subject: Re: [QGIS-Developer] QGIS Server and the Grants programme
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
>
> Nice, thoughtful message below, thanks Jonathon. I wonder what it will
> take to move the needle above 1%? And whether we should try to use our
> funds to make that happen. QGIS is surely the most expressive way to do
> cartography of any GIS out there (acknowledging total bias on my part) and
> seeing that cartography on the web would surely please many people. Clients
> like QWC, QWC2 or anything that requires you to hand edit a config file or
> log into a unix shell to publish map services are probably the main
> limitation (no offence to those tools). Also the lack of an built in tiling
> server (with proper metalling and meta buffering) must surely be the
> other.  Maybe a more useful approach to your discussion below would be to
> promote funding the elements that add resistance to deploying QGIS
> server……but then we would be in new feature space and circling back to the
> idea of not funding QGIS Server with grants…..
>
> Regards
>
> Tim
>
> > On 8 Jun 2020, at 21:42, Jonathan Moules 
> wrote:
> >
> > Hi List,
> > Some of you may have seen my blog post on the OSGeo-Discuss list about
> which mapping servers are the most deployed. For those who haven't seen it,
> QGIS Server has about 60 public deployments (1% of all of them), and it
> serves 11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS
> datasets).
> >
> > Potentially controversial here and I appreciate it's not a competition,
> but given the low uptake of QGIS Server compared to other Open Source
> offerings (GeoServer: 964 deployments, 963,603 datasets; MapServer: 544
> deployments, 389,709 datasets), is QGIS Server something the grant program
> should be funding? There are three Server proposals totalling €10,000, 22%
> of the fund.
> >
> > Now, before you get the pitchforks out(!), please consider the following:
> >
> > * Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS
> Desktop. (The grants mostly aren't things that will improve the shared QGIS
> Core). (This reasoning also follows through to OSGeo funds).
> >
> > * Multiple solutions - Open Source (and OSGeo) already has a very
> healthy ecosystem of mapping servers - does it need another one?
> >
> > * Limited number of users benefited - I don't have stats for it, but
> QGIS Desktop is probably the most popular Open Source Desktop GIS, and is
> certainly going to have many orders of magnitude more users than QGIS
> Server.
> >
> > * Playing to your strengths - QGIS' strength is it's Desktop and it's
> generally good practice to play to your strengths.
> >
> >
> > So given the above, and that QGIS is already "winning" as an Open Source
> Desktop (great job!), I'd like to suggest it's not a good idea to dilute
> the limited resources by spending them on QGIS Server. Instead it seems
> that far more people would benefit if that money was spent on Desktop,
> especially the bug fixing programme.
> >
> > Or alternatively, given the "Unique Selling Point" of QGIS Server is its
> integration with QGIS Desktop, those resources could be used to further
> improve interoperability with GeoServer/MapServer/deegree/etc. Those are
> all successful mature OSGeo projects that excel at serving maps, have an
> architecture designed for it, and already have huge install bases.
> >
> > TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should
> play to its strengths and focus its limited funds there to benefit the most
> users.
> >
> > I shall now retreat to my bunker. :-)
> >
> > Cheers,
> > Jonathan
> >
> > Note: The above only applies to the Grant program and funding; how
> developers wish to spend their time, and on which projects is of course
> their own prerogative.
> >
> > (Disclosure: I have no horse in this race; I don't run or administer any
> mapping servers, but I have done GeoServer in the past.)
> >
> >
> >
> > ___
> > 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/list

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Andreas Neumann]

Hi Alessandro, 

Good idea - I would be happy to join such a meeting. 


In our case (talking for my employer), it is mainly performance,
reliability, scalability and maintenance where we would like to see
improvements. A cache that can be shared between instances would be
great to have. And perhaps a management interface where one could get a
better insight to the state of QGIS server and it's cache: what projects
are cached, how much memory do they need, ability to reload certain
projects, etc. 


Of course, there might be other aspects as well, but the above mentioned
issues are our main pain points currently. 

We would also help with some funding and I can help to attract others. 

Andreas 


On 2020-06-09 09:24, Alessandro Pasotti wrote:


Thank you Jonathan for raising the discussion, I think this should be
a good opportunity to focus on how we can gain a bigger "market share"
and restart investing on the server with both time and funds.

Full disclaimer: I'm a QGIS server developer.

It would be probably useful to start a discussion about how we can
make QGIS Server better and what makes it lag behind "competitors",
both FOSS and proprietary.

- Is it missing features?
- performances/scalability?
- standard compliance?
- missing protocols (WPS...)?
- documentation/examples?
- ease of deployment/maintenance?
- security auditing?
- plain marketing?

I've personally found exceptionally productive the QGIS Server Meeting
we had in Lion a few years back (that ultimately led to a deep
refactoring of the server), I think we should organize a dedicated
(online) meeting with the interested parties to start a discussion and
share ideas.

Regards

On Tue, Jun 9, 2020 at 9:09 AM Andreas Neumann  wrote: 


Hi Jonathan,

You keep repeating yourself. You started the exact same discussion a year ago.

You have a valid point, of course, I don't argue that. But if you think about 
small organizations  that do not have a lot of personal (or financial) 
resources, it would be a lot of burden to invest twice the time in styling: 
once for QGIS desktop and another time again for UMN mapserver and Geoserver. 
Even if SLD output from QGIS improved (also thanks to efforts of Andrea Aime 
and others), it still can't transport everything. If it would, then I would 
better agree with your argument.

For such smaller organization, speed (and I know that UMN and Geoserver are a 
bit faster than QGIS server) is not the only important thing - it is also their 
personal and financial resources and complexity of their software landscape.

And QGIS server has some other unique selling points: the proprietary GetPrint 
command that doesn't have a match in Geoserver or UMN, the ability to create 
Atlases from server, and who knows, in the future perhaps QGIS server can run 
processing models.

Greetings,

Andreas

On 2020-06-08 22:42, Jonathan Moules wrote:

Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list about which 
mapping servers are the most deployed. For those who haven't seen it, QGIS 
Server has about 60 public deployments (1% of all of them), and it serves 
11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).

Potentially controversial here and I appreciate it's not a competition, but 
given the low uptake of QGIS Server compared to other Open Source offerings 
(GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
389,709 datasets), is QGIS Server something the grant program should be 
funding? There are three Server proposals totalling EUR10,000, 22% of the fund.

Now, before you get the pitchforks out(!), please consider the following:

* Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
Desktop. (The grants mostly aren't things that will improve the shared QGIS 
Core). (This reasoning also follows through to OSGeo funds).

* Multiple solutions - Open Source (and OSGeo) already has a very healthy 
ecosystem of mapping servers - does it need another one?

* Limited number of users benefited - I don't have stats for it, but QGIS 
Desktop is probably the most popular Open Source Desktop GIS, and is certainly 
going to have many orders of magnitude more users than QGIS Server.

* Playing to your strengths - QGIS' strength is it's Desktop and it's generally 
good practice to play to your strengths.

So given the above, and that QGIS is already "winning" as an Open Source 
Desktop (great job!), I'd like to suggest it's not a good idea to dilute the limited 
resources by spending them on QGIS Server. Instead it seems that far more people would 
benefit if that money was spent on Desktop, especially the bug fixing programme.

Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
integration with QGIS Desktop, those resources could be used to further improve 
interoperability with GeoServer/MapServer/deegree/etc. Those are all successful mature 
OSGeo projects that excel at serving maps, have an architecture designed for 

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Jeremy Palmer]

On Tue, Jun 9, 2020 at 4:25 PM Richard Duivenvoorde 
wrote:

> On 6/9/20 1:18 AM, Nyall Dawson wrote:
> > Something else to consider is whether technologies like WMS are
> > ultimately just "dead end" technologies now,
>
> Definitely not agreeing here :-)
>
> > and possibly we'd be
> > better off focusing on client side rendering of vector features from a
> > server (QGIS or other), and providing a library which can do
> > client-side rendering of vector tiles from QGIS symbology in as close
> > to 1:1 as possible...
>
> For full blown nice reference maps or aerials  WM(T)S is still the way
> to go. For simpler reference maps like Google, vector tiles will be...
>

XYZ/WMTS maps are certainly the way to go with raster products like aerials
or satellite data, which are for visualisation only. However, when it comes
to a national agency providing highly scalable vector map services, we have
concluded that using WMTS/WMS rasters has too many downsides. The key
benefits of vector tiles are:

* Faster generation of caches for serverless provision. Often you don't
need to generate vector tiles for each required client-side zoom
level/scale, and over-zooming is good enough. In some cases making raster
tiles with complex carto rules required massive computing resources and
timeframes. Even with cloud services, this is a key roadblock unless you
build very complex infrastructure architectures with auto-scaling. Even
then, it's costly to run and needs excellent expertise to set-up.
* Labels are nicely rendered client-side taking the device PPI into
account. For raster maps, generating maps for different DPIs becomes a
nightmare
* Being generally smaller which is essential for delivery to low bandwidth
devices
* Better user experience with seamless zooming and rotating of maps

I agree that raster maps can still produce nicer catro that vector tiles
(especially with combined raster/vector effects). However, raster web map
services have too many scalability issues, and in some cases, as mentioned
above, produce poor visual results or user experiences.  Of course, vector
WMS/WMTS still has it's a place for low volume websites.

In saying all of this, it would be great to get a seamless workflow from
data to published web maps. This needs to include having a style generator
(almost!) equivalent to QGIS desktop and a simple way to host and provide
maps at scale. I'm especially keen to see styling and export of vector
tiles in QGIS (it's almost there thanks to Martin and recent crowdfunding
initiative).

Cheers
Jeremy
___
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 and the Grants programme

[Alessandro Pasotti]

Thank you Jonathan for raising the discussion, I think this should be
a good opportunity to focus on how we can gain a bigger "market share"
and restart investing on the server with both time and funds.

Full disclaimer: I'm a QGIS server developer.

It would be probably useful to start a discussion about how we can
make QGIS Server better and what makes it lag behind "competitors",
both FOSS and proprietary.

- Is it missing features?
- performances/scalability?
- standard compliance?
- missing protocols (WPS...)?
- documentation/examples?
- ease of deployment/maintenance?
- security auditing?
- plain marketing?

I've personally found exceptionally productive the QGIS Server Meeting
we had in Lion a few years back (that ultimately led to a deep
refactoring of the server), I think we should organize a dedicated
(online) meeting with the interested parties to start a discussion and
share ideas.

Regards


On Tue, Jun 9, 2020 at 9:09 AM Andreas Neumann  wrote:
>
> Hi Jonathan,
>
> You keep repeating yourself. You started the exact same discussion a year ago.
>
> You have a valid point, of course, I don't argue that. But if you think about 
> small organizations  that do not have a lot of personal (or financial) 
> resources, it would be a lot of burden to invest twice the time in styling: 
> once for QGIS desktop and another time again for UMN mapserver and Geoserver. 
> Even if SLD output from QGIS improved (also thanks to efforts of Andrea Aime 
> and others), it still can't transport everything. If it would, then I would 
> better agree with your argument.
>
> For such smaller organization, speed (and I know that UMN and Geoserver are a 
> bit faster than QGIS server) is not the only important thing - it is also 
> their personal and financial resources and complexity of their software 
> landscape.
>
> And QGIS server has some other unique selling points: the proprietary 
> GetPrint command that doesn't have a match in Geoserver or UMN, the ability 
> to create Atlases from server, and who knows, in the future perhaps QGIS 
> server can run processing models.
>
> Greetings,
>
> Andreas
>
> On 2020-06-08 22:42, Jonathan Moules wrote:
>
> Hi List,
> Some of you may have seen my blog post on the OSGeo-Discuss list about which 
> mapping servers are the most deployed. For those who haven't seen it, QGIS 
> Server has about 60 public deployments (1% of all of them), and it serves 
> 11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).
>
> Potentially controversial here and I appreciate it's not a competition, but 
> given the low uptake of QGIS Server compared to other Open Source offerings 
> (GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
> 389,709 datasets), is QGIS Server something the grant program should be 
> funding? There are three Server proposals totalling €10,000, 22% of the fund.
>
> Now, before you get the pitchforks out(!), please consider the following:
>
> * Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
> Desktop. (The grants mostly aren't things that will improve the shared QGIS 
> Core). (This reasoning also follows through to OSGeo funds).
>
> * Multiple solutions - Open Source (and OSGeo) already has a very healthy 
> ecosystem of mapping servers - does it need another one?
>
> * Limited number of users benefited - I don't have stats for it, but QGIS 
> Desktop is probably the most popular Open Source Desktop GIS, and is 
> certainly going to have many orders of magnitude more users than QGIS Server.
>
> * Playing to your strengths - QGIS' strength is it's Desktop and it's 
> generally good practice to play to your strengths.
>
>
> So given the above, and that QGIS is already "winning" as an Open Source 
> Desktop (great job!), I'd like to suggest it's not a good idea to dilute the 
> limited resources by spending them on QGIS Server. Instead it seems that far 
> more people would benefit if that money was spent on Desktop, especially the 
> bug fixing programme.
>
> Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
> integration with QGIS Desktop, those resources could be used to further 
> improve interoperability with GeoServer/MapServer/deegree/etc. Those are all 
> successful mature OSGeo projects that excel at serving maps, have an 
> architecture designed for it, and already have huge install bases.
>
> TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should play 
> to its strengths and focus its limited funds there to benefit the most users.
>
> I shall now retreat to my bunker. :-)
>
> Cheers,
> Jonathan
>
> Note: The above only applies to the Grant program and funding; how developers 
> wish to spend their time, and on which projects is of course their own 
> prerogative.
>
> (Disclosure: I have no horse in this race; I don't run or administer any 
> mapping servers, but I have done GeoServer in the past.)
>
>
>
> ___
> 

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Raymond Nijssen]

And imagine that

Mapserver 1.0,
GeoServer 1.0 and
QGIS Server 1.0

had all been released at the same date. What would these deployment 
numbers have been like now?


Regards,
Raymond


On 09-06-2020 01:18, Nyall Dawson wrote:

On Tue, 9 Jun 2020 at 09:12, Tim Sutton  wrote:


Hi


Nice, thoughtful message below, thanks Jonathon. I wonder what it will take to 
move the needle above 1%? And whether we should try to use our funds to make 
that happen. QGIS is surely the most expressive way to do cartography of any 
GIS out there (acknowledging total bias on my part) and seeing that cartography 
on the web would surely please many people. Clients like QWC, QWC2 or anything 
that requires you to hand edit a config file or log into a unix shell to 
publish map services are probably the main limitation (no offence to those 
tools). Also the lack of an built in tiling server (with proper metalling and 
meta buffering) must surely be the other.  Maybe a more useful approach to your 
discussion below would be to promote funding the elements that add resistance 
to deploying QGIS server……but then we would be in new feature space and 
circling back to the idea of not funding QGIS Server with grants…..


Something else to consider is whether technologies like WMS are
ultimately just "dead end" technologies now, and possibly we'd be
better off focusing on client side rendering of vector features from a
server (QGIS or other), and providing a library which can do
client-side rendering of vector tiles from QGIS symbology in as close
to 1:1 as possible...

Nyall




Regards

Tim

On 8 Jun 2020, at 21:42, Jonathan Moules  wrote:

Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list about which 
mapping servers are the most deployed. For those who haven't seen it, QGIS 
Server has about 60 public deployments (1% of all of them), and it serves 
11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).

Potentially controversial here and I appreciate it's not a competition, but 
given the low uptake of QGIS Server compared to other Open Source offerings 
(GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
389,709 datasets), is QGIS Server something the grant program should be 
funding? There are three Server proposals totalling €10,000, 22% of the fund.

Now, before you get the pitchforks out(!), please consider the following:

* Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
Desktop. (The grants mostly aren't things that will improve the shared QGIS 
Core). (This reasoning also follows through to OSGeo funds).

* Multiple solutions - Open Source (and OSGeo) already has a very healthy 
ecosystem of mapping servers - does it need another one?

* Limited number of users benefited - I don't have stats for it, but QGIS 
Desktop is probably the most popular Open Source Desktop GIS, and is certainly 
going to have many orders of magnitude more users than QGIS Server.

* Playing to your strengths - QGIS' strength is it's Desktop and it's generally 
good practice to play to your strengths.


So given the above, and that QGIS is already "winning" as an Open Source 
Desktop (great job!), I'd like to suggest it's not a good idea to dilute the limited 
resources by spending them on QGIS Server. Instead it seems that far more people would 
benefit if that money was spent on Desktop, especially the bug fixing programme.

Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
integration with QGIS Desktop, those resources could be used to further improve 
interoperability with GeoServer/MapServer/deegree/etc. Those are all successful mature 
OSGeo projects that excel at serving maps, have an architecture designed for it, and 
already have huge install bases.

TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should play to 
its strengths and focus its limited funds there to benefit the most users.

I shall now retreat to my bunker. :-)

Cheers,
Jonathan

Note: The above only applies to the Grant program and funding; how developers 
wish to spend their time, and on which projects is of course their own 
prerogative.

(Disclosure: I have no horse in this race; I don't run or administer any 
mapping servers, but I have done GeoServer in the past.)



___
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
Ex Project chair: QGIS.org

Visit http://kartoza.com to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link to make finding time easy.

___
QGIS-Developer mailing list

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Andreas Neumann]

Hi Jonathan, 


You keep repeating yourself. You started the exact same discussion a
year ago. 


You have a valid point, of course, I don't argue that. But if you think
about small organizations  that do not have a lot of personal (or
financial) resources, it would be a lot of burden to invest twice the
time in styling: once for QGIS desktop and another time again for UMN
mapserver and Geoserver. Even if SLD output from QGIS improved (also
thanks to efforts of Andrea Aime and others), it still can't transport
everything. If it would, then I would better agree with your argument. 


For such smaller organization, speed (and I know that UMN and Geoserver
are a bit faster than QGIS server) is not the only important thing - it
is also their personal and financial resources and complexity of their
software landscape. 


And QGIS server has some other unique selling points: the proprietary
GetPrint command that doesn't have a match in Geoserver or UMN, the
ability to create Atlases from server, and who knows, in the future
perhaps QGIS server can run processing models. 

Greetings, 

Andreas 


On 2020-06-08 22:42, Jonathan Moules wrote:


Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list about which 
mapping servers are the most deployed. For those who haven't seen it, QGIS 
Server has about 60 public deployments (1% of all of them), and it serves 
11,924 datasets (0.5% of all public geospatial WMS/WFS/WCS/WMTS datasets).

Potentially controversial here and I appreciate it's not a competition, but 
given the low uptake of QGIS Server compared to other Open Source offerings 
(GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 deployments, 
389,709 datasets), is QGIS Server something the grant program should be 
funding? There are three Server proposals totalling EUR10,000, 22% of the fund.

Now, before you get the pitchforks out(!), please consider the following:

* Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
Desktop. (The grants mostly aren't things that will improve the shared QGIS 
Core). (This reasoning also follows through to OSGeo funds).

* Multiple solutions - Open Source (and OSGeo) already has a very healthy 
ecosystem of mapping servers - does it need another one?

* Limited number of users benefited - I don't have stats for it, but QGIS 
Desktop is probably the most popular Open Source Desktop GIS, and is certainly 
going to have many orders of magnitude more users than QGIS Server.

* Playing to your strengths - QGIS' strength is it's Desktop and it's generally 
good practice to play to your strengths.

So given the above, and that QGIS is already "winning" as an Open Source 
Desktop (great job!), I'd like to suggest it's not a good idea to dilute the limited 
resources by spending them on QGIS Server. Instead it seems that far more people would 
benefit if that money was spent on Desktop, especially the bug fixing programme.

Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
integration with QGIS Desktop, those resources could be used to further improve 
interoperability with GeoServer/MapServer/deegree/etc. Those are all successful mature 
OSGeo projects that excel at serving maps, have an architecture designed for it, and 
already have huge install bases.

TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should play to 
its strengths and focus its limited funds there to benefit the most users.

I shall now retreat to my bunker. :-)

Cheers,
Jonathan

Note: The above only applies to the Grant program and funding; how developers 
wish to spend their time, and on which projects is of course their own 
prerogative.

(Disclosure: I have no horse in this race; I don't run or administer any 
mapping servers, but I have done GeoServer in the past.)

___
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 and the Grants programme

[Luigi Pirelli]

I'm not a backend guy nor a qgis server expert, but because years ago
involved in finding solution to grow style incompatibility among geoserver
and qgis via sld (before in Boundless end to nothing because there were any
tech solution... or I'm too tech limiteated to imagine a solution) later
adding support for sld/raster in qgis, I could say:

1) qgis server is mainly used to respect styling and avoid headaches in
converting to other style languages... and secondarily as wps engine.
2) geoserver side never considered seriously to think at qgis server as
renderer delegate... or at least was my impression with geoserver guys in
Boundless
3) There is no way to represent rich map style in a interoperability way...
sadly I agree with you, qgis is creating (yet) another de facto
style language and I'm not proud of this, but far from me to judge, I'm not
a cartographer too!
3) Style rendering is heavily moving to client side

so having this open point, I can't say what would be better or not
financing a qgis server grant... For sure would be better facilitate qgis
project style rendering in other server platforms, but the solution does
not pass using SLD!

Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition

* Hire a team: http://www.qcooperative.net
**


On Mon, 8 Jun 2020 at 22:43, Jonathan Moules 
wrote:

> Hi List,
> Some of you may have seen my blog post on the OSGeo-Discuss list about
> which mapping servers are the most deployed. For those who haven't seen
> it, QGIS Server has about 60 public deployments (1% of all of them), and
> it serves 11,924 datasets (0.5% of all public geospatial
> WMS/WFS/WCS/WMTS datasets).
>
> Potentially controversial here and I appreciate it's not a competition,
> but given the low uptake of QGIS Server compared to other Open Source
> offerings (GeoServer: 964 deployments, 963,603 datasets; MapServer: 544
> deployments, 389,709 datasets), is QGIS Server something the grant
> program should be funding? There are three Server proposals totalling
> €10,000, 22% of the fund.
>
> Now, before you get the pitchforks out(!), please consider the following:
>
> * Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS
> Desktop. (The grants mostly aren't things that will improve the shared
> QGIS Core). (This reasoning also follows through to OSGeo funds).
>
> * Multiple solutions - Open Source (and OSGeo) already has a very
> healthy ecosystem of mapping servers - does it need another one?
>
> * Limited number of users benefited - I don't have stats for it, but
> QGIS Desktop is probably the most popular Open Source Desktop GIS, and
> is certainly going to have many orders of magnitude more users than QGIS
> Server.
>
> * Playing to your strengths - QGIS' strength is it's Desktop and it's
> generally good practice to play to your strengths.
>
>
> So given the above, and that QGIS is already "winning" as an Open Source
> Desktop (great job!), I'd like to suggest it's not a good idea to dilute
> the limited resources by spending them on QGIS Server. Instead it seems
> that far more people would benefit if that money was spent on Desktop,
> especially the bug fixing programme.
>
> Or alternatively, given the "Unique Selling Point" of QGIS Server is its
> integration with QGIS Desktop, those resources could be used to further
> improve interoperability with GeoServer/MapServer/deegree/etc. Those are
> all successful mature OSGeo projects that excel at serving maps, have an
> architecture designed for it, and already have huge install bases.
>
> TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should
> play to its strengths and focus its limited funds there to benefit the
> most users.
>
> I shall now retreat to my bunker. :-)
>
> Cheers,
> Jonathan
>
> Note: The above only applies to the Grant program and funding; how
> developers wish to spend their time, and on which projects is of course
> their own prerogative.
>
> (Disclosure: I have no horse in this race; I don't run or administer any
> mapping servers, but I have done GeoServer in the past.)
>
>
>
> ___
> 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: 

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Andreas Neumann]

Fully agreed with Richard here. 


OGC standards are important and even required by law. Other protocols
are ok though, if they are in addition. If they prove to better in the
future than OGC, then they might eventually replace the former. But
first, they would have to prove good interoperability and that they are
better. 

Regarding vector styles: 


I hadn't seen a complex, convincing vector style client-side rendering
yet. Mapbox and Maptiler come closest - but even these two are "mickey
mouse" maps compared to what national mapping agencies in our countries
established in quality over decades in their printed and raster map
product lines. 


In our country, Swisstopo (the national mapping provider) experimented
with vector tiles. The result: 


* it renders slower than the raster tile maps
* the CPU of the client is busier than with raster tiles
* the cartographic quality is disappointing. Many years away from the
original raster tile quality

The main advantage of vector tiles would be that the user could switch
colors - but did you ever have the need to switch colors in a we map?
Defacing a map where cartographers spent a lot of time figuring out the
correct color combos? 


Replicating QGIS rendering for vector tiles outside of QGIS in a totally
separate technology from qt rendering would be an interesting project,
but would always be different, lagging and would be a lot of effort. But
if someone finds a sponsor for that, it could be interesting. 

Andreas 


On 2020-06-09 08:24, Richard Duivenvoorde wrote:

On 6/9/20 1:18 AM, Nyall Dawson wrote: 


Something else to consider is whether technologies like WMS are
ultimately just "dead end" technologies now,


Definitely not agreeing here :-)


and possibly we'd be
better off focusing on client side rendering of vector features from a
server (QGIS or other), and providing a library which can do
client-side rendering of vector tiles from QGIS symbology in as close
to 1:1 as possible...


For full blown nice reference maps or aerials  WM(T)S is still the way
to go. For simpler reference maps like Google, vector tiles will be...

Building a QGIS rendering engine in a browser, will always be behind (IF
it will ever reach the same amount of features).

In my view the unique selling point of QGIS Desktop/Server combi is (or
should be) the ease to create beautiful maps easily on a desktop and
then publish them (including metadata) to a server/service...
Just like our commercial brother does with it's services.

And mind you: while not perfect WMS/WFS are real standards understood
and used by a lot of servers and clients.

Vector tiles are great (or at least promising), but I've not seen any
client-side cartographic rendering of them yet.

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] QGIS Server and the Grants programme

[Richard Duivenvoorde]

On 6/9/20 1:18 AM, Nyall Dawson wrote:
> Something else to consider is whether technologies like WMS are
> ultimately just "dead end" technologies now, 

Definitely not agreeing here :-)

> and possibly we'd be
> better off focusing on client side rendering of vector features from a
> server (QGIS or other), and providing a library which can do
> client-side rendering of vector tiles from QGIS symbology in as close
> to 1:1 as possible...

For full blown nice reference maps or aerials  WM(T)S is still the way
to go. For simpler reference maps like Google, vector tiles will be...

Building a QGIS rendering engine in a browser, will always be behind (IF
it will ever reach the same amount of features).

In my view the unique selling point of QGIS Desktop/Server combi is (or
should be) the ease to create beautiful maps easily on a desktop and
then publish them (including metadata) to a server/service...
Just like our commercial brother does with it's services.

And mind you: while not perfect WMS/WFS are real standards understood
and used by a lot of servers and clients.

Vector tiles are great (or at least promising), but I've not seen any
client-side cartographic rendering of them yet.

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] WCS 2.0 access in QGIS

[shiva reddy]

Hi,

I tried to add a WCS layer from a server which supports WCS 2.0 , but it
failed.

Any idea / plugin which can help me.

I tried the experimental plugin QgsWcsClient2 but it also could not load
the layer.


Thanks & Regards
Shiva Reddy K.
Scientist/Engineer 'SE’
Indian Institute of Remote Sensing,
Indian Space Research Organisation
Department of Space
4-Kalidas Road
Dehradun
mobile: 0135-2524126
___
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