Changes between Version 14 and Version 15 of MolesDiscussion

28/07/06 15:24:05 (13 years ago)



  • MolesDiscussion

    v14 v15  
    55 * Modified by Siva, Dom and Kevin with explicit inline comments. 
    66 * Modified BNL, 25 July, based on followup discussion between BNL and KON on the 24th ... 
     7 * Modified RKL, KDO, 28 July with inline comments. 
    89==== Issues on the Table ==== 
    9899      * BNL: So I think the height of the data parameter is something that belongs in CSML ... and so this should be out, and replaced (for BODC) with something that covers the BODC use case (but exactly what use case supports hiding a parameter from discovery? 
     101            * KDO - height? Is this visibility? Anyway, this isn't the point of the flag (new name needed?), the concept behind which has been useful in other areas. 
    100103''Roy:'' ''Seems to be a misunderstanding here.  I was using IsOutput to hide co-ordinate channels (date/time, depth, CTD pressure) as I thought that was how MOLES was to be used.  Kicking them out altogether is just as good for me.'' 
     105    * KDO - Good, if understand you aright, then Siva's point now makes sense to me. I'd rather use the word "mark" rather than "hide", but the point is that you might want this parameter there, but you don't want it mistaken for a measured value. Hence I say it stays. However, if Bryan still feels strongly, it could be made optional. This would then require consistent usage within a DP, and if it isn't there then "co-ordinate variables" should be left out. 
    102107 * 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 '' 
    104109''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'' 
     111 * KDO - It was also a way to link the GCMD valids to BODC variables in a controlled way, without putting the GCMD terms  into structured keywords. 
    106113   * ''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.'' 
    114121''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!'' 
     123 * KDO - so you'll explain to me why this isn't a parameter group Bryan? 
    115125 * 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?!'' 
    116126   * Dominic:''I think that assumption (one phenomenon -- one feature type (for a given granule)) is correct.'' 
    127137It is a moot question as to how much of this needs to be replicated from the granule content. ''Tickets needed on some of the following'' 
    128138 * BNL would argue that the spatio-temporal coverage should be the *union* of the granule coverages (''need a tool to produce this''). 
     139 * KDO - would other data providers like to comment on what they want to do for their data?  
    129141 * The parameter coverage is a bit more complicated, because now we think we could have, for example, temperature monthly means and temperature annual means in the granules. I think the only thing that makes sense is to aggregate the granule parameter summaries. ''In which case why bother? We can parse the granule content. Remove?'' 
    130142 * ''There ought however to be a consolidated lists of feature types present ... as well. Add?'' 
    147159(BNL I'm still convinced that dgDataObjectType is covered by the dgGranule content (with feature type added), so it should go). 
     161(KDO - I'm not, but if no one comes forward to provide the relevant attributes, then it should go... for the moment ;-) 
    149163==== ISO19139 ==== 
    158172It's quite clear that the MOLES data model needs to be in UML. Ideally we'd want to be able to autogenerate the schema via ShapeChange, but that's a ''long'' way away, meanwhile, the docs should make as much as possible clear with UML fragments. 
     174(KDO - 19115 was in UML: 19139 was then necessary. 'nuff said!)