Creating the dataset configuration file using Dapper Server

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:

db_type

dapper - must always be the string dapper

db_server

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.

db_name

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/.

db_title

title to be used with this dataset

db_table

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:

http://las.pfeg.noaa.gov/dods/ndbcMet/ndbcMet_time_series.cdp.asc?location.LON,location.LAT,location.DEPTH,location.profile.TIME,ATMP&location.LON>=230.0&location.LON<=239.0&location.LAT>=32.43&location.LAT<=41.43&location.profile.TIME>=3.8016E11&location.profile.TIME<=4.090392E11

longitude

name of the variable containing longitude values

lon_domain

range of longitude values stored in the database (typically 0:360 or -180:180)

latitude

name of the variable containing latitude values

depth

(optional) name of the variable containing depth values

depth_units

(optional) units associated with the depth variable (e.g. meters)

time

name of the variable containing time values

time_units

units associated with the time variable (e.g. hours since 1970-01-01 00:00:00)

time_type

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.)

time_format

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.

profID

(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.

cruiseID

(optional) name of the database variable containing the cruise ID

The comments for profID apply for cruiseID as well.

missing

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.