Changes between Version 2 and Version 3 of csmlAPIQuestions


Ignore:
Timestamp:
30/06/06 13:04:22 (13 years ago)
Author:
astephen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • csmlAPIQuestions

    v2 v3  
    1313 * Path names - in the CSML, should we store relative paths or absolute paths. The 'delivered' CSML should probably be relative, but what about the stored CSML?  
    1414 
    15  * domain - the domain complement and reference could be a hinderance when we want to do basic axis indexing. At present I don't know the order automatically, this is a major problem for efficient sub-setting. (quoted from Ag - could you explain why this is?) 
     15 * domain - the domain complement and reference could be a hinderance when we want to do basic axis indexing. The CSML file doesn't tell us how an array is structured in terms of axis order. When we are defining an interface to the data it is a common requirement to query the axis order, and often we would like to be able to subset just based on a set of axis indices. In order for the DX to cope with very different types of Grid Series Feature (rather than just "tzyx" ordered data) it needs to be able to call feature.getAxisList() and then to associate a subset specifier with that domain. 
    1616 
    1717 * Global attributes - applications can need to know 'global attributes', for presentation or otherwise. Without MOLES, we don't have access to these directly from CSML. Is there a case for storing some global attributes in the CSML. 
     
    2727 * Upside-down data - in Alpha we didn't use the mappingRule element to specify the orientation of the data, so some of it was the wrong way up. The orientation (e.g. +x-y+z+series) should be calculated when scanning and processed by the API.  
    2828 
    29  *  The DX (and other) GUI needs to provide enough information about a variable so that the user can identify what it is. The name is not enough because you can have different cell_methods (CF-talk) on a variable (such as mean and std deviation).  But, even cell_methods might not be definitive. We need to consider what/how this stuff gets to users. 
     29 * The DX (and other) GUI needs to provide enough information about a variable so that the user can identify what it is. The name is not enough because you can have different cell_methods (CF-talk) on a variable (such as mean and std deviation).  But, even cell_methods might not be definitive. We need to consider what/how this stuff gets to users. 
     30 
     31 * Re-use of existing code where available. There is likely to be different interfaces required for different feature types. The Grid Series Feature and Grid Feature are both already well served with the cdms library (which is already python, already using Numeric/Masked Arrays and already provides an appropriate interface). In analysing what we can achieve for Beta we should consider where to plug into libraries like cdms and just use them as-is for now. This might free resource to work on supporting Features that do not have a useful library in place yet. 
     32 
     33 * Reducing multiple calls to data files. On testing the Grid Series Feature API it was apparent that many files were being re-opened a number of times to fetch metadata or axis information. This repeated I/O should be reduced. One method might be to read in all coordinate variable values when scanning and store these inline. This shouldn't be a massive bulk because most datasets will only need to reference a few domains that are repeated for different variables (phenomena).