May 2002
by Fred Snijders, Roberto Giaccio, Jeroen Ticheler, and Yota Nicolarea
| Page 1 | Page 2 | Page 3 |
Page 4 | Page 5 |
Graphing requires numbers and these numbers need to make sense. To get these numbers from Remote Sensing imagery we extract statistics on the basis of zones.
The earth surface can be segmented into zones that have a particular characteristic. Such a characteristic can be a political one (e.g. the provinces of a country) or a natural one (forests, grassland or another distinctive property). These zones form the basis of the statistic extraction process.
A satellite image is build up as a raster of values. Each of these values is a quantification for a particular phenomenon, for example the amount of cloud cover, the estimated rainfall or the index for green biomass. A statistical number could be the average value of all values occurring in one zone at one point in time.
Figure 3.1 - An average value for each zone is calculated
Figure 3.2 - Monthly averages for different zones can be displayed in a chart to visualize changes in time
During the extraction of statistics from the remote sensing images, a considerable reduction of information quantity takes place. This reduction should therefore be as good and functional as possible.
When the terrain or landscape within one zone is very heterogeneous, say with part desert and part forest covered mountains, the extracted average value makes little sense. The high values of the forest cover in the mountains is leveled out by the low values in the desert. Important changes in for example the desert will not be discovered when looking at the statistical trend, because the forested part has such a big impact on the extracted average. This effect often happens when extracting zones based on political boundaries.
A better approach to statistics extraction would be to use zones with a fairly homogeneous spatial variability.
The approach taken is to create zones with a fairly homogeneous reflection pattern. The zones need to reflect important geographic features. They should be country based, but at the same time respect natural boundaries. Furthermore, the number of zones for one country must be such that it covers most of the spatial variability, while at the same time providing a good summary.
To satisfy the latter, it was decided to aim at 2 to 15 zones per country. Two for very small, homogeneous countries and 15 for the large, heterogeneous countries.
To create a map with homogeneous zones, monthly average vegetation index images were used. These were derived from the ARTEMIS archive of NOAA-GAC NDVI data covering 1982-2000.
A classification on these images was done on a country-by-country basis. The ADDAPIX clustering software was used for this.
The procedure was to first extract a country window from the full Africa images. Secondly, the time series was clustered five (separate) times, producing clustered images with respectively 4, 6, 8, 10 and 12 classes. These images were visually compared with the clustered images for all neighbouring countries and with a Digital Elevation Model (DEM) for the country. The optimal number of classes was determined through visual interpretation and expert knowledge. Neighbouring zones were taken into consideration, as well as the countries size and geography. Zone boundaries were drafted on paper and digitized on screen using the clustered images as background. The result of this procedure was a map of Africa, divided in approximately 400 zones. This map is used to extract the statistics of all individual images of all supported products and a clickable version of the map is used in Page 5 of this document to select individual zones.
Within the operational ARTEMIS environment, there was not one, but several different requirements to manipulate and display the statistical data that was routinely extracted from the individual ARTEMIS images. There was a need for a programme, or applet, to display data by accessing directly the Artemis SQL statistical database. At the same time, there was also the need for a version that would already incorporate the statistical data, with the data compressed into some remote or local file. This to allow people with limited Internet access to download the applet locally and have full access to statistical data, as described in the first part of this article. Moreover, a command line tool was required for creating gif or jpeg charts, to be used within the existing Artemis workflow; the same features as those of the applet had to be in some servlet software for creating gif or jpeg files at runtime. Finally, in order to integrate the new programmes in the highly automated ARTEMIS environment, several utilities were required, for instance to scan existing Artemis data files with extracted statistics and storing the data inside the SQL database and to extract data from the SQL database and compress them inside a ZIP file for use in the RANET transmission. After analysis of the above requirements, it was decided to design and implement a software library to provide a common set of features and write some applications, applets and servlets using the library. In this way, the same code with the same functionality would be available to all the different implementations
The following application-specific goals constrained the design of the library:
In order to satisfy the above requirements and constraints, a three-layered architecture was defined, see Figure 3.3. It shows, from top to bottom, the three main layers: service access; ARTEMIS functions for charting and data access; and general purpose data access and charting.
Figure 3.3 - Applet three-layered architecture
The upper layer provides the following: the applet, a command line tool that creates charts as GIFs by accessing a SQL database, and an upcoming servlet that creates chart GIFs by processing HTTP requests. It also provides utilities for populating a SQL database of statistical data obtained from a set of files in multiple directories that have been created during the image extraction processes.
The middle layer provides two main features: Artemis data access and Artemis charting. The first provides access to Artemis statistical data, independent of the data source. The source can be the SQL database, a set of files or a one ZIP file. Other data source types are possible. Artemis charting provides the ability to properly draw charts described by Artemis attributes such as countries, years, products, etc.
Finally, the lower layer provides some general purpose data access features, that extracts records and fields independently of the data source type, and a general purpose charting library. This library is now limited to scatter charts, but it is extendible and other chart types will be added in the future.
In the figure, the gray areas indicate those used by the Applet. Basically, it uses the Artemis charting functions, which in turn use the Artemis data functions and the general purpose charting functions. Data are read from a Zip file, and are reported to the upper layer independently of the data source type using general purpose structures for data access.
The design of the library proved to work well. For instance, if we want the applet to read data from a SQL database instead of from a ZIP file, we only need to modify one line of code. Also, the command line tool is basically the applet without all the graphical user interface. The architecture is rather efficient in terms of resource usage: the full Artemis statistical data consists of several hundred thousands records, and are compressed into a ZIP file of about 1 MByte; it is also interesting to observe that, even when accessing the full Artemis statistical data, the ZIP file version of the Applet is not significantly slower than the SQL database version, sometimes seemingly being faster.
Proceed to:
Fred Snijders, Roberto Giaccio, Jeroen Ticheler and Yota Nicolarea: Bringing Africa data to the desktop: the ARTEMIS Charting Applet, Page 3.
|
){kind=link}