You are using an outdated browser that does not fully support the intranda viewer.
As a result, some pages may not be displayed correctly.

We recommend you use one of the following browsers:

Full text

International cooperation and technology transfer
Fras, Mojca Kosmatin

Initial date
Final date
File format
File location
These values are organized in a number of different
relational tables depending upon the specific "entity type".
For instance, for an entity of type "municipality" the
"position" is in fact a collection of point coordinates
representing its borders. For a measurement station the
position slot is only a pair of coordinates. The same is true
for the slot "relations" which defines the entities that are
connected in some way to the one at hand (for instance, a
lake has a relation with the inflowing river).
Obviously, several different data sets may belong to the
same entity and they may also belong to different data
categories. For instance, a measurement station may
collect flow data as well as air temperature or oxygen
The “comment” field can be used to supply all additional
information to the data set, such as methods of measure,
data reliability, code for missing data, etc.
The entity type is the only attribute that must be chosen
within a specified value set: municipalities, mountain
communities, parks, lakes, rivers, measurement stations.
Extensions of this set imply a revision of the system, while
for all the other sets (for instance, data categories or file
formats) they can be easily expanded by the system
administrator since their possible values are also stored in
specific database tables.
The definition and use of the attribute "relations" requires
some more details. The entity types are organized in a
hierarchy, which, together with the geographical location,
automatically defines a certain number of relations
between entities. Such a hierarchy is sketched in figure 4.
For instance, a mountain community is automatically
related to the municipalities that constitute it or a river is
related to the park through which it flows. However, the
entity at a higher level in the hierarchy are related with all
the entity at a lower level, while the reverse it is not true.
Entities at the same level are related only to those
adjacent or included. The system administrator can also
force other relations in specific cases.
The existence of such relations among entities is of great
importance for data retrieval. If a user is looking for air
quality data in a certain community, he or she will be able
to see all those collected by the individual municipalities,
even if they are not directly in relation with the community
as a whole. On the contrary, if the user looks specifically
for the data in a certain municipality, that means he or she
is not interested in the rest of the community and thus
such data will not be provided. Note that air quality data
are normally associated to measurement stations, but
they can be found looking for a municipality since they
have a relation of inclusion with it.
The architecture of the system is very simple and based
on two different figures: users and administrator (fig. 5).
Fig. 5 - Structure of the system
Each of them has dedicated programs either in the client
(the users) or in the server (both the users and the
administrator) side of the computer implementation.
The user can search for environmental data sets by
preparing a query to the metadata base using the
interface. He can search by selecting a geographical
position (within a given distance from a point, whose
coordinates are either entered numerically or by clicking
the mouse on the map), by data categories, by time
period or by a combination of these attributes. He can
preview the data.sets found and decide whether or not to
download them. He or she can also submit new data sets
to the system. For this purpose, a frame with the
metadata specification must be filled and the file
containing the data set is uploaded to the server. Finally,
the user can also suggest the creation of a new
measurement station, by defining its position and name.
Both these last possibilities require the intervention of the
administrator. He is notified of the user’s request, must
analyze the information submitted by the user and control
that all the necessary definitions have been correctly
supplied. Obviously, he is not responsible for the
correctness or completeness of the data, which are
entirely under control of the data provider. It is, on the
contrary, a task of the administrator to check if the
relations automatically established by the system for the
new data set are correct or if other should be added.