[Qgis-developer] WCS and Raster improvements for QGIS

[Radim Blazek]

On Thu, Jul 12, 2012 at 5:15 PM, Marco Hugentobler
<marco.hugentobler at sourcepole.ch> wrote:
> Hi
>
> In my opinion, it is better to use the Qt classes for the network requests
> than curl. In QGIS, we have QgsNetworkAccessManager, which picks up
> automatically the network settings from the options tab (proxy settings,
> exclusion list, password, disk cache). It has nice progress reporting by
> signal/slot, the possibility to interrupt the network request and a disk
> cache. And the possibility to provide custom implementations for all that if
> necessary.
>
> Like this, WFS, WPS, WMS providers, plugin installer and open layers plugin
> (and third party python plugins) have a unified method to do network
> requests. No need to use a different network library for each one (and the
> mapping is never 1:1, there is always loss).
>
> So while it might be quicker (in terms of development time) to use the GDAL
> provider, a standalone provider is always more native and flexible (that's
> also the reason there are QGIS vector providers for postgres, wfs, gpx,
> spatialite, grass while everything can be read with the OGR provider).

Marco explained the situation better than I could do. I can only add that:
- reading data with GetCoverage is only one part (about 50%) of the
provider, there is a lot of things around, which we have to do in QGIS
anyway - get list of coverages, describe coverages, GUI select etc.
- even with native (or more native) WCS provider, we are still using
GDAL to decode downloaded data
- (I know that OS people don't like to here it and  they will argue
that is is not a way ahead.) WCS is not widespread yet and there are
various issues with implementation in UMN Mapserver (and other
servers) and GDAL. Combination of that issues made it for example
impossible to support WCS 1.1 in QGIS via GDAL WCS provider. In QGIS
we can use various hacks to get over various issues with servers, for
example axis switching etc. which would not be accepted in GDAL. Then
there is a question of time, if you look at deployment on Linux, it
takes months or years to get fixed package into a distribution. In
last two days, I found for example new issues with both UMN Mapserver
and GDAL which we can get around in QGIS, but we would need to wait
years until fixed versions get to distributions.
- we are using GDAL/OGR heavily where possible.
- question/suggestion, GDAL i using CPLHTTPFetch() to get data from
server, would it be possible to add a possibility to set user function
to be used instead of default CPLHTTPFetch()? Something like
SetHTTPFetchFunction( myHTTPFetch ). That would make it possible to
use GDAL providers with QgsNetworkAccessManager for example.

Radim

> Regards,
> Marco
>
> Am 12.07.2012 15:51, schrieb Even Rouault:
>
>>> Yes - Radim already made a first pass implementation using GDAL WCS
>>> though he said there were some problems with it - I think the most
>>> critical being that it doesn't support proxy access (I am speaking
>>> under correction here as I haven't looked into it in that much detail
>>> myself).
>>
>> This should be rather easy to add. It is just a matter of setting the
>> right
>> option to CPLHTTPFetch() (and thus the curl library), namely :
>>
>> <li>PROXY=val, to make requests go through a proxy server, where val is of
>> the
>>      form proxy.server.com:port_number
>> <li>PROXYUSERPWD=val, where val is of the form username:password
>>
>> Note: They can also already be used by setting the GDAL_HTTP_PROXY and
>> GDAL_HTTP_PROXYUSERPWD configuration options/environmenet variable, which
>> will
>> act on all GDAL/OGR drivers that go through the CPLHTTPFetch() function.
>>
>> I see Radim is already a GDAL committer, so there shouldn't be too much
>> overhead
>> if he wants to hack in the WCS driver.
>>
>>> I will let Radim comment on any other issues. I think from
>>> the project perspective we don't mind too much which approach is used
>>> if the result is efficient and integrates nicely into QGIS.
>>>
>>> Regards
>>>
>>> Tim
>>>
>>>
>>>
>>> --
>>> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
>>> ==============================================
>>> Please do not email me off-list with technical
>>> support questions. Using the lists will gain
>>> more exposure for your issues and the knowledge
>>> surrounding your issue will be shared with all.
>>>
>>> Visit http://linfiniti.com to find out about:
>>>   * QGIS programming and support services
>>>   * Mapserver and PostGIS based hosting plans
>>>   * FOSS Consulting Services
>>> Skype: timlinux
>>> Irc: timlinux on #qgis at freenode.net
>>> ==============================================
>>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer