Changes between Version 13 and Version 14 of MolesDiscussion

28/07/06 14:01:40 (13 years ago)



  • MolesDiscussion

    v13 v14  
    102102 * The next thing is a choice of four items, only one of which should appear for any parameter. Either the value, or the range of values, or an enumeration list of the  value types, or a compound group should appear. ''Yes/No? If so, ticket needed: It needs to be a choice as to whether this thing exists and it needs a name.'' ''Also another ticket: Roy to give us a few practical examples of how the parameter group is intended to work '' 
     104''Roy:'' ''The primary reason for this is the way we handle date/time in BODC, which is to carry two parameters (days elapsed since the start of the Gregorian Calendar and time within day), BUT we have now decided that the inclusion of this was down to a misunderstanding (see above) about what was to be done with co-ordinate data channels in MOLES.  The other thing that was in the back of my mind was how we handle data quality information (parameter + flag) but I now see this is more of a CSML issue than a MOLES issue. So, I think parameter groups are dropping off our radar'' 
    103106   * ''Siva: Yes,at BODC we are using the following Strategy.Go for dgRangeDataParameter and check if HighValue=LowValue, in which case we use dgValueDataParameter.The way we get the HighValue and LowValue is,  by opening each Series data file (QXF file) and the min and max value for the required data channel is obtained.Once the limits for each Series have been obtained, the extremes may be determined to give the limits for the dataset.We cannot envisage using dgEnumerationParameter.'' 
    104107   * ''Dominic: I am concerned that it's not practical to obtain the High and Low values for a parameter when you are dealing with very (very) large datasets e.g. atmospheric model runs. Not practical in the sense that it would increase the processing time to generate CSML by many orders of magnitude.'' 
    108111 * The other elements are rather obvious, but ... 
    109112   * Note that we would expect to use the dgStdParameterMeasured variable to encode both the phenomenon name and the cell bounds (so we get the averaging information  here). ''Can we promote something useful from the CF cell methods? Ticket Needed'' 
     114''Roy:''''This worried me a little at first, but the more I think about it, the more I think it might help as exposes the two items of information needed to map CF to a BODC PUV term side by side making them a much easier target!'' 
    110115 * I suppose we imagine a granule of consisting of multiple phenomena with multiple feature types, but we would expect that any one phenomenon in one granule to have one feature type (''Andrew/Dominic?''). In which case the feature type name and the feature type catalogue from which it is governed should also be encoded per parameter. However, one might argue that the assumption might be violated, and in any case, at this point the user might be pointed to the WFS level. ''It would certainly be simpler, and possibly more useful to generate a list of feature types present in the granule (along with their FTC antecedents).'' ''Yes/No? Ticket Needed?!'' 
    111116   * Dominic:''I think that assumption (one phenomenon -- one feature type (for a given granule)) is correct.''