views using only a single data model. The conversion of lower forms of data to feature form is handled by an 
introduced image view layer, which manages the process of image interpretation and feature extraction. Features can 
be supplied directly from the physical layer, if they exist as such, or derived by the view layer from image data, if 
they don’t. The user need not be concerned with where the features are taken from; the conceptual layer simply 
makes requests for features as and when they are required. 
3.4.3 An Architecture for Full Integration 
The system described here supports data integration across the four views described above, so all of these views 
must be represented at the conceptual layer. Users or applications at the external layer may choose to work only 
with features (or any other view of the data) but are not forced to do so. The architecture required is shown in Figure 
5. Note that the conceptual layer is composed of four distinct schemas (views), and must also contain functionality 
to provide mappings between these views. The physical layer comprises a number of different data storage and 
retrieval strategies, of which vector, raster and quadtree are three examples. 
PI P2 P3 
Figure 5: An Architecture for Full Data Integration 
4. CONCLUSIONS 
This paper is the first of two parts and introduces the complexities encountered when designing schemas for 
integrated GIS. The second part (available from the author on request) defines a formal schema based on the 
discussion presented here. 
Full integration offers benefits to both remote sensing and to GIS. The GIS receives data that is sufficiently rich 
with meta-data to ensure that it is appropriate for the task at hand. The RSS receives more precise requests for data, 
and in addition gains access to a rich source of ancillary data to aid in the image interpretation tasks. To achieve full 
integration, substantial changes must be made to the data model within GIS, and to the control strategies used in 
RSS. It is not strictly necessary that the two systems are physically merged, they may still retain a separate identity, 
or even be remote from each other. Full integration requires a sharing of data models, there may be sound 
operational reasons for maintaining different user interfaces. This corresponds to the different external views onto 
the system shown in Figure 3-Figure 5.