Emmanuel Séguin ha scritto:
Hi,
I've tried using the WCS version 1.1.0 in Geoserver 1.7.3 with the sample
data provided. I'm interested in the ArcGrid output format of this WCS
version so i've tried the following GET request :
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&identifier=nurc:Pk50095&version=1.1.0&format=ArcGrid&BoundingBox=347649.93086859107,5176214.082539256,370725.976428591,5196961.352859256,EPSG:32633
1) The response encoding results in Firefox wanting to download the request
result as an EML file :teeth:
Welcome to the wonderful world of WCS 1.1.1, where you don't
return a raw coverage by default, but a MIME Multipart message
(just like an e-mail with attachments) comprising a xml metadata
document and the actual coverage as an attachment to it.
From the specification, page 51 (the store parameter, that you did
not specify, has a default value of "false"):
-----------------------------------------------------------------
If the “store” parameter has the value “true”, the server shall store the result file(s) at URLaddressable
location(s) of its choosing, and return only the Coverages data structure (within a
SOAP envelope in the case of a SOAP request) with references to the other files as indicated
in 10.3.11.2 and 10.3.11.4 below.
When the “store” parameter is absent or has the value “false”, the server shall transfer the
complete GetCoverage response to the client, either as a MIME multipart message (for KVP
or XML requests) or as a SOAP message with attachments (for SOAP requests). The
Coverages shall reference the other parts of the MIME multi-part message (or SOAP
attachments) as indicated in 10.3.11.3 below.
-------------------------------------------------------------------
So, to factor out the arcgrid issue itself, if you make this request,
asking for store=true and geotiff output:
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&identifier=nurc:Pk50095&version=1.1.0&format=geotiff&BoundingBox=347649.93086859107,5176214.082539256,370725.976428591,5196961.352859256,EPSG:32633&store=true
you'll get back an XML document like:
<wcs:Coverages xsi:schemaLocation="http://www.opengis.net/wcs/1.1.1 http://localhost:8080/geoserver/schemas/wcs/1.1.1/wcsCoverages.xsd">
<wcs:Coverage>
<ows:Title>Sample scanned and georerenced map</ows:Title>
<ows:Abstract>
This is a sample for the world image format (wld + prj + tiff)
</ows:Abstract>
<ows:Identifier>nurc:Pk50095</ows:Identifier>
<ows:Reference xlink:href="http://localhost:8080/geoserver/temp/wcs/nurc_Pk50095_1822821376240.tiff"/>
</wcs:Coverage>
</wcs:Coverages>
And theoretically from there you should be able to download the tiff,
but that is not happening... it seems the file published has been
un-hooked from that position. (the files are actually in the GeoServer
data directory, see $GEOSERVER_DATA_DIR\temp\wcs).
I have to look into it, opened this jira issue:
http://jira.codehaus.org/browse/GEOS-2790
2) The request doesn't work => "Problems Rendering Imagenull nul"
I've also tried with the samples POST requests of Geoserver. Neither 1.0.0
nor 1.1.0 works with the ARCGRID format.
The GET request in version 1.0.0 doesn't work either.
Hmmm... yeah, I see there is a problem there too.
I don't have ArcGrid related tests because the format has been pretty
much impossible to use in WCS. ArcGrid has this assumption that the pixels are square, but making a request that results in perfectly square
pixels is hard. Yet, if the pixels are not square, the ArcGrid writer
will complain about that and won't generate the output.
I believe that if one allowed the pixels to be non square the resulting
grid would be stretched, because the information in the header
just reports one of the corners and the pixel size, and the
readers of it will assume the pixel is square anyways
That said, the problem you're seeing is of different nature, the
writer is failing while trying to report the NULL value
(which, in the case of that coverage, is not there).
Reported here:
http://jira.codehaus.org/browse/GEOS-2791
If you play more with WCS let us know about your findings, it is not
widely used and there are basically no working clients out there, so
it's hard to make any real world testing of it.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
?
It has been filed with Jira.