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.
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.
Hi Kyle: On 11/28/2012 3:07 PM, Kyle Wilcox wrote:
I've finally had time to test this out New-style featureCollection FMRC: http://64.9.200.113:8080/thredds/catalog/LakeErieSST-FMRC/catalog.html Old-style joinExisting Agg: http://64.9.200.113:8080/thredds/aoc.html?dataset=LakeErieSST-Agg The TDS catalog entries: https://gist.github.com/4164765 The NetCDF files are one satellite pass per file. The time dimension is unlimited with a length of 1 in the individual files. The time units are seconds since epoch (all even seconds). The joinExisting Agg works as expected just like in 4.2. All of the services (including WMS) work.
ok
> Data is no longer on even seconds in the FMRC. Agg: http://64.9.200.113:8080/thredds/dodsC/LakeErieSST-Agg.ascii?time[0:1:132] VS. FMRC: http://64.9.200.113:8080/thredds/dodsC/LakeErieSST-FMRC/LakeErieSST-FMRC_best.ncd.ascii?time[0:1:132]The featureCollection FMRC doesn't work quite as well, but I do get a valid dataset. * There are rounding issues when converting the original files' "seconds since 1970-01-01 00:00:00" to the FMRC's "hours since 2012-03-11T08:00:00.000Z".
for "Best" im seeing these time coordinates: 2012-03-11T08:00:00Z 2012-03-14T06:55:00Z 2012-03-17T07:25:00Z 2012-03-18T08:05:00Z 2012-03-18T08:10:00Z 2012-03-20T07:55:00Z 2012-03-22T07:40:00Z 2012-03-23T06:45:00Z 2012-03-26T07:20:00Z 2012-03-27T08:00:00Z 2012-05-03T08:20:00Z 2012-05-06T07:15:00Z 2012-05-10T08:25:00Z 2012-05-11T07:30:00Z 2012-05-14T08:00:00Z 2012-05-15T08:45:00Z 2012-05-17T08:30:00Z 2012-05-18T07:35:00Z 2012-05-18T07:40:00Z 2012-05-19T08:20:00Z 2012-05-20T07:25:00Z 2012-05-23T07:55:00Z 2012-05-24T07:00:00Z 2012-05-25T07:45:00Z 2012-05-26T08:25:00Z 2012-05-27T07:30:00Z 2012-05-28T08:15:00Z 2012-05-30T08:00:00Z 2012-10-01T06:45:00Z 2012-10-01T06:50:00Z 2012-10-08T06:55:00Z 2012-10-19T08:15:00Z 2012-10-21T08:00:00Z 2012-10-22T07:05:00Z these seem to match the original files.
* The datasets has a "time_run" variable even though there are no "runs". I can't remove the "time_run" variable from the resulting dataset using the protoDataset tag. * The "coordinates" attribute of the "sst" variable gets set to "time_run time lon lat". I don't want 'time_run' to be part of the coordinates. I can't change the attribute using the protoDataset tag.
yes, its an artifact of using FMRC. Ideally its harmless. We will look at the WMS problem.
* The "File_Access" link takes me to a directory listing that doesn't apply the regex of the collection. It lists all of the files in the directory rather than just the .nc4 files: http://64.9.200.113:8080/thredds/catalog/LakeErieSST-FMRC/files/catalog.html.
we will fix this
* The WMS service does not work (it is a known issues with ncWMS and FMRC datasets... it does not handle the run dimension correctly).
we are looking at the WMS problem
Is a possible solution to create another option in the fmrcConfig's datasetTypes attribute to remove all concept of a "run" from the dataset? This will be useful for gridded files with no overlapping time. <fmrcConfig datasetTypes="NoRunsPlzKThnx Files" /> Another solution could be to remove the concept of a "run" from a FMRC dataset if the calculated time_offset variable is filled with all zeros. Thoughts?
What we need is a featureCollection type=GRIB for your case. I will think if we can add it quickly.
John
thredds archives: