This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Tyn- > >(this will also be the answer to the similar question you sent to > >support-thredds) > > Well, if Ethan & John have some thing on the IOSP side it would solve my > problem... ;-) The IOSP was being developed by NCDC and I have a query into them on the status. Last I knew, all images were upside down. I'll ping them again to see if I can get more info. > This file does not exist or has the wrong permissions. > > Can you try again, my stupidity... > > ftp://ftp.itc.nl/pub/venus/Venus-IDV/NETCDF0001.nc.zip No problem, thanks for the sample. > Here is the info dump from OPenDAP (aka Hyrax) for the same netCDF..... > > Variables in this Dataset > version: 32 bit Integer > long_name: "McIDAS area file version" > sensorID: 32 bit Integer > long_name: "McIDAS sensor number" > imageDate: 32 bit Integer > long_name: "image year and day of year" > units: "ccyyddd" > imageTime: 32 bit Integer > long_name: "image time in UTC" > units: "hhmmss UTC" > startLine: 32 bit Integer > long_name: "starting image line" > units: "satellite coordinates" > startElem: 32 bit Integer > long_name: "starting image element" > units: "satellite coordinates" > numLines: 32 bit Integer > long_name: "number of lines" > numElems: 32 bit Integer > long_name: "number of elements" > dataWidth: 32 bit Integer > long_name: "number of bytes per source data point" > units: "bytes/data point" > lineRes: 32 bit Integer > long_name: "resolution of each pixel in line direction" > units: "km" > elemRes: 32 bit Integer > long_name: "resolution of each pixel in element direction" > units: "km" > prefixSize: 32 bit Integer > long_name: "line prefix size" > units: "bytes" > crDate: 32 bit Integer > long_name: "image creation year and day of year" > units: "ccyyddd" > crTime: 32 bit Integer > long_name: "image creation time in UTC" > units: "hhmmss UTC" > bands: Array of 32 bit Integers [bands = 0..0] > long_name: "bands" > auditTrail: Array of Strings [auditCount = 0..0][auditSize = 0..79] > long_name: "audit trail" > data: Array of 32 bit Reals [bands = 0..0][lines = 0..499][elems = > 0..5415] > long_name: "data" > type: "MODS" > units: "unitless" > latitude: Array of 32 bit Reals [lines = 0..499][elems = 0..5415] > long_name: "latitude" > units: "degrees" > longitude: Array of 32 bit Reals [lines = 0..499][elems = 0..5415] > long_name: "longitude" > units: "degrees" > > > > for THREDDS to be happy? > > Reading the AREAs from disk works fine, it's just that here at the National > Meteorological Institute in Mongolia they wanna serve this stuff to other > governmental organizations with some metadata, hence my hopes for a catalog. > That's why I was hoping the TDS would swallow AREAs... The problem is that the time is a separate variable and it would be a pain to munge this I think. > How are you btw & Jeff btw? Busy as bees. ;-) Trying to shore up the 2.6 release in the next month or so. Hope you are doing well. Don Ticket Details =================== Ticket ID: NUK-817580 Department: Support IDV Priority: Normal Status: Open