on 
lata 
ata, 
  
  
  
orts 
vork 
ons, 
s to 
run 
ould 
ces, 
  
ace 
sted 
Map 
k as 
jject 
d by 
atial 
'n to 
cript 
arch 
g on 
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 
Application level (aka IRIB) is subsystem that should enable 
interaction between interfaces and data themselves. This level 
must be consisted by Web services and system API (see Fig.3). 
  
ga ki Plugins The core service CGl-service 
  
  
  
  
Nr IN | ry 
1 t N + 
i FINES. i Map service 
Par ) 
  
  
  
  
  
  
id 
| À H 
! 
i t | core “| Metadata service [‘* Web user interfaces and 
: : : : - applications 
i : i " id 
A t : ; Data service —— ul 
| apN i ut i J 
| i i 
(ET : i (E Hk 
n ! i 
| 
  
  
Node smiswms 
  
  
Fig.3. IRIB functional modules’ structure 
Web services should receive data access based on HTTP 
protocols. In order to provide application level functionality on 
application level of EO CUS three types of Web services must 
be included in IRIB: 
e Map data Web service; 
e Metadata Web service; 
e Data management Web service. 
Map data Web services should allow receiving map 
information in form of raster images. This type of services has 
to be based on extension of WMS standard. It should allow 
providing data not only for Web interfaces but as well for GIS. 
Metadata Web services should allow receiving information on 
product availability for requested geographic region or dating 
interval as well for given additional criteria set. These services 
should be able to work with JSON or XML formats and send 
queries addressing any catalog in distributed data system. 
Returning information should contain both descriptive data and 
auxiliary data for map services. 
Data management Web services should enable data 
manipulation in database via Web queries, such as adding 
information on contours and their attributes, their changing and 
deleting. Interaction with those services should be conducted in 
JSON format. 
All three types of EO CUS Web services should be realized in 
frame of one common strategy i.e. should be integrated in one 
common service. Those common services should enables 
support of map data receiving (via request GetMap which 
should be generated in interface by smisMap module), queries 
on metadata receiving (via request GetMetadata which should 
be generated in interface by smisMeta module), requests on 
data addition and modification, e.g. addition of polygons and 
information about them. So, Web interfaces kernel should be 
able to provide direct interaction with metadata retrieving 
services and map information displaying. It is important that 
interactions should be possible to install with any amount of 
spatially distributed services. 
System API is separate part of IRIB. It is the set of Perl 
modules, which should be located on servers and be able to get 
data access and to work with data on server side. All above 
mentioned services should work with data via those modules. 
Each module should take responsibility for definite data type or 
system part. It should allow flexible system configuration, error 
fixing, and fast software development. 
4. IMPLEMENTATION OF BASIC ELEMENTS 
4.1 UICU IMPLEMENTATION 
In developing the EO CUS particular attention was drawn to 
the issue of designing the structure of interfaces aimed to work 
with data sets. Taking into account needs in reasonably clear 
and user-friendly interfaces which should support operations 
with different-type quickly updated spatial data, it was 
necessary to develop some general approaches to allow user 
easily navigate interface content. To this end the basic type of 
Web interface was designed, namely the UICU which structure 
is shown in Fig. 4. 
Data management Map information 
  
  
Pop-down menu { 
  
  
dd mm Map management buttons 
eu 
Data filter 
   
Selected data 
List control 
Mini map 
  
  
  
  
  
  
  
  
Fig.4. Basic type of UICU. 
In order to support operations with different data types, UICU 
controls have a block structure. Each data type and typical 
control function matches their own module in UICU. At user 
level the appropriate tabs for each module and each data type 
are designed in UICU. This structure allows grouping various 
similar data and various operations on data in a convenient and 
clear manner. The modular structure also allows making UICU 
scalable, with no significant difficulty to extend the interface 
with new data types, groups, or additional operations. The 
structure allows configuring UICU to work with required types 
of data. It should also be noted that in variety of specialized 
systems which exploit the interfaces based on this principle, 
the processing control for the same type of the data can be 
performed in the tabs of the same type. It facilitates both the 
development of specialized interfaces and data exchange 
between different systems. 
To work comfortably with multi-temporal datasets UICU 
realizes unified blocks which allow managing satellite data of 
different types as well as the results of their processing, e.g. 
working with: 
e data of high spatial resolution displayed by quite localized 
scenes; 
e data of coarse and moderate resolution with their 
characteristic units, “sessions”, covering large areas; 
e series of temporal and spatial composites of various 
products of satellite data processing. 
There's also a special opportunity in UICU to sample different 
types of data layers to perform their joint analysis. Selected 
data layer controls are collected in a separate tab which, 
225