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.
THREDDS folks, This sneaky workaround suggested by Kyle works, allowing us to get the WMS working from our collection-style FMRC. Here's proof: http://screencast.com/t/XwbxrYaC4N But creating duplicate datasets in NcML around every FMRC to remove the dang "time_run" variable in the attributes of every varaible is pretty annoying! -Rich On Wed, Nov 28, 2012 at 5:28 PM, Kyle Wilcox <KWilcox@xxxxxxxxxxxxxx> wrote: > If you create another TDS dataset and use NcML to point at the FMRC OPeNDAP, > you could change the coordinates attribute and remove the "time_run" variable > that way. > > >> -----Original Message----- >> From: Signell, Richard [mailto:rsignell@xxxxxxxx] >> Sent: Wednesday, November 28, 2012 5:19 PM >> To: Kyle Wilcox >> Cc: John Caron; Charlton Galvarino (2Creek); thredds@xxxxxxxxxxxxxxxx; >> Brandy Armstrong >> Subject: Re: [thredds] Scan Aggregation vs. Feature Collection >> >> Kyle, >> Thanks for posting this to the THREDDS list. Just today a colleague >> finalizing her poster for AGU asked me why the WMS command that used to >> work (in the pre-collection days) for her FMRC no longer works. >> >> I had no idea, and spent an hour trying to figure it out before >> giving up. I guess that "time_run" variable is the culprit. Didn't >> know "new style FMRC" + WMS was a "known" problem. Hope it gets >> fixed soon. >> >> -Rich >> >> On Wed, Nov 28, 2012 at 5:07 PM, Kyle Wilcox <KWilcox@xxxxxxxxxxxxxx> >> 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. >> > >> > 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". 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 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. >> > * 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. >> > * The WMS service does not work (it is a known issues with ncWMS and >> FMRC datasets... it does not handle the run dimension correctly). >> > >> > 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? >> > >> > >> > >> >> -----Original Message----- >> >> From: John Caron [mailto:caron@xxxxxxxxxxxxxxxx] >> >> Sent: Friday, October 26, 2012 7:48 PM >> >> To: Kyle Wilcox >> >> Cc: Roy Mendelssohn; thredds@xxxxxxxxxxxxxxxx; Charlton Galvarino >> >> (2Creek) >> >> Subject: Re: [thredds] Scan Aggregation vs. Feature Collection >> >> >> >> Hi Kyle: >> >> >> >> For GRID data aggregations, If they are GRIB format, use Feature >> >> Collection, type=GRIB. Otherwise use type=FMRC, even if theres only >> >> one runtime. Let us know any problems. >> >> >> >> John >> >> >> >> On 10/3/2012 10:09 AM, Kyle Wilcox wrote: >> >> > Hi John - >> >> > >> >> > Just trying to clarify a few things when testing 4.3: >> >> > >> >> > If we have a homogenous set of non-forecast GRID FeatureTypes >> >> > (satellite), >> >> we should still use an 'old-style' NcML aggregation because there is >> >> no GRID FeatureCollection. >> >> > >> >> > If we have a heterogeneous set of non-forecast GRID FeatureTypes >> >> > (satellite >> >> passes on slightly different grids), there is currently no way to >> >> aggregate them in 4.3 because there is no GRID FeatureCollection. >> >> > >> >> > Thanks , >> >> > Kyle >> >> > >> >> >> -----Original Message----- >> >> >> From: thredds-bounces@xxxxxxxxxxxxxxxx [mailto:thredds- >> >> >> bounces@xxxxxxxxxxxxxxxx] On Behalf Of John Caron >> >> >> Sent: Monday, July 23, 2012 5:50 PM >> >> >> To: Roy Mendelssohn >> >> >> Cc: thredds@xxxxxxxxxxxxxxxx >> >> >> Subject: Re: [thredds] Scan Aggregation vs. Feature Collection >> >> >> >> >> >> Well, its complicated. >> >> >> >> >> >> Old style aggregations, aka "NcML aggegations" remain supported. I >> >> >> think of these as low level index manipulations. These are >> >> >> embedded in NcML, either on the client or in TDS config catalog, see: >> >> >> >> >> >> http://www.unidata.ucar.edu/projects/THREDDS/tech/tds4.3/tutorial/ >> >> >> NcM >> >> >> L.ht >> >> >> m >> >> >> >> >> >> We can do much better when we know the "feature type", and the new >> >> >> way is called "feature collections": >> >> >> >> >> >> 1) type=FMRC is for gridded data. Works mostly of in 4.2, but >> >> >> refactored in 4.2 and still testing. >> >> >> 2) type=GRIB is for GRIB data, which is a special kind of gridded data. >> >> >> This supersedes FMRC when the data is in GRIB. Only in 4.3, ready >> >> >> for beta test. >> >> >> 3) type=point are for point feature types. Still in alpha in 4.3 >> >> >> >> >> >> NcML works fins when you know what you are doing and you have >> >> >> homogenous files. feature collections are intededd to be easier to >> >> >> use and tolerate heterogeneous files. >> >> >> >> >> >> John >> >> >> >> >> >> >> >> >> On 7/23/2012 3:27 PM, Roy Mendelssohn wrote: >> >> >>> But is this just for FMRC aggregation, or for all aggregations? >> >> >>> I could swear I >> >> >> remember a web age with feature collections that "grid" was a >> >> >> feature type, but when I looked the other day, it was point, >> >> >> station and grib I >> >> believe. >> >> >> Maybe it was my old age and bad vision seeing "grid" for "grib". >> >> >> If there is an aggregation for featureType=grid, can you point me >> >> >> to the page that describes this. >> >> >>> >> >> >>> We do not have any FMRC aggregations, but if there all of our >> >> >>> aggregations >> >> >> should be feature collections, then I have a lot of editing to do >> >> >> on our xml files. >> >> >>> >> >> >>> Thanks, >> >> >>> >> >> >>> -Roy >> >> >>> >> >> >>> On Jul 23, 2012, at 1:59 PM, John Caron wrote: >> >> >>> >> >> >>>> On 7/19/2012 11:50 AM, Roy Mendelssohn wrote: >> >> >>>>> Hi All: >> >> >>>>> >> >> >>>>> I have asked this before and am not certain that I ever got a >> response. >> >> >> For TDS 3.0 is it correct to assume that scan aggregation is >> >> >> deprecated and we should be using feature collections for >> >> >> aggregation >> >> instead? >> >> >>>> Hi Roy: >> >> >>>> >> >> >>>> Yes correct, though we are still debugging the FMRCs in 4.3. >> >> >>>> >> >> >>>> For GRIB files, you really want to use feature collections , type = >> >> >>>> GRIB. >> >> >>>> >> >> >>>> 4.3.12 is the last alpha, next release will be beta. It should >> >> >>>> be ready this >> >> >> week. >> >> >>>> >> >> >>>> Would appreciate use and feedback. >> >> >>>> >> >> >>>> John >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> thredds mailing list >> >> >>>> thredds@xxxxxxxxxxxxxxxx >> >> >>>> For list information or to unsubscribe, visit: >> >> >>>> http://www.unidata.ucar.edu/mailing_lists/ >> >> >>> ********************** >> >> >>> "The contents of this message do not reflect any position of the U.S. >> >> >> Government or NOAA." >> >> >>> ********************** >> >> >>> Roy Mendelssohn >> >> >>> Supervisory Operations Research Analyst NOAA/NMFS Environmental >> >> >>> Research Division Southwest Fisheries Science Center >> >> >>> 1352 Lighthouse Avenue >> >> >>> Pacific Grove, CA 93950-2097 >> >> >>> >> >> >>> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address) >> >> >>> voice: (831)-648-9029 >> >> >>> fax: (831)-648-8440 >> >> >>> www: http://www.pfeg.noaa.gov/ >> >> >>> >> >> >>> "Old age and treachery will overcome youth and skill." >> >> >>> "From those who have been given much, much will be expected" >> >> >>> "the arc of the moral universe is long, but it bends toward >> >> >>> justice" -MLK >> >> Jr. >> >> >> >> >> >> _______________________________________________ >> >> >> thredds mailing list >> >> >> thredds@xxxxxxxxxxxxxxxx >> >> >> For list information or to unsubscribe, visit: >> >> >> http://www.unidata.ucar.edu/mailing_lists/ >> > _______________________________________________ >> > thredds mailing list >> > thredds@xxxxxxxxxxxxxxxx >> > For list information or to unsubscribe, visit: >> > http://www.unidata.ucar.edu/mailing_lists/ >> >> >> >> -- >> Dr. Richard P. Signell (508) 457-2229 >> USGS, 384 Woods Hole Rd. >> Woods Hole, MA 02543-1598 -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598
thredds
archives: