Hi Michael,
When I wrote this I just followed the spec which only offered the
coverages XML or the multipart mime as the response format. It differed
from 1.0 in that respect.
However I tend to agree that just returning the file object is a option.
I think we should maintain the current functionality, but we could add
an extra argument to the getCoverage request e.g. 'dataOnly = True'
However the 'store' parameter should probably still take precedence so
you can only get the raw data if 'store=False' AND 'dataOnly = True'
I'm not likely to spend much time on this at the moment so if you'd like
to contribute a patch for this and other fixes you would be more than
welcome.
Cheers,
Dominic
On 03/03/11 08:54, [email protected] wrote:
Hi,
what do you think how the getCoverage for WCS 1.1.x request should
work? I see the commented method getData and the question is, whether
getCoverage should return the actual coverage data or whether it
should return the path to the downloaded and unpacked data?
If store is set to true then it makes sense to directly return the
coverage xml file, if store is false rather than downloading the data
and storing it locally just to return a filename I'd prefer to return
the coverage data directly.
Any feedback appreciated.
Michael
2011/3/2 Michael Schulz<[email protected]>:
Hi,
ok this little trick works ... ugly though:
wcsdecoder.py#75:
msg = email.message_from_string(self.u.info()+self.mpartmime)
It prepends the original header to the body and then it is recognized
as a multipart messages and the tiff is extracted correctly to the
unpacked dir ...
Cheers, Michael
2011/3/2 Michael Schulz<[email protected]>:
Hi Dominic,
I think the problem is somwhere else... when the getCoverage URL is
opened by urllib2 then the headers are stored in the info object. But
they are not present anymore in the result of the read() method, thus
the response is not considered as a multipart message...
Cheers, Michael
2011/3/2 Dominic Lowe<[email protected]>:
Hi Michael,
I don't think this has been widely used (not many server implementations).
The test for whether it's a multipart mime or not is pretty feeble. Maybe
this is the problem?:
http://trac.gispython.org/lab/browser/OWSLib/trunk/owslib/coverage/wcsdecoder.py#L27
Cheers,
Dominic
On 02/03/11 16:27, [email protected] wrote:
Dear owslib-users,
wonder how the reading of coverage data from WCS 1.1.0/1.1.1 providers
is working? I get the results from the WCS in the multipart mime
format,or at least I think I do ;-)
When issuing the getCoverage URL in the browser, the xml section is
displayed and the tif is offered for download. When trying the same in
python/owslib, the getCoverage result is not recognized as a multipart
file and so the result as a whole is saved by the wcsdecoder. That's
(some of) the content of the saved file:
---------
--_boundary_gks93dbq
MIME-Version: 1.0
Content-type: text/xml
Content-ID: urn:ogc:wcs:1.1:coverages
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<owcs:Coverages xmlns:ows="http://www.opengis.net/ows";
xmlns:owcs="http://www.opengis.net/wcs/1.1/ows";
xmlns:xlink="http://www.w3.org/1999/xlink";
xmlns="http://www.opengis.net/wcs/1.1";
xmlns:gml="http://www.opengis.net/gml";
xmlns:smil20="http://www.w3.org/2001/SMIL20/";
xmlns:smil20lan="http://www.w3.org/2001/SMIL20/Language";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.opengis.net/wcs/1.1/ows
http://schemas.opengis.net/wcs/1.1.0/owcsAll.xsd
http://www.opengis.net/wcs/1.1
http://schemas.opengis.net/wcs/1.1.0/wcsAll.xsd";>
<owcs:Coverage>
<owcs:Identifier>wc_30s_tmax_12</owcs:Identifier>
<owcs:Reference xsi:type="owcs:AbstractReferenceBaseType"
xlink:arcrole="urn:ogc:def:role:WCS:1.1:coverage"
xlink:href="cid:wc_30s_tmax_12.bil"/>
</owcs:Coverage>
</owcs:Coverages>
--_boundary_gks93dbq
MIME-Version: 1.0
Content-type: image/tiff
Content-ID: wc_30s_tmax_12.bil
[...]
------------------
It looks like a multipart file, but I thought there should be a
header, but it is not there. When inspecting the whole thing it
returns text/plain as the contentType... Hmm, anyone succeeded in
using the wcsdecoder?
Thanks, Michael
--
Scanned by iCritical.
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
--
-----------------------------------------------------------
Michael Schulz
[email protected]
--
-----------------------------------------------------------
Michael Schulz
[email protected]
--
Scanned by iCritical.
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
