> Does the presence of a featureType attribute indicate that a file uses the > DSG "machinery" and should therefore follow the guidelines of limited axes > that are spelled out in chapter 9?
This was the reason I favored creating a new ACDD term. It was clear in the documentation that featureType implied a DSG-compliant file -- but I didn't see any reason I had to create a DSG-compliant file to make the file CF-1.6 compliant. As Nan says, it implicitly overloads the term. Happy to be educated if I missed something. (But if it is true that all CF-1.6 compliant files have to be DSG, than there is no reason for featureType to mention DSG, since every file will already be DSG.) John On Dec 3, 2013, at 06:31, Nan Galbraith <[email protected]> wrote: > Sorry to drag this out again, but I need to restate my question; it's more or > less the opposite of the question that was answered. > > Does the presence of a featureType attribute indicate that a file uses the DSG > "machinery" and should therefore follow the guidelines of limited axes that > are spelled out in chapter 9? > > Can I use this attribute and NOT have an instance (or station) dimension, > but stick with my current encoding: > float seatemp(time, depth, lat, lon) > rather than changing to: > float seatemp(station, time) > > We need an attribute in oceansites files that indicates the type of feature > in the file - > multiple-depth moored instruments, single-depth moored instruments, profiles > ... > We'd like to use this attribute to fill that role, but if it is overloaded in > the sense that > it indicates something else about the file, we'll need to use another term. > > Thanks - > Nan > > On 8/29/13 9:55 AM, Jonathan Gregory wrote: >> Dear Nan >> >> It is allowed to use the new "machinery" of ch9 only if the featureType att >> is included. Perhaps we should put this in Appendix A - is that your >> suggestion? The new machinery is the incomplete multidimensional >> representation >> and the two ragged representations (which collapse the data variable into 1D) >> It is allowed to use the orthogonal rep (the data variable is >> samples*features) >> because that existed anyway, before ch9 was introduced, and there were >> already >> examples of it in the document. >> >> Best wishes >> >> Jonathan >> >> ----- Forwarded message from Nan Galbraith <[email protected]> ----- >> >>> Date: Thu, 29 Aug 2013 09:46:14 -0400 >>> From: Nan Galbraith <[email protected]> >>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) >>> Gecko/20130801 Thunderbird/17.0.8 >>> To: [email protected] >>> Subject: [CF-metadata] featureType attribute (was CF-1.6 DSG clarification: >>> time series & lat/lon coordinates) >>> >>> Hi all - >>> >>> Quick question on the featureType attribute. >>> >>> Back in June, Jonathan Gregory said: >>> >>>> for a DSG (which is indicated by the presence of featureType) >>> I don't think this is stated clearly in the CF 1.6 manual, and as a >>> result, some >>> people have taken 'featureType' to be the equivalent of the 'cdm_data_type' >>> attribute. >>> >>> I'm not using discrete sampling geometries yet, and am not >>> completely familiar >>> with the details of this part of CF 1.6, but I understand that the >>> rules for allowed >>> coordinate variables (dimensions) are quite different from those of non-DSG >>> files. >>> >>> If the use of a single attribute changes the rules that much, I >>> think we need to >>> spell it out *very* clearly in the description of the featureType >>> attribute in the >>> CF document. >>> >>> Regards - Nan >>> >>> >>> On 6/5/13 9:08 AM, Jonathan Gregory wrote: >>>> Dear John >>>> >>>>> If we use the time series featureType as example >>>>> >>>>> (from >>>>> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8307552) >>>>> >>>>> AFAIU, the orthogonal multidimensional representation would be: >>>>> >>>>> float humidity(station,time) >>>>> >>>>> not >>>>> >>>>> float humidity(lat, lon, time) >>>> You are quite right, sorry. I was taking a step too far! The point is not >>>> only >>>> that the coordinates are size-1, but there is more than one of them. You >>>> are >>>> right that (lat,lon,time) can't be a timeseries discrete sampling geometry >>>> because it's got more than one spatial dimension. A timeseries DSG can have >>>> only one station (instance) dimension, and it is required to have both x >>>> and y >>>> coordinates. So these current rules mean that 2D field e.g. (lat,time) >>>> can't >>>> be a timeseries DSG. >>>> >>>> Like Mark, I saw the relevance of this to the discussion of scalar >>>> coordinates >>>> but I reached a different conclusion about it! At the moment, we are >>>> talking >>>> about the CF data model for version 1.5. DSGs were introduced in version >>>> 1.6. >>>> As a result of this discussion, it seems me that for a DSG (which is >>>> indicated >>>> by the presence of featureType), scalar coordinate variables have to be >>>> interpreted as auxiliary coordinate variables of an omitted size-one >>>> instance >>>> dimension. That is what is implied by section 9.2. It's different from the >>>> interpretation that is implied by section 5.7, which should exclude DSGs >>>> (and >>>> predates DSGs). I see no problem with having different interpretations for >>>> different purposes. >>>> >>>> Cheers >>>> >>>> Jonathan >>>> > > > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ------------------------------------ John Graybeal Sr. Data Manager, Metadata & Semantics M +1 408 675-5445 skype: graybealski Marinexplore 920 Stewart Drive Sunnyvale 94085 California, USA www.marinexplore.com _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
