Ethan,
Thanks for the reply.
For:
http://localhost:8080/thredds/wcs/testAll/2004050300_eta_211.nc?request=GetCoverage&version=9.0.0&service=WCS&format=GeoTIFF&coverage=Z_sfc&bbox=-134,11,-47,57";
In Firefox 3.0.7, nothing is returned in the browser... might be a
browser issue. Curl shows the right stuff coming back:
curl -i
"http://localhost:8080/thredds/wcs/testAll/2004050300_eta_211.nc?request=GetCoverage&version=9.0.0&service=WCS&format=GeoTIFF&coverage=Z_sfc&bbox=-134,11,-47,57";
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Content-Type: application/vnd.ogc.se_xml
Transfer-Encoding: chunked
Date: Sat, 14 Mar 2009 23:35:35 GMT
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<ServiceExceptionReport xmlns="http://www.opengis.net/ogc"; version="1.2.0">
<ServiceException code="InvalidParameterValue"
locator="Version">Invaled "Version" parameter value
[9.0.0].</ServiceException>
</ServiceExceptionReport>
I need to test stuff a bit more carefully. This likely points to FF
doing the wrong thing.
With a 200 OK HTTP response and XML service exception is what I and
clients likely expect.
http://localhost:8080/thredds/wms/testAll/2004050300_eta_211.nc?service=WMS&version=4.3.0&request=GetCapabilities
This still generates a 404 error. I'd expect 200 OK HTTP and a service
exception report. As you said, this might be a future fix yet to make it
out the door :)
For:
http://localhost:8080/thredds/wms/testAll/2004050300_eta_211.nc?service=YES&version=1.3.0&request=GetMap&layers=Z_sfc&crs=EPSG:4326&bbox=-135,19,-31,60&width=600&height=400&styles=&format=image%2Fpng
As I think about this, this is a whole can of worms. I think for
consistency, I would really sanitize the service request and return a
service exception error if "thredds/wms" (or whatever path is used) is
not paired with service=WMS and likewise for WCS and future OGC services.
I will probably provide more comments as we test more and do some more
testing with ESRI ArcMap and other clients.
The way WMS and WCS is deployed, each data container is its own service
end point. Typical WMS and WCS server endpoints are monolithic (hard to
deploy large amounts of data due to lack of LAYER namespace).
Additional comments:
For WMS:
Is there work being done to allow query of features through WMS?
Is there a way to specify a remote SLD for styling? The existing
palettes are open ended just looking at min/max per dataset?
<Style>
<Name>BOXFILL/rainbow</Name>
<Title>BOXFILL/rainbow</Title>
<Abstract>BOXFILL style, using the rainbow palette</Abstract>
<LegendURL width="110" height="264">
<Format>image/png</Format>
<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/thredds/wms/testAll/2004050300_eta_211.nc?REQUEST=GetLegendGraphic&LAYER=Z_sfc&PALETTE=rainbow"/>
</LegendURL>
</Style>
We've abused the SLD standard a slight bit.
<StyledLayerDescriptor version="1.0.0">
<NamedLayer>
<Name>atmp</Name>
<units_primary>degC</units_primary>
<units_secondary>degF</units_secondary>
<UserStyle>
<Title>xxx</Title>
<FeatureTypeStyle>
<Rule>
<RasterSymbolizer>
<Opacity>0.80</Opacity>
<ColorMap>
<ColorMapEntry color="#0000ff" quantity="-80"/>
<ColorMapEntry color="#0000ff" quantity="-40"/>
<ColorMapEntry color="#4141ff" quantity="-32"/>
<ColorMapEntry color="#5f5fff" quantity="-28"/>
<ColorMapEntry color="#7878ff" quantity="-24"/>
<ColorMapEntry color="#9191ff" quantity="-20"/>
<ColorMapEntry color="#a5a5ff" quantity="-16"/>
<ColorMapEntry color="#b9b9ff" quantity="-12"/>
<ColorMapEntry color="#cdcdff" quantity="-8"/>
<ColorMapEntry color="#e1e1ff" quantity="-4"/>
<ColorMapEntry color="#f5f5ff" quantity="0"/>
<ColorMapEntry color="#ffeaea" quantity="2.8"/>
<ColorMapEntry color="#ffd4d4" quantity="5.6"/>
<ColorMapEntry color="#ffbfbf" quantity="8.4"/>
<ColorMapEntry color="#ff9d9d" quantity="11.2"/>
<ColorMapEntry color="#ffaaaa" quantity="14"/>
<ColorMapEntry color="#ff9595" quantity="16.8"/>
<ColorMapEntry color="#ff7f7f" quantity="19.6"/>
<ColorMapEntry color="#ff6a6a" quantity="22.4"/>
<ColorMapEntry color="#ff5555" quantity="25.2"/>
<ColorMapEntry color="#ff4040" quantity="28"/>
<ColorMapEntry color="#ff1515" quantity="30.8"/>
<ColorMapEntry color="#ff0000" quantity="40"/>
</ColorMap>
</RasterSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>
If you use udunits and specify the units for quantity, then if the data
behind the scenes adequately defines units (CF standard) then these
quantities can be adjusted on the fly with a unit conversion as the
secondary units. As well as quantities adjusted by slope and offset
information (packed data):
scale_factor: -0.004828610923
add_offset: 158.2215118
http://ak.aoos.org/cgi-bin/sldcb_ws.py?sld=/space/gis/config/atmp_sld.xml&units_primary=degC&units_secondary=degF
In this SLD the primary units are in degC. We can override the scale and
make the primary scale degK and the secondary scale degF. The
declaration of units is non-standard... though quite useful.
http://ak.aoos.org/cgi-bin/sldcb_ws.py?sld=/space/gis/config/atmp_sld.xml&units_primary=degK&units_secondary=degF
This would allow application of a consistent colorbar to datasets.
This is great stuff. No real showstopper stuff, just some general
comments on what could be improved. Look forward to the official 4.0
release.
Rob
