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.

Re: [thredds] Scan Aggregation vs. Feature Collection

Hi Ethan -

My catalog is configured for Best and Files

<fmrcConfig datasetTypes="Best Files" />

Result: 

http://64.9.200.113:8080/thredds/catalog/LakeErieSST-FMRC/catalog.html

> -----Original Message-----
> From: thredds-bounces@xxxxxxxxxxxxxxxx [mailto:thredds-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ethan Davis
> Sent: Friday, November 30, 2012 4:44 PM
> To: thredds@xxxxxxxxxxxxxxxx
> Cc: Charlton Galvarino (2Creek)
> Subject: Re: [thredds] Scan Aggregation vs. Feature Collection
> 
> Hi Kyle,
> 
> Do you have your FMRC configured to only generate the "Best" dataset? It
> sounds, instead, like you are looking at the 2-D time view of the FMRC.
> 
> This line in your FMRC would restrict it to only produce the "Best" dataset:
> 
>   <fmrcConfig regularize="true" datasetTypes="Best" />
> 
> Without an fmrcConfig element, I believe the default is to produce all views.
> So the same as
> 
>   <fmrcConfig regularize="true" datasetTypes="TwoD Best Files Runs
> ConstantForecasts ConstantOffsets" />
> 
> 
> Ethan
> 
> 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.
> >
> > 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
> 
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit:
> http://www.unidata.ucar.edu/mailing_lists/
  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: