Steve Peedell, Simon Kay and Giovanna Giardino
SEEING THE (OLIVE) TREES FROM THE WOOD - USING GIS IN EUROPE FOR OLIVE
TREE IDENTIFICATION
Abstract
In response to a requirement to identify all the olive trees in Europe
(totalling an estimated 450 million), the Joint Research Centre (JRC) of
the European Commission has initiated a project to study methods of computer-assisted
tree identification from digital orthophotographs. One of the principal
outcomes of the initial phase of this study is an algorithm, which has
been integrated within an ArcView GIS environment as a Dynamic Link Library
(DLL). In a short period of time, this combination has given us a means
of first testing how well the algorithm performs, and secondly assisting
the countries who have to undertake the counting task. The prototype system,
called OliCount, is described here. Our experience shows that the combination
of custom modules as DLL's and ArcView is a powerful one, and is relevant
to many different applications beyond our own specific sphere of interest.
Introduction
Agricultural ministries across Europe are currently faced with a huge task
- how to identify an estimated 450 million olive trees in order to develop
a comprehensive register, which is used as the basis for subsidy payments.
The millions of trees involved are geographically concentrated in 5 of
the 15 Member States of the European Union (EU). This paper describes the
OliCount project, which aims to assist those involved in the task of olive
tree identification by developing semi-automatic tools integrating custom
image-processing software in a proprietary GIS environment. For prototype
development, the chosen GIS interface has been ArcView. The content is
therefore relevant to an audience who may be involved in agricultural applications,
aerial photography, image processing and Avenue development, specifically
the integration of Dynamic Link Libraries (DLL's) in ArcView.
Following a brief explanation of the political context of why so many
olive trees need to be counted, there is a more detailed discussion of
how olive trees are identified from digital orthophotographs, and how ArcView
is used to manage the results of the algorithm we have developed. It is
hoped that our experience in this specific area will encourage a wider
audience to exploit the benefits of developing DLL's which can easily be
used with a small amount of Avenue programming to significantly enhance
the power of ArcView and avoid wasting time developing standard GIS functions.
Agricultural Policy in Europe
One of the key sectors of activity concerning the European Union is agriculture.
The various regulations associated with the Common Agricultural Policy
(CAP) include requirements for Member States to set up an Integrated Administration
and Control System (IACS), to manage payments of subsidies on a number
of agricultural products. Increasingly, Geographic Information Systems
(GIS) are being used for IACS, with digital orthophotography often providing
the large-scale mapping background.
As far back as 1975, prior to IACS, legislation was put in place for
setting up olive tree registers for subsidy management. Farmers receive
payments linked to the number of declared trees, and whilst the use of
GIS is not mandatory, the benefit of having a management approach harmonised
with that of IACS is being realised, and is likely to be legally required
in the future.
The European Commission (EC) does not only stipulate regulations to
individual Member States. It also provides funding and technical assistance
to implement these regulations. The Joint Research Centre (JRC) of the
EC is one of the ways support is given by providing relevant applied research
programmes.
The Role of the Joint Research Centre
Within the JRC, the Agricultural Information Systems Unit (AIS) is closely
linked to the EC Directorate General VI (Agriculture). Given the sheer
enormity of the task of olive tree counting, an important task in the 1997/8
AIS research programme is to develop tools for counting trees and for mapping
areas planted with olive trees. OliCount, the application described in
this paper, is the result of a seven person-month development project,
consisting of a tree-identification algorithm (implemented in C++), and
an ArcView 3.0 interface. Our main tasks have been to:
-
Collect existing know-how on automated or computer-assisted counting of
olive trees on digital aerial photography
-
To develop an algorithm based on the knowledge collected
-
To implement this algorithm and integrate within an existing GIS application
environment
-
To pass on the knowledge, algorithm and software tools to interested organisations
OliCount Overview
In this implementation, ArcView 3 provides the user interface (image /
parcel display, database connection, custom menus, setting of parameters,
counting), whilst the identification of trees themselves is a "black-box"
operation, using the parameters defined by the user prior to operation
(tree characteristics, image information). Using Avenue, we can easily
pass the parameters required by the tree identification algorithm and,
equally importantly, handle the result of the algorithm geographically,
where each tree can be analysed in conjunction with the parcel to which
it belongs.
Software environment
OliCount consists of an ArcView 3.0 project file and two DLL's. The
DLL OTCount performs Olive tree recognition on scanned panchromatic aerial
photography with 256 grey levels in TIFF format. The DLL OTValues evaluates
certain parameters from trees manually identified by the operator on screen.
In particular, ArcView has no direct functionality to obtain a pixel value
from an Image Theme, so we developed OTValues to do this for us. To date,
only 1 metre pixel imagery has been tested. The software was developed
on a Windows 95 platform, and has been successfully tested on Windows NT
4.0.
Capabilities
The custom ArcView OliCount interface allows the user to set parameters
for tree identification, calling the OTCount DLL for identification, and
interactive editing of results. The user can work on irregular parcels
(in shapefile format), with OliCount performing clipping of trees within
the bounding rectangle used within the TIFF image according to whether
they are inside or outside of the selected parcel. Each tree (point) is
tagged with the parcel identifier to which it belongs and stored in a central
file / database which can be set up for the region being studied. The count
of the number of trees identified in each parcel is also stored as an attribute
of the parcel polygons, allowing checks against the number of trees declared
by the farmer or the number identified by ground survey.
Olive Counting Algorithms
Olive tree identification is based on a set of input parameters, which
essentially define the morphology (shape) and radiometry (grey level):
-
The minimum and maximum grey values ("thresholds") in the image which distinguish
tree from background
-
The size range (diameter) of the tree
-
The aspect ratio of the tree crown
-
The density range within each tree "envelope" (i.e. the bounding rectangle).
This is a measure of the size of holes in the tree crown relative to the
overall tree area.
The conceptual process of Olive Tree recognition is shown below:
.
Unfortunately the reflectance of both olive trees and background is
not constant, and can vary across an aerial photograph, between trees and
in the difference between tree / background. In the example below, use
of a fixed threshold range would result in rejection of Olive B, which
is brighter than the Background in Area A.
In the image below, the background in particular varies due to shadow
effects. This is such a common occurrence that we looked at developing
a method of varying the threshold within our area of interest.
Reflectance of an olive tree is a function of age, species and health,
whereas the reflectance of the background is affected by soil composition,
vegetation, moisture and shadows. Because of this, our algorithm is based
on a process of "Iterative Thresholding".
The Iterative Thresholding process can be summarised as follows:
Within an image, the current domain (extent) is defined by the rectangle
which encompasses the selected parcel(s). 2 copies are made in memory which
will subsequently be used as masks to keep track of areas which have already
been processed. Starting with a maximum threshold value, the relevant portion
of the image is scanned for what we have termed "blob seeds", i.e. pixels
with a value lower than the specified maximum. When a blob-seed is found,
a seed function generates a complete "blob", and the corresponding pixel
in one of the mask images (blob mask) is updated. The blob mask is effectively
a map of processed seeds.
The morphological parameters are then checked (size, aspect, density),
and if the blob satisfies all these criteria, a maximum score of 3 is awarded.
Once the complete domain has been scanned, a list of trees is generated
from all blobs with this maximum score. The threshold value is then lowered
by one, the blob-mask reset to zero, and the process begins again. A second
mask image (tree mask) is updated with all blob pixels, which prevents
searching in these regions during subsequent cycles. The process continues
until the minimum threshold value is reached, with the final output being
an ASCII file with the ID, X Coordinate, Y Coordinate of all the trees.
This is the file which is the input data source for ArcView. Coordinate
transformation between real world and pixel coordinates is achieved by
reference to the TIFF image World File, which must be present.
A detailed explanation of our implementation of this algorithm, including
source code (C++) and documentation, is available from http://www.ais.sai.jrc.it/marspac.
The Role of ArcView
So how does ArcView help once we have a DLL which works? By using ArcView
and Avenue we are able to avoid developing functions from scratch to perform
the following:
-
Visualising the image(s), parcel(s) and selection of our area of interest
(domain).
-
Automatic identification of the rectangle which bounds an irregular parcel
polygon.
-
Dialogue boxes for the entry of the parameters used by the algorithm.
-
Automatic geographic selection of the appropriate image(s) which are in
the area of interest.
-
Clipping of the result (a rectangle) to the parcel polygon(s).
-
Display and interactive editing of the result (adding and deleting trees).
-
Storage of counts as an attribute of parcel polygons, and committing results
to a master database.
These functions are best illustrated by looking at some typical examples
in the sections below.
Data Selection and Preparation
In order to identify trees in OliCount, you will need at least one TIFF
image and a theme (polygon shapefile) containing at least one parcel. Upon
loading of a selected parcel theme, fields are automatically added to store
the total count of trees for that parcel. The operator has to select a
field which uniquely identifies individual parcels.
Any images which are loaded automatically have a footprint theme created,
i.e. a rectangular polygon for each image which defines the geographic
extent. The polygon has the image pathname as an attribute, and is used
to automatic spatial selection of images according to the selected parcel(s).
In the current implementation, it is assumed that all images coincide exactly,
without overlap or gaps. The example below shows a typical parcel, with
image boundary lines shown in red. In this case the algorithm will be used
3 times, once for each image in which the selected parcel shares the same
geographic space. All three individual results are automatically merged,
so that the operator considers only the parcel, and not the arbitrary tiling
of image files.
Setting Parameters
A default set of parameters used by OTCount is set once OliCount is started.
These parameters can then be changed manually, which is often the case
for experienced operators, or via a "training" set of known trees.
In the latter case, the OTValues DLL automatically evaluates the grey
value and size parameters from the circles representing tree crowns digitised
on screen by the operator. Throughout the OliCount session, a separate
window displays a sub-image at a fixed scale of 1:800, centred on the area
currently displayed in the main OliCount window. Although somewhat simplistic,
with the operator restricted to identifying candidate trees as circles,
this is a quick and easy way of obtaining suitable diameter and threshold
values.
Select the parcel(s)
Once a parcel has been selected using the standard ArcView tool, OTCount
can be launched with the current parameter set and the current geographic
extent. Multiple parcels can be selected using SHIFT-Select.
Call OTCount
The performance of OTCount varies according to the geographic extent of
the selected parcel(s), the TIFF image size and the range between the minimum
/ maximum threshold values (which determines the number of cycles in the
iterative thresholding process). The resulting comma-separated values (.csv)
file is loaded as a Table in ArcView and converted to a temporary point
shapefile. This is then automatically clipped according to the parcel polygon(s)
and displayed as a point theme called "Active Parcel(s) Olive Trees". At
any given time, only one count may be active - it must be accepted or rejected
before moving on to another parcel. The diagram below shows the initial
OTCount result for the complete rectangle in yellow, with the clipped parcel
result in red. Trees outside the parcel are automatically deleted.
Accept / reject or edit the results
So how well did OTCount perform? We cannot expect to automatically count
all the trees all the time, so immediate acceptance of a result is rare.
If the count looks really bad, we can reject it completely, and maybe use
different parameters for a re-count. Or, more often, there is a small proportion
of trees that have not been identified which we can add, or some which
OTCount may have mistakenly identified, which we want to delete. Since
our result is now a shapefile, we can make it editable, and add or delete
trees as required.
For subsequent monitoring and quality control, each tree is tagged with
a code which indicates how it was identified (automatic / manual), and
whether it was selected for deletion. We can then analyse how well the
algorithm has performed.
Commit the results
Once we have finished editing, the results are saved to a master database,
which may cover a whole region with many individual parcels. At the time
of committing, a spatial join is performed between the olive trees (points)
and the parcel(s) polygons. In this way each tree stores its parent parcel
as an attribute. Similarly, each parcel is tagged with the total count,
with separate counts for automatic and operator identified trees. It is
these totals which are essential for the comparison with the number of
trees declared by a farmer for subsidy payments.
Our "master database" is actually another shapefile, but of course as
we are dealing with points, these could just as easily be managed in an
ODBC table, which would be more effective in an operational environment.
Benefits of DLL Integration
DLL's are an excellent way of extending the capabilities of ArcView. Despite
a few initial teething problems, our experience with OliCount shows they
are flexible and fast, and can be called easily using Avenue. ArcView can
be used as the interface to set the values for the various parameters and
work with the results, and there are many many other applications beyond
that described here which can be developed in the same way. The benefits
we have identified can be summarised as follows:
-
Clear division of tasks and responsibilities (between C++ programmer and
ArcView developer)
-
Speed of operation - the bulk of the custom processing is handled by the
DLL
-
Reduced development times - ArcView provides all the vector data handling
functionality we require
-
Software independence - the GIS does not have to be ArcView
One limitation we identified was the fact that a maximum of 12 parameters
can be passed to a DLL using Avenue - we needed more than this and therefore
used lists of grouped parameters in a known order, which the DLL broke
down into the individual parameters.
Conclusions and Potential Future Developments
OliCount began as a means of demonstrating our work on tree recognition,
and subsequent interest from across Europe showed that GIS is an essential
aspect of the enormous task being faced. Although conceived and developed
as a prototype, it has sparked off a number of initiatives which mean that
the algorithm is used operationally in Italy, and is under test in France.
With this in mind, we continue to support the agricultural administrations
of the countries involved, and are investigating the following specific
developments in the future:
-
Implement OliCount as an extension rather than a project file plus DLLs.
-
Restructure database to maintain history of all trees, including those
which were deleted at some point.
-
Incorporate a knowledge-based approach more finely tuned to local conditions
(slope, soil, climate etc).
-
Investigate alternative base-data sources (high resolution satellite imagery,
infra-red etc)
-
Improve the user-friendliness of the application using Dialog Designer
-
Develop further olive tree applications, particularly in the context of
the OliStat project, which is a statistical study based on systematic sampling
methods across Europe.
Author Information
Steve Peedell
TERMA Elektronik Italia
GIS Manager
Agricultural Information Systems Unit
Space Applications Institute
Joint Research Centre of the European Communities
I-21020 Ispra (VA)
Italy
Telephone: +39 332 786153
Fax: +39 332 789074
E-Mail: stephen.peedell@jrc.it
Simon Kay
Agricultural Information Systems Unit
Space Applications Institute
Joint Research Centre of the European Communities
I-21020 Ispra (VA)
Italy
Telephone: +39 332 789702
Fax: +39 332 789936
E-Mail: simon.kay@jrc.it
Dr. Giovanna Giardino
Harlequin Group
SK9 7QD
United Kingdom
E-Mail: giovanna@harlequin.co.uk