Re: [thredds] followup on web services responses (Version 4.0.06 - 20090312.1846); additional comments

• Subject: Re: [thredds] followup on web services responses (Version 4.0.06 - 20090312.1846); additional comments
• From: Pauline Mak <Pauline.Mak@xxxxxxxxxxx>
• Date: Mon, 16 Mar 2009 14:38:17 +1100

Hi Rob,

Thanks for your comments :)  Good to know someone is out there testing
it out!

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.

Yeap that makes sense.  I'll also put in something that will check for
valid REQUEST values (invalid REQUEST value gives am empty page).  This
can be corrected easily :)

Speaking of clients, which ones are you using aside from ArcMap?
Finding a function WMS client is frustrating to say the least...

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).

Indeed :)  This is one of the drive to integrate nwWMS with TDS - it's
easier to configure, and avoids the massive GetCapabilities response.
You can also configure WMS services for aggregated NcML datasets too,
that can reduce the number of end points even further (provided your
datasets can be aggregated and this also adds an extra load to the server)

Additional comments:

For WMS:

Is there work being done to allow query of features through WMS?

Do you mean the GetFeatureInfo request?  It's supported at the moment,
although, I'm not entire sure what it does.  Jon?

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>

The colour range is only a guess - it takes a sampling of the data
values and hopes that the min/max falls within the sampled box.  So
there are cases where the scaling is incorrect.  In a perfect world, it
would be really nice if the metadata included with files always comes
with a min/max value...

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

I'll have to have a good look at SLDs...  Sorry, can't comment about it
right now!

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

_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe,  visit:

http://www.unidata.ucar.edu/mailing_lists/

--
Pauline Mak

ARCS
Ph: (03) 6226 7518
Email: pauline.mak@xxxxxxxxxxx
Jabber: pauline.mak@xxxxxxxxxxx
http://www.arcs.org.au/

TPAC
Email: pauline.mak@xxxxxxxxxxx
http://www.tpac.org.au/

• References:
  • [thredds] followup on web services responses (Version 4.0.06 - 20090312.1846); additional comments
    • From: Rob Cermak