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]
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community

Reply via email to