Closed nmtoken closed 8 years ago
eox-cs1
commented
9 years ago Hey,
could you please provide me with some more details on your requests. You may open the python console in QGIS, there you will get the request printed. That's probably easier then a lot of screenshots. ciao
nmtoken
commented
9 years ago The service URLs are as above links.
Debugging this a little further I see that when I request a Tiff as below, then the coverage does plot in the correct location
However when I request an image/png format the resultant image is not correctly located.
and
Comparing this to the inbuilt QGIS WCS tool, I see that for the MapServer service I can only select GTiff (though the GetCapabilities response shows more formats!). For the GeoServer service, I can select other formats such as png, and when I do so the coverage displays in the correct location.
I get the same behaviour with jpeg, that is when called in the QGIS tool displays in the correct location but when called though the plugin doesn't.
eox-cs1
commented
9 years ago Hi nmtoken, Well now I see. Let me first go into greater detail to provide some more context. WCS is a "download-service" intended to get your hands on to the real data (in whatever data type e.g. 16-bit/float, the data is in). WMS, on the other hand, is a "viewing-service" it just presents you with a view on the data, hence PNG and JPEG is OK here. For WCS these formats are not really an option, since these format will change the actual datasets. In addition they both do not provide any Geographic information (like Projection, Datum, etc.). That is also the reason why the QgsWcsClient2 handles GTIF correctly but not PNG/JPEG, since it simply doesn't know where to place it. How the QGIS internal WCS is handling this, I don't know and I can only guess (either taken from the request, or as an WMS, see also below).
The QGIS internal WCS looks to me as it actually acts more like a WMS then a WCS. The intention here seems to FIRST VIEW and THEN STORE (manually) - the QgsWcsClient2 plugin, on the other hand, acts the other way around; FIRST STORE and THEN VIEW, with the basic idea behind that the original data is manipulated as little as possible (beside reprojection/scaling, etc.). The QGIS internal WCS also is permanently reloading the dataset (like the WFS does too) which might get a problem for large datasets or networks with low bandwidth; the QgsWcsClient2 only download the requested coverage (=>file) once and then acts locally when viewing.
So there are differences (philosophical?) which result in the different behaviour (beside the possibilities introduced by the two OGC WCS standards). ciao
nmtoken
commented
9 years ago Hi,
Absolutely understand the fundamental differences between download and view services, but though the aim of the WCS is to provide, if required, the raw data it is also allowed to provide some representation of it, such as an image whether that be in GTiff or png etc. With web based clients such as the Cryospheric Data Service developed by EOX as part of the EarthServer project for example, png images were used in the client I believe. Obviously QGIS is not a web client and we don't have to rely on images that will display in browsers.
I did wonder whether you needed the server to provide world file information either embedded or separate, and I guess this answers that question.
What other formats are supported, NetCDF, ascii grid?
Thanks
eox-cs1
commented
9 years ago The webclient in EarthServer/Cryospheric service (and in others too eg. CryoLand.eu) uses a WMS or WMTS to view the data in the Browser. But when the WCS is used (downloading) PNG/JPEG doesn't make sense. Formats supported are defined by the WCS-Server offering the data. In any case a "geo-aware" download format is recommended. The QgsWcsClient2 plugin will try to display the downloaded data it inside QGIS or create an error message. So I guess (haven't tested this in depth) that all QGIS formats should work for display. Some formats migh be tricky though (HDF, netCDF) since they may contain a lot of data sets in various forms (at least unless they are not pre-defined like EOS-HDF or CF-netCDF) ciao
nmtoken
commented
9 years ago Not all the EarthServer clients used WMS/WMTS, some used WCPS output in png format, for example for the model viewers, but yes I agree (and apologies) png output from a pure WCS is less useful.
eox-cs1
commented
9 years ago Oh, yeah, there was WCPS, too. But that's another story.....
I've tried to display some EMODnet bathymetry data in QGIS, using two WCS services, that is:
MapServer
and
GeoServer
The services are on the same server and use the same data, which is natively in EPSG:4326 projection.
When loading the coverages, choosing output CRS as EPSG:4326 (and the default original subsetting).
The coverages appear but are NOT in the correct location. In the screen shot below, the little blue rectangle in the top left corner is a blue marble mosaic (served by WMS), and displaying in the correct geographic location.
Choosing the CRS: / EPSG. No.: 4326 subsetting option doesn't change the effect, though I'm not sure if this should make any difference because I am requesting a full coverage and not any subset.
Using the inbuilt WCS QGIS tool on the same services the coverages load in the correct location as below image: