Hi Rob,
Rob Cermak wrote:
> 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.
That is a Firefox issue. It doesn't show any content if the response
code is 400. It actually acts as though no request has been issued. Very
strange.
> 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.
A 200 response code for a service exception seems a bit confusing to me.
It makes server logs a bit deceptive and it means the client has to read
the response body and try to interpret it before it can know if there
was a problem with the request ... before it hands it to a netCDF or
GeoTIFF (or whatever) reader.
Do you have a WCS client that doesn't like the 400 response code?
>
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 :)
We're looking into this.
> 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.
Yeah, we'll probably tighten this up a bit.
> I will probably provide more comments as we test more and do some more
> testing with ESRI ArcMap and other clients.
Great!
> 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:
I'm going to leave the rest to the folks that know the WMS side of
things better than I.
Thanks for your comments.
Ethan
> 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
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
