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
