The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part B4. Beijing 2008 
133 
s 
USER 
UPLOAD 
input 
query 
information 
DOWNLOAD 
(link) 
data storage 
(AFS) 
BACKUP 
-> 
upload 
meta data 
Web-Interface 
WebGIS 
input 
—> 
content & structure 
non-spatial DB 
(MySQL) 
S 
ADMIN 
Figure 2. TR32DB Design 
purchased data include geodata like topographic, elevation, 
remote sensing, soil, land use or weather data in different scales. 
Besides collected measured data and purchased data, further 
data e.g. publications, reports, videos, and pictures of the TR32 
participants need to be managed with their corresponding 
metadata. 
The TR32DB-Structure (see Figure 2) is basically subdivided in 
three components: (i) data storage, (ii) databases, and (iii) web- 
interface. The data storage is the system component where the 
project data is physically stored (upload of data). The database 
stores associated metadata and administrative data. Finally the 
web-interface provides uploaded project data of (download of 
data) and information about the TR32. A backup of the whole 
system is continuously done. In the following paragraphs, each 
core component of the TR32DB system is described in detail. 
3.1 TR32DB Data Storage (upload of data) 
The essential data storage of the TR32DB (upload of data) is 
carried out in the already established AFS. The latter was 
chosen in cooperation with the ZAIK/RRZK due to the 
mentioned reasons under 2.1 and additionally due to the support 
opportunities provided by the ZAIK/RRZK. Furthermore, the 
cooperation with a local computing center is requested by the 
DFG. 
In detail, the TR32DB file database is organized in a folder 
system. Due to the fact that the TR32DB contains a multiplicity 
of several project data, the data is arranged in different folders. 
This is designed in a specific hierarchy according to the 
mentioned structure of the TR32. The folder structure is 
therefore ordered by: (i) cluster, (ii) project sections and (iii) 
data type. The data type is divided into: data, publications, 
pictures, presentations and reports. Only users who are 
participants of the TR32 are authorized to store their data in the 
TR32DB. 
The upload of data within the AFS operates as follows. Users 
who are authorized to the AFS system own a specific view in 
their home directory. They have the opportunity to store their 
data directly via copy and paste in their particular project 
section folder sorted by the five data types. The actual project 
section folder is joined by a symbolic data linkage with a 
directory in the TR32DB. Consequently, uploaded user data is 
immediately located in the TR32DB system. The data is moved 
into the final folder directory by a script that is developed in 
cooperation with the ZAIK/RRZK. The developed solution has 
several advantages. These are basically the immutability and 
documentation of the moved data files. A database entry is 
automatically generated by the script for each moved file that 
contains e.g. the file name, the file extension, and the final file 
storage directory. Only the administrators are permitted to edit 
or delete documented information in the database as well as the 
data file directory in the AFS. 
The announced system has some restrictions. Some are set by 
the actual AFS version like a single file size limit of 2GB 
(which will be increased in near future) and others are 
established by the administrators for safety aspects. These are 
limitations like access restriction for other project section 
folders due to the user AFS-account. This has the advantage 
that the administrators are able to define the exact folders where 
users are permitted to store their data. Users are required to 
label their data files in a well-defined manner and compress 
them if possible. Furthermore, the current folder size of the data 
types is limited to 8GB (which will be extended in near future, 
too). Therefore, each SP is only able to upload 8GB per data 
type in their specific folders per day since the script operates 
over night. In exceptional cases a movement of data managed 
by the administrators is possible.