Changes between Version 3 and Version 4 of csmlAPIQuestions


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

--

Legend:

Unmodified
Added
Removed
Modified
  • csmlAPIQuestions

    v3 v4  
    77Additionally integration of the alpha CSML API with WCS and the Data Extractor has brought up plenty of other issues that we also need to take into account. Most of which (except minor bugs) are documented here: 
    88 
    9  * 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. ? 
     9 * 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 
    1111 * 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.