The dataset configuration file fora dataset that requires Dapper access must include information that describes the location and nature of the data to the Dapper service. The Dapper service will use this information to access the data and properly convert the data intoan intermediate NetCDF file.
Action Performed by Date and Time Comment Publish Jonathan Callahan 2006-09-12 11:35 No comments.
The dataset will typically require a new user interface behavior-- the combination of Views/Products/Options presented by the LAS user interface (UI). Both the UI and database access information are specified as a set of properties within the dataset <properties>... </properties> tags.
LAS is distributed with an example data set which uses a Dapper server. The example will be in the $LAS_HOME/conf/server/pfeg.xml if you have installed the in-situ examples when you configured your LAS> The <properties> section of the pfeg.xml file distributed with LAS is given below:
<properties> <ui> <default>file:ui.xml#dapper_demo</default> </ui> <database_access> <positive>down</positive> <time>location.profile.TIME</time> <depth_units>meters</depth_units> <db_table>ndbcMet_time_series.cdp</db_table> <depth>location.DEPTH</depth> <db_title>NOAA Time Series</db_title> <missing>NaN</missing> <lon_domain>0:360</lon_domain> <time_units>msec since 1970-01-01 00:00:00</time_units> <longitude>location.LON</longitude> <db_name>ndbcMet</db_name> <db_server>PFEG Server</db_server> <time_type>double</time_type> <db_type>dapper</db_type> <latitude>location.LAT</latitude> </database_access> <product_server> <ui_timeout>1000</ui_timeout> <ps_timeout>3600</ps_timeout> <use_cache>false</use_cache> </product_server> </properties>
The <ui> properties are described in the section on Configuring the UI for scattered data.
The<database_access> (these are called database_access even thoughthey refer to a Dapper server) properties are described below:
- dapper - must always be the string dapper
- This the key that is used to look up the server URL in the DRDSBackendConfig.xml file and refers to the name attribute of the <dapper> element.
- this is the top level name of the data set from the Dapper server. This will be used as the first part of the resulting dapper URL. In this example the db_server URL and this property combine to give an OPeNDAPaccess url of: http://las.pfeg.noaa.gov/ndbcMet/.
- title to be used with this dataset
name of the OPeNDAP collection in which the data is stored on the Dapper server. In the response this becomes the name of the OPeDNAP sequence that will contain the data. For example, internally the OPeNDAP client in the Dapper server might make a request like this:
- name of the variable containing longitude values
- range of longitude values stored in the database (typically 0:360 or -180:180)
- name of the variable containing latitude values
- (optional) name of the variable containing depth values
- (optional) units associated with the depth variable (e.g. meters)
- name of the variable containing time values
- units associated with the time variable (e.g. hours since 1970-01-01 00:00:00)
- data type of the time variable stored in the database (use double for all numeric times)
Currently, time_type must be one of double | int | string. The behavior of the database service is to assume that time variables with a type of double have appropriate units and can be written directly into the intermediate NetCDF file. Whenever the database service encounters a time of type int or string it assumes that the time variable has an ASCII representation that must be converted into a floating point value. The conversion is performed by the the org.joda.time library. (If the time variable in your database is stored as type float you must still specify double in the <database_access>properties. This will be corrected in a future release.)
- coaches org.joda.time library on how to interpret ASCII representation sof time (joda time format patterns)
- Need an example that requires <time_format>. This example does not since time is a double.
- (optional) name of the database variable containing the profile ID
Aprofile ID variable can be used to associate multiple records in a database with a single atmospheric or oceanographic profile. If specified, the variable identified by profID will be written to the intermediate NetCDF file as PROF_ID. As released, Armstrong supports several Ferret based products that rely on the presence of the PROF_ID variable in the intermediate NetCDF file.
- (optional) name of the database variable containing the cruise ID
The comments for profID apply for cruiseID as well.
- missing_value flag to be used in the intermediate NetCDF file
There is currently no way to identify missing value flags that are stored in the database.