Changes between Version 9 and Version 10 of csmlAPIQuestions


Ignore:
Timestamp:
06/07/06 14:29:41 (13 years ago)
Author:
domlowe
Comment:

Added in ticket links

Legend:

Unmodified
Added
Removed
Modified
  • csmlAPIQuestions

    v9 v10  
    99 * Idenfication of axes - although CSML does not place specific requirements on axis names, applications need to know which are the longitude/latitude/level/time axis. This can usually be inferred from the CSML context/feature type, but should we explicitly have attributes in the CSML document such as isLatitude, isLongitude, isTime etc. ? An example is that in the current csml API you need to be able to find out what the time axis is called (id) so that you can handle it accordingly. Doing the standard CF-compliance checks is the best way to ensure you have the correct axis. 
    1010 
    11  ** This information is contained in CSML, but for NDG2 we need to explcitly provide support for certain coordinate reference systems and have a mechanism for exposing the information ('this axis is longitude') to the client. See ticket: TICKET LINK 
     11 ** This information is contained in CSML, but for NDG2 we need to explcitly provide support for certain coordinate reference systems and have a mechanism for exposing the information ('this axis is longitude') to the client. See ticket: [ticket:407] 
    1212 
    1313 * Calendaring - The frame of reference for times may depend on different calendars e.g 360_day, Gregorian etc. This information should be stored in the CSML probably in a srsName attribute - is this always possible? What about when times are encoded as file extracts rather than inline? Currently (alpha) the API refers back to the original data to check the calendar attribute, but this is inefficient. 
    1414  
    15  ** Calendar info should be stored in CSML. Also need to define which calendars we support. TICKET 
     15 ** Calendar info should be stored in CSML. Also need to define which calendars we support. See ticket: [ticket:408] 
    1616 
    1717 * 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?  
     
    2929 * CF compliance - to write CF-compliant NetCDF we may need to store additional attributes alongside 'variable' and 'axes' (i.e. attributes of the feature and domain). Which attributes are required for CF compliance? "units" is a significant example as CF says you can determine the axis identity from the "units" attribute - we need to be able to do that so we need to capture the units attribute. Will this model be viable when the CSML is not derived from underlying CF-NetCDF? 
    3030  
    31  ** The crux of this issue is that CSML is a lossy format, and not a mirror of the underlying NetCDF data model. Action to come up with a specification for a minimally compliant net CDF document. We will then assess if this is sufficient for use by client applications, and whether CSML needs to contain any additional attribute information. TICKET. If additional attribute information is required, eg. cell_methods, then we should see where this fits into the conceptual model - i.e is it part of the phenomenon or where else might it go in CSML, 
     31 ** The crux of this issue is that CSML is a lossy format, and not a mirror of the underlying NetCDF data model. Action to come up with a specification for a minimally CF compliant net CDF document. We will then assess if this is sufficient for use by client applications, and whether CSML needs to contain any additional attribute information. TICKET. If additional attribute information is required, eg. cell_methods, then we should see where this fits into the conceptual model - i.e is it part of the phenomenon or where else might it go in CSML, See ticket: [ticket:409] 
    3232 
    3333 * Data in memory  - applications may want to hold the data in memory rather than receiving a link to NetCDF file. 
     
    4747 * 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.  
    4848 
    49  ** Problem understood and fairly simple to solve. Andrew to come up with a clear explanation of the sequence Rule element. TICKET LINK 
     49 ** Problem understood and fairly simple to solve. Andrew to come up with a clear explanation of the sequence Rule element. See ticket [ticket:410] 
    5050 
    5151 * 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. 
     
    5454 
    5555 * 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. 
    56   ** Dom to look at CDMS code to see what might be useful. TICKET 
     56  ** Dom to look at CDMS code to see what might be useful. See ticket: [ticket:411] 
    5757 
    5858 * 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). 
     
    6666 * Subsetting - it would be nice to allow subsetting by index or by value. Also, need to allow subsetting across the Greenwich Meridian. 
    6767 
    68  ** Subsetting by index would be nice, but probably not required yet. Dom to fix bug with subsetting across Greenwich Meridian TICKET. 
     68 ** Subsetting by index would be nice, but probably not required yet. Dom to fix bug with subsetting across Greenwich Meridian See ticket: [ticket:412]