Database Reference
In-Depth Information
Structured Data
Repositories
Service
Middleware
Data Sources
Clients
HTTP
FTP
ODBC/JDBC
Data Store
Satellite
Imagery
MapServer
Web Clients
Data Views
(ODM)
GeoServer
Model
Outputs
Desktop
Applications
Application
schemas
ArcGIS
Database
(ODM)
Static
GIS Data
Local
processing
52North
Historical
Archiving
Oostethys
Sensor
Systems
Real-time
Stream
Middleware
CS-W
WFS
WCS
WMS
SOS
WSDLWS
Apache Axis
Remote Service-Enabled
Data Repositories
Figure 10.6
Conceptual architecture for geospatial data integration and
interoperability.
receive or pull streaming data. Structured data repositories are not necessar-
ily independent; derived products from raw data can be generated and saved
as additional data repositories. For example, the daily maximum/average ETo
value of an hourly model output (in raster format) can be derived and saved in
a GIS. Also monthly ETo average from weather stations can be implemented
as either a regular view (named database query) or a materialized view (a
physical instantiation of the query result) in a database. In addition, a stream
engine (e.g., Ring Buffer Network Bus, RBN,
79
) whose primary functionality is
to serve as a middleware for real-time data, can be used by certain client mod-
ules to update a database for archiving purposes. Middleware at the service
level is responsible for extracting data from structured data repositories and
providing it to clients in standard-compliant formats. Several commercial and
open source service middleware systems, such as MapServer,
72
GeoServer,
71
THREDDS Data Server (TDS),
80
52North,
81
and so forth. are currently avail-
able. As such, structured data repositories should be formulated to work with
the service middleware when possible. For example, PostgreSQL databases
storing weather station measurement data can adopt the Community
