Download EDCSS integration into OneSAF

EDCSS Integration into OneSAF – Technical Details
EDCSS integration into the OneSAF Environment Runtime Component (ERC) is described in three parts:
the EDCSS Adapter, C++ code modifications, and Java/JNI code modifications. This division helps identify
what types of changes were necessary and where they occur. The additions for the PVD weather layer to
view weather attributes over geographic areas is discussed in its own section.
EDCSS adapter
The EDCSS interface for retrieving a weather value requires the caller to specify the data product
(database name), parameter (e.g., temp, humidity), vertical layer (altitude), date and time, and location.
These parameters are specified using EDCSS data types. The EDCSSAdapter class encapsulates these
details behind interfaces that accept standard OneSAF data types. The EDCSSAdapter contains a method
to query (isInitialized) whether or not an EDCSS database is active. This method is used in the C++ code
to conditionally make calls to EDCSS or global METOC.
Upon initialization, the EDCSSAdapter syncs OneSAF SimTime to the first date in the EDCSS dataset. All
calls to weather queries use this time offset to query EDCSS weather parameters. Caller-supplied
altitudes are translated into EDCSS layers using the highest layer the altitude is above (floor function). In
other words, if EDCSS has layers at 500m and 1000m, a query at 900m will use the 500m layer. Locations
are specified in geodetic coordinates – easily obtained from OneSAF coordinates. Weather parameter/
attribute name translation occurs in the C++ code to avoid circular dependencies.
ERC C++ modifications
The majority of changes to ERC C++ code occur in the AosRuntimeCoverage and AosRuntimePage
classes. The approach taken tries to minimize impact to existing ERC code. AosRuntimeCoverage uses
the file name extension to determine which database is requested and initializes the appropriate one.
For subsequent weather queries, it has conditional code in key places to make the appropriate call into
AosRuntimePage based on which weather database is loaded. AosRuntimePage makes the low-level
calls to the weather databases. Several methods in this class are duplicated, taking different arguments
depending on which weather database is used. An AosAttributeTypeMap class provides the mapping
from OneSAF weather attribute strings to EDCSS weather parameter strings.
Minor changes were made in the call chain through EnvironmentServices, AosApi, and
AtmosphereInterface to accommodate EDCSS integration. Unit tests (specifically auto_tests) were
modified to test data returns using the EDCSS OneSAF_CONUS_Sample database.
ERC Java/JNI modifications
Since the C++ modifications for EDCSS queries made no changes to external weather interfaces, they
had no effect on the Java/JNI code. The ERCInitializer did require modifications to detect (via file name
extension) which type of database to load and append an EDCSS path when appropriate.
1
PVD weather layer
This effort added the ability to visualize weather attributes in the PVD. A WeatherGridLayer class
provides this functionality. An interface to query for the grid values was added to ERC at all levels (Java,
JNI, and C++). On the Java side, the grid query method resides in the AosApi class and a new class
(GridQuery) contains the underlying support. The JNI AosAPI class was modified to pass the grid across
the code language boundary. On the C++ side, AosRuntimeCoverage contains the bulk of the grid query
code, constructing a grid covering the requested geographic area and populating it with queried values
for the queried weather attribute. A new Grid class in ERC core provides the container for the weather
grid information. Pass-through interfaces were added to the AosApi and AtmosphereInterface classes to
allow external access for the JNI layer.
2