The dataset configuration file for a dataset that requires DRDS access must include information that describes the location and natureof the data to the 'drds' service. The 'drds' service will usethis information to access the data and properly convert the data intoan intermediate NetCDF file.
The dataset will typically require a new user interface behavior-- the combination of Views/Products/Options presented by the LAS userinterface (UI). Both the UI and database access information arespecified as a set of properties within the dataset <properties>... </properties> tags.
The <properties> section of the nwioos_hake98.xml file distributed with LAS is given below:
<properties> <ui> <default>file:ui.xml#nwioos_demo</default> </ui> <database_access name="nwioos_drds"> <db_type>drds</db_type> <db_server>NWIOOS Server</db_server> <db_name>1998 Hake Survey ADCP</db_name> <db_title>1998 Hake Survey ADCP</db_title> <db_host>localhost</db_host> <db_table>adcp98</db_table> <longitude>X</longitude> <lon_domain>-180:180</lon_domain> <latitude>Y</latitude> <depth>Z</depth> <depth_units>meters</depth_units> <time>yearday</time> <time_type>double</time_type> <time_units>days since 1998-01-01 00:00:00</time_units> <hours_1970></hours_1970> <missing>-9999.0</missing> <positive>down</positive> </database_access> </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 though they refer to a DRDS server) properties are described below:
- drds - must always be the string drds
- This the key that is used to look up the server URL in the DRDSBackendConfig.xml file.
- the name of the database being served by the DRDS server (see Configuring the LAS database service). This will be used as the first part of the resulting drds URL. In this example the db_server URL and this property combine to give an OPeNDAP access url of: http://nwioos.coas.oregonstate.edu:8080/dods/drds/1998 Hake Survey ADCP.
- title to be used with this dataset
- name of the table in which the data is stored on the DRDS server. In the response this becomes the name of the OPeDNAP sequence that will contain the data. For example, the OPeNDAP client in the DRDS server might make a request like this: http://nwioos.coas.oregonstate.edu:8080/dods/drds/1998 Hake Survey ADCP.asc?adcp98.yearday&adcp98.yearday<189
- name of the database variable containing longitude values
- range of longitude values stored in the database (typically 0:360 or -180:180)
- name of the database variable containing latitude values
- (optional) name of the database variable containing depth values
- (optional) units associated with the depth variable (e.g. meters)
- name of the database 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 doublehave appropriate units and can be written directly into theintermediate NetCDF file. Whenever the database service encounters atime of type int or string it assumes that the timevariable has an ASCII representation that must be converted into afloating point value. The conversion is performed by the the org.joda.time library. (If the time variable in your database is stored as type floatyou must still specify double in the <database_access>properties. This will be corrected in a future release of Armstrong.)
- 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 adatabase with a single atmospheric or oceanographic profile. Ifspecified, 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.
- timeout (not yet implemented)
- database timeout