Picture of Book

OO GIS at Ispra

Project Vision: To establish at Ispra a permanent centre of expertise in object-oriented GIS technologies based around an in-house developed and maintained OO-GIS research application based on a commercial OO-GIS product.

High-Level Use Case:
Architecture of Data Processing

The purpose of the application is land re-classification and change detection. (Note that this is just the technical procedure, not the requirements for the project as a whole.)

Input data are:

The sequence of suggested actions follows. The complete actions are difficult and require  complex software configurations, so the complete sequence is not a realistic target (see current task list and software development plan).
  1. Take raster images and perform segmentation to find shapes (will be determined purely by the spectral data in the raster image, no other data to be used).
  2. Detect if new image accurately (to some level of probability) matches previous polygon shape: produce a yes/no answer for each polygon.
  3. For matching shapes, perform classification and detect if class is same or changed: yes/no for each polygon.
  4. If shape is same, but classification has probably changed (to some set level of probability), re-set classification, if probability is uncertain, alert the user or produce report or some similar action.
  5. If shape was different, perform re-segmentation on the area bounded by the affected polygons and alert the user.
  6. If shape was different, after re-segmentation, generalise result to standard CORINE generalisation standard.
  7. If shape was different, reclassify re-segmented and generalised polygons.
  8. Finally, write out result polygon dataset in same format and with same types of attributes as input polygon dataset, and print change report with statistics and confidence levels.
The above software does not include:

Unavoidable Research Issues

Some of these processes can potentially be performed by algorithms developed for other purposes, but even these may need adapting and will certainly need configuring and tuning. Even if all the steps were established algorithms, available in a commercial GIS product, putting them together and tuning parameters to make them work together would be a significant piece of work.

The initial segmentation step on the input raster images is a significant piece of work in itself. It requires a user-level view of what the most important spectral distinctions are, which must be derived from a spectral class to land-cover class mapping. It requires thresholds and segmentation algorithms, minimum area limits etc. To cope with misregistration, Smits' research work on textures will probably have to be used.

Yes/no detection of changed polygon shape from a raster image is a complex procedure in itself requiring many of the algorithms listed for later steps. Detection of encroachments requires a different algorithm from detecting enlargements. If the encoachment is smaller than the minimum size of polygon allowed for the specific data product (CORINE specifies a minimum 25ha), then the adjacent polygon must be found (easy for topologically connected polygons) and modified - if it's class is compatible. For enlargements it is even trickier: the affected adjacent polygon may then be too small and need to be merged with a third  polygon.

The classification task can take into account only the spectral class of the segmented area and the previous polygon classification, or it can take adjacent polygons into account to determine the "local landscape type" which would change the prior probablitities for classification.

The process "For matching shapes, perform classification" is very similar to algorithms developed for the CROPINS configuration of IGIS and the CLEVER Mapping project and are incorporated into IGIS 3.1 .

Segmentation of a pure raster field is a moderately standard technique, but not when bounded by vector polygons (which must not be changed) as here.

Even generic algorithm design is emphatically not a solved problem. There are significant unresolved issues, especially where an operational system is eventually envisaged.


Version 2 of this document. (Versions start at 0.)
Go to Project Home Page
Updated 12 August 1998