International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XXXIX-B4, 2012
XXII ISPRS Congress, 25 August — 01 September 2012, Melbourne, Australia
information. To achieve this goal it is necessary to build
custom interfaces that allow solving the basic problems that
arise in a variety of EO systems. Naturally, every specialized
monitoring system has its own special challenges, but one can
outline the overall specificity, which nowadays occurs in
almost all such systems. Most of modern remote monitoring
systems should
1) allow to monitor large areas and quickly to provide
information about monitored objects and phenomena to
geographically dispersed users;
2) provide an opportunity for ongoing monitoring of
controlled objects and phenomena, i.e. be designed to
work with continuously updated information;
3) allow obtaining various characteristics of controlled
objects and phenomena and, therefore, be focused on the
use of information from various observation platform
(satellites, aircrafts, in-situ etc);
4) archive data for enough long periods of observation since
in many cases the objective of monitoring systems is to
identify deviations from “normal” behavior of the
controlled objects and phenomena;
5) be capable of working with distributed archives and
databases, as the collection, analysis, processing and
storage of information can take place in different
geographically distributed centers;
6) due to the need of working with fairly large information
flows and amounts, be mainly focused on fully automated
technologies for collecting, processing, distributing and
presenting the data;
7) provide users with information that has passed sufficiently
deep levels of processing as well as convenient toolkits
(interfaces for its analysis), and in many cases be capable
of dynamic generation of certain products at the request of
the user;
8) allow users to obtain and to analyze various kinds of
spatial data;
9) effectively receive and integrate data from third-party
monitoring systems as well as an easy access to various
information products, including online services provided
by the system.
3. EO CUS ARCHITECTURE
To work with map data EO CUS should provide at least the
following functionality:
e to be able to present data on map layers;
e toown basic functions to proceed with maps;
e to be able to search catalog data and to display
retrieved information;
e to be capable to can export data.
While implementing these functions in Web interfaces one
should follow the next principles of their development:
e structural modularity;
e application of object data model;
7 flexibility of configuration;
e easyextensibility.
As analysis reveals it is possible to split EO CUS on two
functional levels which interactions are shown in Fig.1:
e Presentation level which should include Web and
GIS interfaces and is based on usage of UICU;
e Application level which functionality is based on
IRIB and should include:
o Web services (including map services, metadata
services, and data management services);
o System API, enabling access to data, metadata,
and various resources and interfaces.
Presentation level
x es
Browsing in ArcGIS Export es m Googe Map interface
AVS Application level
System API
Web services
Formation of metadata
Map services Metadata services
Access
i J
of
Access control
Data management CGI modules Q
Process control
Fig.1. EO CUS architecture.
Presentation level (aka UICU) is subsystem that supports
interaction with user. This level should allow user to work
with system via Web interface or via specialized applications,
e.g. GIS. As typical GIS is equipped with all basic tools to
work with map data its interactions with EO CUS should run
on data service level. This is the reason why EO CUS should
be oriented on development of unified data access interfaces,
i.e. UICU. UICU architecture is presented in Fig.2.
Web interface |
Controt
: | » | smisMap
| (map object)
GetMetadata
smisMeta
JSON | (metadata object)
| |
Metadata J Map interface
Web Service
a
Fig.2. UICU architecture.
Work of such interfaces should be provided by kernel consisted
of two object modules:
e Map module which is designed in our work as smisMap
software module (see Fig.2);
eo Metadata module which is is designed in our work as
smisMeta (see Fig.2) software module.
Map module is advisable to implement as JavaScript object
which should enable to display map information retrieved by
data services. In addition, module should allow to send spatial
queries and to export displaying data to print service or even to
other systems.
Metadata module is advisable to implement as JavaScript
object as well. This module should support catalog data search
and retrieval of data necessary for information displaying on
rendering service.
224
