NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
thredds
archives: