thanks for the info. we'll have the fix in 4.0.14, thanks to nathan
potter at opendap.
we will switch to using the ddx also when we can, because of the easier
parsing.
sounds like you are doing great stuff too!
Rob Cermak wrote:
BTW, what do you use the DDX for? We have ignored his problem because we
use DDS/DAS instead.
The nutshell answer is it is XML based and a consolidated summary of both
the DDS and DAS responses. Saves us from hitting the server twice for
metadata. Parsing XML is far easier.
What we use the DDX for is trapping variable attributes and global
attributes using whatever CF standards we can find and apply to do some
things on the server side for clients.
1. Looking for scale and offset metadata and scaling SLD prior to
display of WMS layers.
2. Provision of data and units to the user as expected. If the data is
stored in degC and the user wanted degF, there are some operations we can
do on the server side with UDUNITS.
3. For data downloads, we actually provide a copy of the XML for users
as metadata instead of the DDS/DAS response. One of the attributes is a
pointer to a larger FGDC metadata record.
That is just a few things that we do with it. I think we had started to
use just DAS or DDS and then found out we really needed both.
TDS4 has amazing capabilities compared to a year or so ago. By repairing
the DDX or adding a ncML response, we can join the rest of the IOOS
regions spinning up TDS servers and plug the TDS into existing
infrastructure.
Thanks for all the hard work! Good luck on the upcoming release.
Rob
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
