Donald Kay Munro

Library of the Australian Defence Force Academy

University College The University of New South Wales

Donor: Donald Kay Munro PLEASE TYPE UNTVERSITY OF NEW SOUTH WALES Thesis/Project Report Sheet SumameorFamilyname: Firstname: DONALD Othername/s: MI Abbreviation for degree as given in the University calendar: Ml NF. S.Q School: COMPUrER..SCIENCE p^cuity: ZIIII^IIIZZIIIIZIIZIIIIIZ m:

Fanners conduct their business in a spatial environment They make decisions about the area of land to place under various crops, the area for livestock and the areas which need to have ^^^^^^^^^^^^^^^^^^^^^^^^^ certain treatments (spraying, ploughing) carried out on them. On domestic personal computers, software such as Word Processors and Spreadsheets can assist them with record keeping and financial records; however, there is no commonly available software that can assist with the spatial decisions and spatial record keeping.

Geographic Information Systems (CIS) can provide such support, but the existing software is targeted at an expert specialist user and, while offering powerful processing, is too complex for a novice user to derive benefit. Most of the software has its origins in the scientific or research community and would previously have been running on mainframe or powerful minicomputer environments. Many programs require complex instructions and parameters to be typed at a command line, and learning how to use these instructions would consume months of training.

This Project used the Evolutionary Model of Structured Rapid Prototyping to define the user requirements of a DeskTop GIS for use by farmers. This work involved a repetitive cycle of talking to farmers about the information that they regularly used and the sort of information they would like in the future; finding ways of collecting and storing that data; writing programs that would manipulate and display the information; and making those programs accessible to the farmer in an easy-to-use environment on a domestic personal computer. The feedback from the users was then assessed, the programs changed and extended, and the cycle repeated.

The Project initially found difficulty in selecting a suitable programming environment that would support the Rapid Prototyping Methodology for a graphical application. Tnis necessitated considerable reprogramming between the versions of the prototype. Also, a great variety of sources of farming data was discovered, all of which had different processing requirements. This richness led to many custom designed routines being required for the different data types, and hence a modular approach to prototype construction.

While the Prototype is by no means a complete specification of the requirements of a User Driven DeskTop GIS, it has uncovered many considerations in terms of data and processing ; that were initially not apparent. It has also been useful in trialing a different approach (Rapid ZZZHIZIZZZZI Declaration relating to <1 Prototyping) to the definition of a graphical appUcation. I am fuUy aware of the policy of the Univensity relating to the retention and use ofMgher degree projectreports an d theses, namely t copies submitted for examination and isfree t o allow them to be consulted orborrowed. Subject to the provisions of the Copyright Act 1968, the University may issue aprojectreport o r thesis in whole or in part, in photostats or microfilm or other comd^^ lalso atfthcrif^puiicationby University Microfilms of

^lELSignature . —^^MT— Date TheUniversityrecognisesthattheremaybeexceptionalcircumstancesrequiringrestrictionsoncopyingorcon^^^^ upto2yearsmustbemadeinwritingtotheRegistrar.Requestsforalongerperiodofrestrictionmaybeconsideredinexw^^ aletterofsupportfromtheSupervisororHeadofSchooLSuchrequestsmustbe submitted with the thesis/project report

FOR OFFICE USE ONLY DateofcompletionofrequirementsforAward: Re gis trar and Deputy Princi pal

THIS SHEET IS TO BE GLUED TO THE INSIDE FRONT COVER OF THE THESIS The DeskTop GIS for Farmers: an application of Rapid Prototyping in a Graphical Environment

p r^. r' .

University CoiiGga

Donald Kay Munro, B A A.N. U.

A Major Project (600 hour equivalence) towards the degree of Master of Information Science by Coursework

Department of Computer Science University College The University of New South Wales Australian Defence Force Academy

December 1995

324539 Certificate Of Originality

I hereby declare that this submission is my own work and that, to the best of my knowledge and belief, it contains no material previously published or written by another person nor material to a substantial extent has been accepted for the award of any other degree or diploma of a university or other institute of higher learning, except where due acknowledgment is made in the text of the report.

Donald Kay Munro

OS / 10/1996

11 Abstract

Farmers conduct their business in a spatial environment. They malce decisions about the area of land to place under various crops, the area for livestock and the areas which need to have certain treatments (spraying, ploughing) carried out on them. On domestic personal computers, software such as Word Processors and Spreadsheets can assist them with record keeping and financial records; however, there is no commonly available software that can assist with the spatial decisions and spatial record keeping.

Geographic Information Systems (GIS) can provide such support, but the existing software is targeted at an expert specialist user and, while offering powerful processing, is too complex for a novice user to derive benefit. Most of the software has its origins in the scientific or research community and would previously have been running on mainframe or powerful minicomputer environments. Many programs require complex instructions and parameters to be typed at a command line, and learning how to use these instructions would consume months of training.

This Project used the Evolutionary Model of Structured Rapid Prototyping to define the user requirements of a DeskTop GIS for use by farmers. This work involved a repetitive cycle of talking to farmers about the information that they regularly used and the sort of information they would Uke in the future; finding ways of collecting and storing that data; writing programs that would manipulate and display the information; and making those programs accessible to the farmer in an easy-to-use environment on a domestic personal computer. The feedback from the users was then assessed, the programs changed and extended, and the cycle repeated.

The Project initially found difficulty in selecting a suitable programming environment that would support the Rapid Prototyping Methodology for a graphical application. This necessitated considerable reprogramming between the versions of the prototype. Also, a great variety of sources of farming data was discovered, all of which had different processing requirements. This richness led to many custom designed routines being required for the different data types, and hence a modular approach to prototype construction.

While the Prototype is by no means a complete specification of the requirements of a User Driven DeskTop GIS, it has uncovered many considerations in terms of data and processing that were initially not apparent. It has also been useful in trialing a different approach (Rapid Prototyping) to the definition of a graphical application.

Ill Acknowledgments

This project has only been possible with the assistance of the following people:

Dr. Graham Freeman, (Computer Science, ADFA), for being my supervisor and for offering additional insight;

Dr. Edward Lewis, (Computer Science, ADFA), for reviewing the early drafts;

Dr. Gerald Nielsen, (Professor of Soil Science, Montana State University, USA), for his invitation to spend part of a study leave in his laboratory working on the prototype and for his many introductions to people interested in the prototype;

Dr. David Tyler, (Director, Springhill Engineering, Belgrade, Montana, USA) for his assistance in the collection of GPS data and for providing survey and geodetic information;

Mr. Bill Wright, (Farmer, Belgrade, Montana, USA), for allowing borrowed equipment to be mounted on his brand new header, and for his enthusiasm and patience during the four days which I shared his driving space collecting data during the harvest;

Ms. Diana Cooksey, (Project Coordinator, Montana State University, USA), for a crash course in GPS operation, and for the post-processing of the crop-yield data;

Dr. Peter Fisher, (Professor, Department of Geography, Leicester University, UK), for his invitation to spend part of a study leave in his department looking at the processing of GPS data;

Mr. Jason Dykes, (PhD student, Department of Geography, Leicester University, UK), for his help in generating the GRASS images from the Montana crop yield data;

Mr. Jo Wood, (Lecturer, Department of Geography, Leicester University, UK), for his help with PBMPlus and Kriging code;

Dr. John Louis, (Director, Centre for Image Analysis, Charles Sturt University, Australia), for the initial satellite images and paddock boundary data;

Mr. Tom Maginness, (Director, CSU Farm, Wagga Wagga, AustraHa), for his farm notes, cropping histories and valuable insights; and

Ms. Janice Anderson, (Wife and friend), and Nathan, Stewart and Vanessa for putting up with me during the project.

iv Contents

Certificate of Originality ii Abstract iii Acknowledgments iv Contents v List of Tables vii List of Figures viii Abbreviations and Acronyms ix

1 Introduction 1 1.1 Project Vision 1 1.2 Existing Products - Market Survey 8 1.3 Propositions 12 1.4 Summary 12

2 Methodology - Rapid Structured Prototyping 13 2.1 Background 13 2.2 Rapid Prototyping 15 2.3 Choice of Prototyping Environment IT 2.4 Summary 20

3 Building and Testing the Prototype 21 3.1 Prototype Versions 21 3.1.1 AMIGABasic on the AMIGA 500 21 3.1.2 GFA-Basic on an IBM-PC 23 3.1.3 Microsoft Visual Basic V3.0 running under Windows 3.1 on an IBM-PC 24 3.2 Required Processing for "types" of data 26 3.2.1 Satellite Images 26 3.2.2 Scanned Aerial Photographs 26 3.2.3 Manipulating Colour . 27 3.2.4 Colour Intensity 28 3.2.5 Data Boundaries 29 3.2.6 Points 30 3.2.7 Line work 31 3.2.8 On-Screen Digitisation 31 3.2.9 Keyboard Entry of Ordnance Survey Co-ordinates 32 3.2.10 Co-ordinates collected from a digitising table 32 3.3 Selection of Test Users 34 3.4 Summary 35 CONTENTS

4 Functional Requirements Identified 37 4.1 GIS as a Spatial Decision Support System - SDSS 37 4.2 Establishing the Co-ordinate System 38 4.3 Creating Data Layers 40 4.4 Images 41 4.5 Crop Yield Maps 42 4.6 Soils Maps 49 4.7 Contour Heights • 50 4.8 Natural Vegetation 51 4.9 Weeds 51 4.10 Salinity 52 4.11 Boundaries and Objects 52 4.12 Activities 53 4.13 Land Treatments 53 4.14 Animal Records 54 4.15 Extreme Environmental Events 54 4.16 Weather 54 4.17 Spatial Analysis and Reporting 54 4.18 Interpolation 55 4.19 Temporal Considerations 56 4.20 Cumulative Histories 58 4.21 Future Developments 59 4.21.1 Future Programming Environments 59 4.21.2 Economic Modelling 60 4.21.3 3D Projection 61 4.22 Summary 62

5 Conclusions 63 5.1 Propositions Revisited 64

6 Bibliography 67

7 Appendicies

VI List of Tables

Table 1: Internet Traffic 3

Table 2: Times taken for window refresh 25

Vll List of Figures

Figure 1: Site Specific Farming Process 6

Figure 2: The evolutionary rapid prototyping process 15

Figure 3: Problem boundaries 33

Figure 4: Uncorrected track plot 45

Figure 5: Corrected track plot 45

Figure 6: Coordinate positions from 24 hours 47

Figure 7: GPS random noise 47

Vlll Chapter 1

Chapter 1

Introduction

This project describes the apphcation of the Rapid Structured Prototyping systems analysis methodology to the requirements analysis of a graphically based application.

The application chosen was a Geographic Information System for Farmers. It was to be capable of being run on a normal "domestic" personal computer, and to be able to be operated by normal farm staff (usually the farmer, their spouse or children). The application was called a "DeskTop GIS" so as to place it within the general arena of other desktop products such as desktop pubHshing, wordprocessing and spreadsheets.

The reason for choosing the apphcation was that there was (and continues to be) significant interest in such applications from the farming community; there is a wealth of real data available from a wide variety of sources with many opportunities to utihse graphics to visualise the data as well as the incorporation of sateUite images and scanned aerial photography; and there were expressions- of interest from several farmers to take part in the trials.

1.1 Project Vision

The following scenario of a "day-in-the-life-of-a-farmer-in-the-year-2000" sets the parameters for this project.

Farmer Brown wakes to an overcast but dry sky. The previous two days had rained. He Chapter 1 1.1 Project Vision starts the DeskTop GIS and via the attached modem down loads the latest weather map from which he deduces that there is a high hkelihood of a return to substantial rain within two days. He enters his predictions into the "short term scenario" layer of the DeskTop GIS and finds that a "livestock alert" has been triggered for a large flock of sheep in a holding paddock. He investigates the alert and finds that the prospect of additional rain has lowered the paddock holding capacity from its dry estimate to its wet estimate (which has raised an "overstocking" alert), and that the likelihood of footrot in an overstocked wet paddock has also raised an "animal hygiene" alert. He needs to find a holding area which will accommodate the flock, so he searches the "current utilization" layer for land not under crop. He identifies six paddocks but notices that one of them he had recently ploughed, and that two others are low lying and so also likely to be wet. For the six paddocks he displays their sheep-carrying capacity, and abandons further consideration of the lowest four. As the remaining two have a combined carrying capacity that is less than the size of the flock he must "make" a dry paddock by placing part of the flock in a paddock under crop. He searches the topographic layer for "moderate" and "steep" sloped paddocks in which the water runoff would compensate for the effects of the predicted rain, and identifies eight. Via the modem he down-loads the most recent AUSLIG satellite image, which was taken ten days previously with clear skies and displays images of the crops in the eight paddocks. For the wheat crops he applies a classification system from two years earlier (which was also a wet year) based on the yield monitor readings from the harvester, and for the barley the same classification as the previous year. This calculates the potential crop loss of having sheep in each paddock. Via the modem he down-loads the latest wheat, barley and sheep futures prices and applies the former to the potential crop losses and the latter to the prospect of selhng the surplus Uvestock at today's prices rather than in the future as planned. The figures favour selling the surplus sheep and so he enters the sale into the "short term scenario" layer, and the movement of the other sheep into the available holding paddocks. This raises an alert from the "Enterprise Accounting" layer, which now shows that by lowering the number of sheep the projected farm income has a greater than 60% impact exposure to crop failure due to drought. With so much rain late in the season farmer Brown decides to accept the risk and via the modem enters the sheep details into the on-line sales yard.

This scenario identifies the following potential benefits to the farmer of utilising a Desk- Top GIS as an information gathering and analysis tool:-

• the ability to download latest weather maps as a basis for the "rain" decision;

• the entering of predictions into the "short term scenario" layer; Chapter 1 1.1 Project Vision

• the system providing "alerts" for the hvestock overstocking and animal hygiene and the enterprise accounting layers;

• the abihty to download AUSLIG SatelHte images and apply classifications;

• the integration of harvester yield monitor readings and the running of a crop predic- tion model; and

• the ability to download "futures" prices.

The scenario also identifies the software and infrastructure facilities required for such de- hberations to take place.

1. GIS data needs to be generally available.

Researchers are becoming aware of the ubiquitous nature of GIS data and the range of problems that it can be used to address. Hutn states, "There is no lack of issues for which spatially accurate global data are required. Biodiversity, demography, deforestation, freshwater and poverty, all are important" [Hutn 93, p. 6].

2. There has to be a mechanism which can deliver the GIS data.

The "explosion" of popularity of the Internet, and the World Wide Web (WWW, or Web) for delivering information has taken many by surprise. Berghel states that "There is no longer any question that the World Wide Web has evolved into an indispensable resource for the networking community" [Berghel 95, p. 63]. The following data illustrates his point. .

Application Total Packet Count Total Byte Count World Wide Web 21.4% 26.3% File Transfer Protocol 14.0% 21.5% Network News 8.1% 8.6% Telnet 7.5% 2.5% Gopher 1.5% 1.8%

Table 1: Internet Traffic: Source: [NFS 95]

He finds this "even more remarkable given that the Web really didn't take off until 1992 when the first navigator/browsers became available" [Berghel 95, p. 63 .

This explosion has occurred while this project has been under development. In 1989 it seemed a little fanciful to imagine that satellite images might be downloaded over Chapter 1 1.1 Project Vision

country quality telephone lines which were often unable to dehver a robust service, even at 300 baud. In 1996 those same lines in many cases, connected to more modern exchanges, are delivering data at 28,800 baud with very few errors. At these increased speeds images which would have taken several hours to download are available in a matter of minutes.

The use of the Web to dehver GIS data will require the providers to mount such services. This appears to be happening. In the November 1995 ACRES UPDATE newsletter [ACR95, p. 4] AUSLIG and ACRES were advertising their new Web Home page (http://www.auslig.gov.au) and were creating an on-line catalog of their services. As demand for services increases, so does the incentive for organisations to meet that demand; especially when the demand is broadly based in the user community.

3. The costs of access to the data need to be economic.

The costs of access to the Web have dropped dramatically. Once the domain of only Universities and other academic institutions, pubhc operators (Compuserve) started providing access in 1994 at $25.00 per hour with additional charges for the amount of data transferred. As more connection providers entered the market, prices for "bare bones" connections dropped so that in October 1995 it was possible to achieve fees of just $1.00 per hour regardless of data transferred. If these costs were to be commonplace, and if dehvery could be achieved via the World Wide Web, then even small users could afford to access the information several times during a year.

4. It must be simple and easy to access the information.

Graphical User Interfaces (GUI), as pioneered in the mass marketplace by the Mac- intosh, have become synonymous with the concept of "user friendly" user interfaces. Computer applications with these "point and click" interfaces are providing user driven processing capabihty without the technical complexity of command driven applications. The "what you see is what you get" (WYSIWYG) style of graphical processing permits immediate user feedback of the effects of various operations.

In order to support the dehvery of graphically oriented information in a "point and click" environment, the Web "Browsers" (interface programs which display the information) were extended from the initial "text only" display to include pictures and images, then variably sized text and font styles, then multiple windows of information, then control "buttons" and forms. Sound and interactive video are reported to be "just around the corner" [Kehoe 95 . Chapter 1 1.1 Project Vision

5. The data must be available in a reliable timely manner.

The data transfer speeds of domestic modems have increased in pace with the user demands for "communications heavy" graphics. In 1991 a 2.4K ( "fax modem" was $425.00. In October 1995 a 28.8K modem can be purchased for about the same price, and will deliver an even more robust service across the same physical domestic telephone lines than the older, slower devices. It is therefore possible to download a satellite image of a farm in only a few minutes.

6. Handle Data from many sources.

Data for the scenario came from many sources, and in a great variety of formats. While satellite images would normally be supplied to farmers through an agency which would perform alignment and registration of the images prior to their delivery, many farmers possess aerial photographs and soil maps which would be digitised or scanned using a variety of devices. While not of a time critical nature, routines will be needed to ahgn and register these images. With the advent of "Precision Farming" techniques [Reichenberger k Russnogle 89], and the linking of Geographic Positioning Systems (GPS) to Yield monitoring devices in headers and harvesting equipment (see Figure 1 "Site Specific Farming Process"), many new types of data become available, often at a higher resolution (+/- 100 mm) than the original field surveys. The "traditional" farmer's notebook is also a rich source of additional data requiring a variety of encoding methods.

The impact of "Agricultural Economics" and Project Accounting associated with various farming enterprises has added another dimension to the more "spatial", mapping and shading, graphical reporting. The range of query types that are required to be handled has grown accordingly The increasing sophistication in the use of Personal Productivity Tools such as wordprocessing, and more importantly, spreadsheets, has meant that farmers are capable of creating and processing a lot of secondary data outside the DeskTop GIS, and hence flexible import and export formats to these tools Chapter 1 1.1 Project Vision

are required.

Site-Specific Farming Process

Sources Yield Monitor Soil Survey GPS Soil Survey Samples Remote Sensing/GPS Applicator/GPS GPS

B O Z E M A N

Figure 1: Site Specific Farming Process [Neilsen 94

7. There needs to be sufficient demand for such systems to make their development economic.

Dangermond has predicted one million GIS users by the year 2000 [Dangermond 91 . Muller has predicted this figure could become even bigger "if the general pubHc was given access to GIS at home (eg, through Minitel, video telephone device in France) or in pubhc places (such as hbraries)." He goes on to state, "This would presuppose Chapter 1 1.1 Project Vision

a much more friendly entrance to GIS than is presently afforded by the tedious and laborious approaches through user manuals. To express this in a somewhat exagger- ated fashion, someone will have to invent a simple GIS for all! The Macintosh success story, in spite of the well-estabhshed DOS chentele, is a case in point" [Muller 93, p. 302].

It is therefore apparent that the interfaces and delivery infrastructure are becoming available with the capabilities, and at sufficiently low cost, to support both Dager- mond's and Muller's predictions IF the applications exist which can process the required data in the required way. How are these applications to be developed?

8. Software must be available which is tailored to the farming enterprise.

Tomlin, in a discussion of Cartographic Modelling methods, identifies some 68 Carto- graphic Modelhng capabihties. On page 373, he states, "If the cartographic modelhng approach is truly successful, these new techniques will also involve high-level models that are specific to particular fields of apphcation. Ideally, such techniques will come not from those who design these tools in the world of high technology, but from those who must ultimately put them to use in that other world just outside" [Tomlin 92 .

The DeskTop GIS project was conceived as a prehminary investigation of the user preferences and required processing, as well as the hardware and software limitations which would be present on the typical "desk top" personal computer. While hardware and software advances are progressing at a great pace, the definition of the sort of processing required for a "Domestic GIS" is still largely in the hands of the "tool designers", and the DeskTop GIS project seeks to redress the situation.

9. The software must be usable without extensive training.

Application users generally do not want to invest a great deal of time in attending extensive training courses prior to being able to start work with a particular package. A number of institutions offer GIS training, but their focus is on providing technical experts with additional high powered tools, not on training "end-users". For example, LandlS is the computerised land information system of the Soil Survey and Land Research Centre (SSLRC) at Silsoe Research Institute, Wrest Park, Silsoe, UK. The numerous services which SSLRC provide through LandlS are targeted at groups in the Agricultural, Environmental, Engineering and Financial Sectors. They operate a three month post-experience course on Land Information Systems and Analysis and Design. It is unhkely that such facihties are going to be practical alternatives to the farmer; even if they had the time, they would be such small users of data that standing charges would make them uneconomic. General GIS training is being offered by various other institutions, for example, Manchester Metropolitan University, offers Chapter 1 1.2 Existing Products - Market Survey

a Postgraduate Diploma in GIS involving three residential workshops, and costing $6200.

These courses are very broad and thorough in their coverage of the subject area, and it could be argued that short courses which were specifically targeted at particular application packages would be a more appropriate approach. The difficulty here is in the number of different packages (mostly of a general nature) which offer some GIS functionality An overview of the range follows.

1.2 Existing Products - Market Survey

This survey of existing systems was carried out from 1990 to 1993 in Austraha, and during 1994 while on study leave in Montana USA and Leicester UK. Of particular benefit was a visit to the AGI 94 (Association for Geographic Information) trade conference held annually in September at the National Exhibition Centre in Birmingham. At this event there were over 100 exhibitors showing systems ranging from pure "image processing" systems through to very specific Local Government sewage and water pipe location and maintenance systems. The purpose of the survey was to identify whether there already existed a simple, intuitive, user driven package which could be easily manipulated with little user training, for a farm application. Not finding one justified the farm application as a useful target for testing a rapid prototyping methodology in a graphical environment.

New GIS products are being offered certainly monthly and almost weekly. Indeed many products now (late 1996) possess sophisticated scripting and programming languages which may provide more productive and fiexible'rapid prototyping environments. These products take full advantage of the rapid increase in computer power and storage together with the overall drop in cost of such facilities. The comments made here represent the state of GIS development observed before and during 1994, and are only intended to justify the selection of a farm application for the graphical rapid prototyping exercise.

Computer packages already exist which have elements of GIS functionality, but they are:-

• often expensive compared to word processors and spreadsheets, which are aimed at

the "mass market";

• technical tools requiring a large investment in training, and hence documentation is

8 Chapter 1 1.2 Existing Products - Market Survey

often aimed at the "power user" rather than the novice;

• consumers of vast processing and storage resources as they are seldom tailored to the desktop machine environment, and are often just "down-sized" minicomputer applications; and

• more generahst in nature rather than being directed at the target group (as you would expect as they are aimed at a more "expert" user group with diverse needs).

Most packages fall into the categories of "mapping", "CAD", "database" or "drawing" packages, that have had elements of GIS grafted onto them by the close binding of other packages or by using special templates to provide limited functionality

A very popular high end level tool is the Package ARC/INFO, which currently retails for $6,600, has in excess of 200 diiferent commands (many of whose effects can be modified by various switches and options), and which is said to take about 6 months of continuous use in order to feel confident in its use (but by no means "expert").

At the other end of the scale is the non-profit IDRISI project produced at Clark Uni- versity, Massachusetts. The commercial price of this system is $640 US, with Academic copies for $320 US, and student copies at $160 US. Even though this may be considered a "cheap" GIS, it still contains over 138 different commands and a five day training school is offered by the University to first time users.

STRUMAP, marketed by STL Woodside, is advertised as "A GIS FOR WINDOWS" which takes "less that 5 minutes to install, and comes ready to load, view and print any Ordnance Survey vector or raster map." Although it can be used as an independent program, STRUMAP is designed to "exchange information with other Windows apphcations such as databases, spreadsheets... and ... because it can write its entire database, including geometry, to a series of database tables, it completely eliminates the need to write specific translator programs." The user, however, would need to have considerable expertise in being able to manipulate these other programs to process the data. The documentation goes on to state that "Scanned maps or aerial photographs can be used as the GIS BACKDROP", however only primitive "drawing" tools are provided for image manipulation [STL, Woodside 95].

SLIMPAC, reviewed by Parker, has been described as a GIS but this must be quali- fied. It Hnks the industry standard CAD software, AutoCAD, with the industry standard

9 Chapter 1 1.2 Existing Products - Market Survey database software, dBase. The term spatial is used since it is capable of managing all forms of spatial information, not just mapping or other geographical data sets. Again, expertise in the two underlying packages would require a considerable training time investment, as well as the cost of both packages in addition to SLIMPAC [Parker 94 .

GEO/SQL R.4, from Geo/SQL(UK), is marketed as "an object-oriented platform for developing sophisticated, spatially intelligent information systems designed to extend rather than replace existing DBMS environments." ie, it provides only an interface to SQL databases. While containing many features, the price of the Query station (DOS or Win- dows) at $2,990, the Edit station at $4990, and the Professional version at $12,990 are exclusive of the required SQL database and also exclusive of UK VAT (17%) (as at Nov '94). This product, while not being specifically targeted at the domestic micro end user, suffers from both a high training requirement as well as a very high price when compared to other "desktop" products.

LANDCADD is an AUTOCAD based Civil Engineering oriented package that includes COGO (Co-ordinate Geometry) and Development routines and is more suited to land subdivision exercises and the location of Utility services.

PROCIS-MOBILE-GIS is produced by the Southern Water Board (UK) and uses Toshiba T200 Dynapad Micros for use in the field and a radio Hnk to communicate with the base station. A two user system comprising all hardware and software was quoted at approx $40,000 (Oct '94). This system was more suited to providing mobile technicians with access to plans of locations of services and to schedule work in the field, rather than provide spatial analysis capabilities.

pcHABINFO, from APS Imaging Services, is advertised as "a user friendly" macro for analysis of an Ecological dataset using the GIS pcARC/INEO. The existence of such a product speaks volumes for the "friendliness" of pcARC/INFO.

APS - ALLIANCE is another database User-Interface product. It requires a 486 with 16 Mb ram and takes 10Mb of disk space and still requires either PARADOX or ORACLE.

APS - pcTIN2.2D is a digital terrain modelling system for pcARC/INFO, and so suffers from the learning curve and cost implications of both packages.

MAPINFO - DESKTOP MAPPING SYSTEM VS.O is advertised as an "Easier to use" package with "New Data Visualisation features; New Geographic Analysis features and

10 Chapter 1 1.2 Existing Products - Market Survey

Extended Data Access." It uses raster images, scanned maps or aerial photographs to enhance your maps and provides Improved Interface and Polygon operations (basic spatial operations). It needs a 486pc with 4Mb of memory and uses 12Mb of hard disk space.

The INTERGRAPH "Square One" package uses "Microstation CAD" and "ORACLE" as the interface and database. The software only costs are $3500 for the View only version, and $9350 for the Power User version, which places it outside the budget of the average user.

Cartology, including "FastCAD" costs $7700 and includes new powerful database support for dBaselV, PARADOX, DATABASE, ACCESS, SQL and "many others". Of course, you still need to purchase the other database.

Cartology LITE, including "FastCAD" is just $1097; however, it still requires the database and does not include many image manipulation tools [Surveyor 94, p. 40 .

FIELDNOTES (TM) is a Pen based Data Capture and "Mobile CIS software SOLU- TION". Data manipulation uses FORMS and it includes a Vector Editing capability. The advertising information states that it supports Export and Import for "all leading Vector and Raster drawing formats" and is unusual in that it has an optional software development kit for Visual Basic & C programming languages. While a farm user would not be expected to program in these languages it may be that such a kit would provide a tool base which the current project could access.

These tools are still generalist in nature, offer a broad range of facilities and require considerable expertise for their use. Even though ARC/INFO contains a scripting (programming) language that permits extensive customisation of menus and options, the price alone would preclude its adoption by an end-user market.

In summary, the packages were either very difficult to learn and expensive, or simple and cheap but also lacking appropriate facilities. The rate at which new packages are entering the market means that there will be no shortage of sources for comparison with the prototype. At time of writing, however, no package combines the simplicity of use with the required facilities.

11 Chapter 1 1.3 Propositions

1.3 Propositions

While this project does not set out to formally prove a series of hypotheses, it does seek to explore the feasibility of current domestic computer equipment being operated in a GIS appHcation by relatively untrained users. To this end it is anticipated that the truth of the following statements will be supported or refuted.

1. That the use of the Rapid Prototyping approach is valid for systems involving graphics processing;

2. That domestic "personal computer" hardware possesses sufficient processing and storage capacity and graphical capabilities to support Rapid Evolutionary Prototyping of a User Driven Desktop GIS for use in a farming application; and

3. That sufficiently flexible and efficient programming environments exist on such hardware to carry out the project.

1.4 Summary

This chapter has outlined the benefits to the farming community which could be accrued from a user driven DeskTop GIS. It has been demonstrated that the technological infrastructure is available which would permit such a product to communicate with external data sources at a cost which would not be prohibitively expensive. A sample of the existing products in the marketplace has been reviewed, and have been shown to be either too compUcated and too expensive, or cheap but lacking in GIS functionality. This project seeks to redress this situation by developing a prototype system which has its functionality tailored to the needs of the farming community and which can be used by farmers with minimal computer training.

12 Chapter 2

Chapter 2

Methodology - Rapid Structured Prototyping

This chapter describes the Rapid Structured Prototyping methodology and describes its strengths in helping novice users arrive at a specification of their requirements.

2.1 Background

Rapid Prototyping [Connell & Shafer 89] emerged as a methodology to counter some of the problems being faced by the computer applications software industry during the 70's and early 80's. The motto for these times might well have been "If a job's worth doing, it's worth doing TWICE" because as soon as systems grew in size and complexity the chances of having a working system on the first try, diminished accordingly If, after an initial failure, the system was still deemed to be worth having, then the system would be re-engineered in the light of the previous experience.

The difl&culty seemed to be, that once a problem was too big to be fully understood by one person (in finite time), the tools being used were incapable of containing and partitioning the complexity.

The first responses to these problems came in two ways:-

1. Attempts focussed on an understanding of the things DONE by the system; this Chapter 2 2.1 Background

resulted in the approach know as Structured Analysis (DeMarco:1978) which partitioned the processes performed by the system, and documented the relationships and interfaces between processes; and

2. Attempts focussed on an understanding of the DATA we DO things TO; this resulted in the approach known as Data Analysis [Chen 76] which partitioned and mapped the elements of data and recorded the relationships between data elements.

Both of these approaches assumed that the exact requirements of the new system were known at the time of the analysis; and this was often not the case [Arthur 92, p. 23 .

Consider, as an analogy, two people who wish to purchase items of clothing. The first knows the size, type, colour, style and price range of the item they require and so goes from store to store inquiring whether such a garment is in stock. When they find such a garment, they purchase it and stop looking. The second person knows only that they require, say, "something to keep the rain off them", and so "browses" amongst the possible solutions by going into various shops and trying on different combinations of items until they find something that satisfies their requirement. The second person does not seem to know what they want, "until they see it". They have no preconceived notion of the solution that they are seeking.

The situation of the second person may be more common in computing terms than first imagined. The average farmer who has little exposure to image processing, spatial analysis and graphics will be unlikely to be able to define the requirements of a "User Driven DeskTop CIS" as they have no experience of the elements possible in such a system. Equally true, asking an experienced "remote sensing aware" agronomical consultant to define the facilities for the farmer will again be unlikely to result in an acceptable solution.

In computer system terms, the first person can be handled adequately by either of the above approaches (process or data) but both fail to assist the second person to efficiently arrive at a definition of their requirement, as that requirement is being defined and moulded by their experience of the types of systems they investigate. The Rapid Prototyping approach was developed to address the requirements of the second person by placing in their hands a working model, or prototype, through which they would build experience of the sorts of solutions which could be made available to address that requirement.

14 Chapter 2 2.2 Rapid Prototyping

2.2 Rapid Prototyping

The Rapid Prototyping approach is cyclical in nature and its components are illustrated below.

Figure 2: The evolutionary rapid prototyping process. [Connell h Shafer 89, p. 24

The identified components are:-

• the Rapid Analysis of the main elements of data that the system must process, and the relationships between them;

• the building of a Data Model to permit the navigation of the data elements identified above;

• the provision of Tools to the User to populate and manipulate the data model, and to extract information from it; and

• an Evaluation Stage in which the User identifies the correctness, errors, missing data, missing features of the model.

15 Chapter 2 2.2 Rapid Prototyping

After the Evaluation Stage the components are performed again, incorporating the results discovered during the Evaluation Stage. Ideally, the User is integrally involved in each of the above components and is interacting with the analyst as each stage progresses. From my own experience of having used this approach on other systems (not graphically based), the point where the User stops complaining about missing features and starts complaining about how slow the system is, marks the end of the definitional prototyping exercise and the start of the actual implementation.

Connel and Shafer describe the methodology as producing a "dynamic visual model providing a communication tool for customer and developer that is far more effective than either narrative prose or static visual models for portraying functionality" [Connell & Shafer p. 1]. They propose a model which has four key attributes:-

1. It is functional after a minimal amount of effort.

2. It is a means for providing users of a proposed system with a physical representation of key parts of the system before implementation commences.

3. It is flexible. Modifications should require minimal effort and be achieved quickly and without programmer resistance. Experimentation is encouraged.

4. It does not necessarily represent the complete system in either function or method of implementation.

Of these the third attribute is often the most important. The user may express a desire to do something in a different manner, or to revert to a previous approach when a current method becomes too tedious or unwieldy as operations become more complex. The efficiency of the processor and storage are not important considerations during the building of the prototype so long as adequate response times to operations can be maintained.

Conventional Rapid Prototyping uses very high level tools in the development of the model. These high level tools include Data Base Managers, Screen and Report Generators, and Menu Systems. The use of these tools permits the analyst to respond quickly to the feedback from the user by including additional data fields, rearranging the data, and providing more and different screens and reports. The whole focus during the refinement of the model is one of functional effectiveness rather than system efficiency and so no tunmg or optimisation, except to achieve the desired results, takes place. The actions followmg the definitional phase depend upon the type of Rapid Prototype being constructed.

16 Chapter 2 2.3 Choice of Prototyping Environment

Throw Away model

The first type of Rapid Prototype is known as the "throw away" model. Its whole purpose is solely to define the functional requirements of the User, and to provide a model of a workable interface. It becomes the definition of the required system. In a sense, it does not matter on which hardware/software platform such a prototype is built, as the eventual implementation will be constrained by other factors (existing equipment, limited funding, corporate standards). For this reason the computer language used for the prototype may be completely different from the final language of implementation. What is important is that the developer record the rationale for the adoption or discarding of various features or approaches so that the "dead-ends" are documented along with the fruitful paths. In this environment some features may be too complex to build completely and may be replaced by gross approximations so as to give the "feel" of the final system. Delays are introduced where the approximation takes significantly less time to achieve than the real processing, so as to provide authentic "feel". Care must be taken not to provide too optimistic a model which could artificially raise user expectations of features for, "it is of little use designing a prototype user interface that uses windows, for example, if they cannot be supported by the actual system's software and hardware." [Medyckyj-Scott et a/90, p. 2

Evolutionary model

The second type of Rapid Prototype, and the one employed in this project, is known as the "evolutionary" model that evolves from the prototype into the delivered system. This type presents a dual set of criteria to the analyst; to be flexible enough to support the rapid changes required in response to User feedback, but still efficient enough to be the final environment in a production system. In a lot of environments these two requirements are at loggerheads and the chosen implementation vehicle is a compromise that meets neither fully

2.3 Choice of Prototyping Environment

While Chapter 3 discusses the construction of the various versions of the prototype since 1990, it is appropriate to note here the huge developments which have occurred in the power and capacity of computer hardware and in the sophistication of application software

17 Chapter 2 2.3 Choice of Prototyping Environment development tools. "Domestic" computer hardware in August 1996 is now more powerful than most of the multi-user research systems which were in common use when the prototype construction was initiated. Indeed, all of the early hardware restrictions which influenced the choice of environments have been completely eliminated in the current technological offerings. In addition, the advent of "visual" programming environments on microcomputers (Visual C, Visual Basic) which have the ability to interface with powerful relational database engines (Microsoft Access) would definitely influence the choice of a prototyping environment today. The following discussion indicates the considerations which took place and the conditions which existed at the time of construction and should not be interpreted as justification of how such a project would be conducted if the opportunity to "start again" were taken today.

A number of systems have been designed for fast development and User interaction, for example the Trillium system at Xerox PARC [Henderson 86], the AIDE system by Hix and Hartson [Hix h Hartson 86] and the EASIE system of MacLean, Barnard and Wilson [MacLean et al 86]. There is considerable difficulty in gaining access to such systems and it is most unlikely that the target population of farmers would have the hardware resources to run such systems.

Personal experience with traditional evolutionary prototyping, reinforced by other research conclusions [Edmonds et a/86], [Connell k Shafer 89], is that when considering the "effectiveness/efficiency" continuum, greater weight should be placed on the "effectiveness/flexibility" features as the elapsed time between receipt of User feedback and the provision of an updated version of the prototype was critical in maintaining the momentum of User enthusiasm and hence the accuracy and completeness of the feedback. Indeed, the advantage is that the prototypes provide a more concrete object that Users can respond to in a realistic manner rather than the more abstract outline proposals or screen-by-screen paper versions of dialogues which appear difficult to visualise [Edmonds et al 86 .

In software terms, a high degree of flexibility is often associated with an "interpreted" environment in which each command is analyzed, converted to machine instructions and executed, in the sequence in which they are encountered, rather than a "compiled" environment in which all commands are converted to machine code at the one time, and are then just executed.

A very popular microcomputer based tool for traditional evolutionary prototypmg is the dBaselll package which combines high level instructions for the design, population and manipulation of tables of data, particularly when combined with the Chpper com-

18 Chapter 2 2.3 Choice of Prototyping Environment piler which then compiles those instructions into machine code. This combination of interpreter/compiler provides the flexibiHty during the model building stage, and then the efficiency during production running. Unfortunately, dBaselll does not support graphics or mouse operations very well, and hence was not an alternative for this project, but the underlying interpreter/compiler combination was investigated for products which would satisfy the requirements.

MacLean, Barnard and Wilson [MacLean et al 86] and Harker [Harker 87] offer very comprehensive discussions of the requirements for, and use of, rapid prototyping tools. The following list is the essential operational requirements for the environment based on their lists, and extending the requirements for a graphical appHcation.

1. Provide a menuing system for the selection of alternatives through the use of mouse or function keys.

2. Provide context sensitive interactive help through a consistent mechanism.

3. Provide control over at least 16 colours with the ability to vary the red, green and blue composition of each.

4. Provide a mechanism for monitoring the position of the mouse by returning x,y coordinates, displaying a visible pointer, and the status of the mouse buttons (single and double click).

5. Provide window control for clipping on window boundaries and for the overlaying of one window on another, and the refreshing of the former when the second window is moved or closed.

6. Provide control at the individual screen pixel level of the colour being displayed at that point.

7. Provide facilities to save portions of the screen image to arrays, or directly to disk.

8. Provide the common data file structures of sequential, and direct access, with end- of-file sensing capabilities.

9. Be able to create "free standing" running systems which can be distributed without Hcence fee.

10. Provide graphics functions: Hne, box, locate etc.

19 Chapter 2 2.4 Summary

11. Provide local variable definitions for parameter passing for the writing of object oriented code modules.

12. Be modest in the amount of disk and memory consumed for both development and operational usage.

This list formed the basic requirements which were investigated for each of the prototype environments discussed in the next chapter.

2.4 Summary

This chapter has outlined the Rapid Structured Prototyping Methodology and discussed the requirements of a computing environment which would support such a development approach. The particular requirements of a graphical application have also been identified, and the importance of flexibility, even at the expense of efficiency, has been identified as highly important.

20 Chapter 3

Chapter 3

Building and Testing the Prototype

This chapter describes the programming work which was carried out in this project, the difficulties which were encountered, and the solutions which were implemented. Development is currently being carried out on the third version of the DeskTop GIS Prototype. The following section describes the rationale for the selection of the environments, as well as the reasons for their eventual abandonment. The final section describes the programming which was required for the storage, processing and display of the different types of data which the project encountered.

Each version of the prototype was developed on "commonly available domestic computer equipment" which existed at that time. The advances being experienced in this area of the market, and the drops in costs, means that the rationale recorded here must be interpreted in the historical context in which the decisions were made. There is no assertion being made here that these approaches would be valid if the project were to be initiated today. Indeed, with the benefit of the experiences which are summarised in the conclusion (Chapter 5) it is evident that quite a different software selection strategy would be adopted.

3.1 Prototype Versions

3.1.1 AMIGABasic on the AMIGA 500

In 1990 the first environment to be chosen for implementation was AMIGABasic running on a 1Mb Amiga 500. The Amiga had become the cheapest colour machine available which Chapter 3 3.1 Prototype Versions offered a "point and click" GUI, and its 68000 microprocessor was quite fast for that time. Farmers, if they owned a computer at all, would have been hkely to have a 640K, Hercules graphics, monochrome 8088 type PC, and if it had a hard disk at all it would most Hkely have been 30Mb maximum. As this was before Microsoft Windows entered the market,

MS-DOS 3.x would have been the operating system. The Amiga had wordprocessor and spreadsheet software available and was already establishing itself in the "games" market, so its adoption was within the price range which Farmers could afford, and could offer the dual role of being an entertainment machine.

As many different formats of data were anticipated, a basic data structure was designed which was highly modular. This centred upon using an "object" file to record the "type" and nature of data in the system, and many different other files to actually store the data. In this way when new data was received in a format which had not been previously encountered, a new object "type" would be created and program modules would be written which would process and display that new data type. The idea was for the prototype to grow in an ad hoc fashion until the need for new data types ceased, and then to look at commonality of processing to enhance the performance of the program.

In this environment the prototype was used to explore the number of colours which would be useful, the required size and resolution of the graphics window (as small windows would refresh more quickly when needing to be re-drawn) and the arrangement of Menu selections and the type of context sensitive Help which would be provided. Also, all of the early processing of paddock boundary data (mentioned later) was carried out, and the incorporation of the first satellite image to be displayed by the program.

This early work was presented at the Fourth Colloquium of the Spatial Information Research Centre [Munro 92]. At this conference the paper was presented with the award of "most interesting new work", and several demonstration copies were distributed and names collected of persons who indicated they wished to evaluate future versions. The demonstrated version was 1200 Hnes of code which was split into twelve programs under the control of a scheduler. It adequately handled the required number of colours as well as the mouse and windowing operations. The difficulty which caused the environment to eventually be abandoned was the time taken to redraw the graphics window at different resolutions when "zooming" in or out. Even with the image window restricted to just 320 pixels by 256 pixels (the minimum indicated to be useful), the system still took over 45 minutes to refresh the screen when each individual pixel had to be redrawn in the correct colour. The AMIGA did have development languages which would operate far faster than AMIGABasic. However, they lacked the fiexibiHty required of a prototyping environment,

22 Chapter 3 3.1 Prototype Versions and would have severely impacted the philosophy of the project.

3.1.2 GFA-Basic on an IBM-PC

In late 1992 another survey was made of hardware and software environments. This resulted in GFA-Basic being adopted as the initial implementation vehicle for the IBM-PC version, as its interpreter/compiler combination should have provided a very productive and flexible programming environment, while delivering the application performance which had crippled the former version. The environment ran in MS-DOS in just 1Mb. Initial benchmarks carried out on a 20Mh IBM 386SX (a commonly available platform at that time) indicated that it would handle the required number of colours, the mouse and windowing operations, and would redraw a 375 pixel by 375 pixel image window in 5 minutes (quite adequate for the prototype).

The GFA-Basic environment worked best when presented with one large program, and so the initial programming effort was to install the Amiga code as subroutines in a larger program. The data files in the Amiga format then had to be converted to MS-DOS format, and different screen handling and mouse handling programs had to be written for the IBM hardware. Errors were discovered in the GFA-Basic file handling software, and the supplier provided "work-around" solutions which permitted the project to continue. At this stage Daniel Jolly, a Year 11 high school student proposed under a CSIRO Student Research Scheme, became involved in the project for three weeks and wrote several "one- off" routines to remove errors from the initial data, and to pre-process some of the other data which was becoming available (salt and timber readings).

The project was successful in gaining a Rector's Research Grant in 1993 which funded a five week Vacation Scholarship which Daniel filled over the 1993/94, December/January Christmas period. During this time he wrote programs which generated and displayed the histograms of pixel values in image data, and the 2 x 2 pixel image display routines (both are part of the tutorial in Appendix P). He also prepared the data files for contours and roads.

By mid 94 the prototype had been extended to include zooming to different resolutions, and additional code was being prepared to handle the Yield Monitoring and GPS readings which were anticipated during a three month study period at Montana State University (MSU) at Bozeman during the second half of 1994. It was in September 1994 during this

23 Chapter 3 3.1 Prototype Versions programming that the environment became quite unstable resulting in many calls to the suppher, and many patches and "work-arounds" being provided. Eventually the size (2600 hnes of code) and complexity of the prototype was causing so many interconnected errors that the addition of any new code would cause previously running code (including patches and work-arounds) to cease working. This was not caused by the new code accidentally altering the values of variables, but even the order in which the variables were defined would change the operation of the code. A further disappointment at this stage was that the GFA-Basic Compiler would produce different (but still wrong) results from the GFA-Basic Interpreter. This required the code to be "debugged" in two different environments and the additional effort was deemed unproductive and the environment abandoned. I suspect that some of the GFA Basic internal functions used "short" instead of "long" variable pointers and so worked adequately while there were only a small number of variables and locations to address.

3.1.3 Microsoft Visual Basic V3.0 running under Windows 3.1 on an IBM-PC

The most recent environment being used is Microsoft Visual Basic V3.0 running under Win- dows 3.1. This was chosen following a series of Video Benchmarks which were performed while on study leave at Montana State University (MSU) at Bozeman during September 1994. The Benchmarks were to check that the environment would perform with adequate speed on the sort of equipment which farmers were likely to own. The size of the code was not deemed to be a problem as large commercial programs had been written in Visual Basic by programmers at MSU. However, these programs were not graphically oriented in the sense that they did not process image data.

The Video Benchmark was to establish the delay which would be experienced using Visual Basic V3.0 to redraw images of 420 pixels by 420 pixels using just the simple commands provided by the programming environment. The test consisted of opening a form with three picture panels. The time taken to fill the first panel with a 420 x 420 pixel image consisting of random colours was then recorded. The test was run with, and without, the "auto-refresh" property being set for the picture panel. When the auto-refresh is set ON a panel that was covered by another window will be automatically refreshed when the covering window is either closed or moved. This requires an additional memory area to be maintained automatically by the system. For comparison, a (small, and therefore stable) GFA-Basic program was tested doing a "similar" task (without auto-refresh) on

24 Chapter 3 3.1 Prototype Versions each machine. The benchmark provided the following data which gives the times from the initiation of a zoom operation to the completion of the refresh of the 420 x 420 pixel window. Times shown are in minutes and seconds.

Machine GFA-Basic Visual Basic Visual Basic MS-DOS With Auto-Ref Without Auto-Ref Decstation 320+ 386SX/20Mh 5:00 6:22 5:37 Decstation 425C 486DX/25Mh 3:00 4:27 3:42 DecPC 433 ST 486DX/33Mh 2:00 4:05 3:36 DecPC 466 d2 /MTE 486DX/66Mh with Local Bus Video 1:00 1.06 0.53

Table 2: Times taken for window refresh.

The performance of the 486DX/66 pointed to the sorts of machines which would be commonly in the hands of farmers when the prototype was released. The broad industry acceptance of Visual Basic as the Windows Interface programming tool, and the existence of supporting Magazines such as the "Visual Basic Programmer's Journal", which pubhshed techniques, tips and features, was a strong incentive to select that environment.

What is particularly interesting is that in 1992, when the first IBM/PC environment was being chosen, Visual Basic VI.0 on an early version of Windows took 16 minutes to perform the same task on a 386SX/16Mh. At that time GFA-Basic on a MS/DOS base took just 6 minutes. So, while the 386SX/20 is slightly faster, the majority of the performance increase must be attributed to the efficiencies built into the latest version of Windows and the latest version of Visual Basic.

The demonstration disk and tutorial contained in Appendix P was the final version produced under the GFA-Basic environment as time constraints have not permitted the Visual Basic version to be developed to the same extent at this time.

25 Chapter 3 3.2 Required Processing for "types" of data

3.2 Required Processing for "types" of data

As mentioned earlier, the idea was for the prototype to grow in an ad hoc fashion until the need for new data types ceased, and then to look at commonality of processing to enhance the performance of the program. This section describes some of the processing which was required.

3.2.1 Satellite Images

The image used in the start of the demonstration disk of the Charles Sturt University (CSU) farm in Wagga Wagga (Appendix A) was subsetted using Genamap from a Landsat TM image. The image comprised three bands (2, 3 and 4), and was enhanced using proportional colour allocation for the 255 colours which were supported on the Hewlett Packard hardware on which it was originally running. When the image was converted to the first Amiga platform it had to be reduced to just 16 colours because of hardware and memory limitations, and so a histogram of each of the 255 colours was constructed and the 16 available colours were allocated to the numerically most significant in the original image. The resulting image was pleasing as a backdrop, and was useful in testing the image display routines, however there is very little "information" to be gained from the colours in the image. Even the production of the colour page at Appendix A required some technical adjustment [Govier 96] as the different boundaries which were appropriate for the majority of screens were not the same for the colour printer being used. This will open up a whole new area of concern should the prototype be required to support a variety of colour printers. It would also be unreasonable for a user to perform such manipulations upon the data before importing it into the system as all of this required specific programs to be written which would be different for each image.

3.2.2 Scanned Aerial Photographs

A lot of farmers have aerial photographs of the paddocks of their properties. Often only one or two paddocks will be presented on an A2 sized sheet which is the result of photography from as low as 1000 metres (An example is included at Appendix B). If these are scanned at 400 dots per inch (not an uncommon resolution for even quite inexpensive scanners) then the resulting image is huge (up to 32 Mb per paddock) and the pixel resolution is sub metre!

26 Chapter 3 3.2 Required Processing for "types" of data

While such photographs provide a great deal of visual information, for DeskTop GIS usage a scanning resolution of 100 dots per inch provides a more useful image of 2 to 3 metre resolution per pixel. Aerial photographs are useful for locating visually identifiable objects hke houses and sheds, silos, roads, dams and tanks. However, they generally would not be subject to the same level of image analysis as their grey scales convey less information.

They would, however, require the same treatment for registration and alignment, and perhaps more adjustment by way of "rubber sheeting" [Bedell 88] depending upon the skill of the scanner operator. This will be particularly true if the photograph is physically too large to be scanned in a single pass and requires multiple scans which result in a series of images files that have to be aligned and "stitched" together prior to inclusion. The additional problems which such a scenario introduces is that it is highly likely that parts of the scans will overlap, and that the overlapping area may not be a neat rectangle but more of a "wedge" shape. This will require the image files to each be rubber sheeted prior to being overlaid on each other and output as a single image. Additional complexity can be expected if the contrast or brightness of the individual scans is different, as now some averaging will be required in the overlapping regions.

3.2.3 Manipulating Colour

The problems associated with displaying images led to an investigation of just how such colour analysis would be performed by farmers.

An original Landsat image of part of the area was obtained and the data was displayed, one band at a time. Different intensities within the band were allocated different intensities within one colour (eg, red). This was then repeated for other bands, and other colours. The farmers found it difficult to interpret what exactly the colours being displayed were composed of when the colours were blended into a single pixel. As ease of use and minimum training time were objectives of the prototype, it was unreasonable to expect users to undergo colour interpretation training, particularly as 8.5% of males and 0.5% of females are likely to be colourblind to some extent [Carter 70, p. 88]. Further research suggests that even for those who have some degree of colour blindness, appropriate selection of colours will largely overcome physiological imparement [Foley h Van Dam 82, p. 621 .

A different approach was tried in which up to four bands would be displayed with each band being allocated a particular pixel in a 2 x 2 pixel matrix which represented

27 Chapter 3 3.2 Required Processing for "types" of data a single location. In this way, without colour interpretation training, the farmer could distinguish the intensity of each of say four colours individually, and could visually interpret the relationships by looking for areas of the displayed image which are more one colour or another resulting from areas in which there was combined high intensities in various bands, and low intensities in others.

Appendix C shows the sort of image which can be displayed in this fashion. In it can be seen areas which are mostly blue, others mostly red, and some mostly green. The tutorial in Appendix P will instruct you how to view these images on your monitor so that a better appreciation of the differences can seen as the printed version requires more colour tuning for better results.

3.2.4 Colour Intensity

The first attempt at colour intensity differentiation used the whole 15 available colours (not including white) to represent the intensities in the red band from a very low reading (black) through to a very bright reading (a value of 255 in the red colour). This introduced the problem of deciding what intensity levels of colours to use for the divisions, but also the larger problem of which boundaries in the data to use for the different intensities.

As a test of the various levels in a single colour intensity which would be perceived as being different, a small program was written which displayed a series of coloured boxes ranging from the "black" through to the very bright. The idea was that various individuals would then be asked to indicate how many coloured boxes they could distinguish, and so intensities would be chosen which would suit the majority of individuals. This test was run with about 20 students and six lecturers at The Austrahan Defence Force Academy, and four farmers.

What the test in fact did show us was that the colour adjustment of the video monitor in use created a greater variety of reactions, and that the same individual would perceive different boundaries when viewing the same test on a number of differently adjusted mom- tors. This opened a whole new area of research possibihties which I considered to be outside the immediate scope of this project. I did, however, find that four intensities, which were named "black", "light", "mid" and "bright" could be discerned by all individuals on all monitors. The results of this practical test were further strengthened by other research which discovered that a maximum of 10 colours in four intensities were generally distin-

28 Chapter 3 3.2 Required Processing for "types" of data guishable [Foley et a/90, p. 422]. As I wanted to be able to display up to four bands simultaneously, and as I wanted to stay within a palette containing a maximum of 16 colours, the choice of four intensities meant that a maximum of 13 colours would be used for this type of image display as each band would share the "black" colour.

The decision to restrict the display to 16 colours maximum was taken quite early in the project and was to permit the prototype to be able to operate in a consistent fashion across a wide range of user installed platforms (IBM PC 286's at that time). As a rapid increase in the sophistication of hardware was anticipated, the "magic" number "16" was not hard coded into the prototype, and during the rewrite into Visual Basic this parameter will be changed to 255 reflecting the most common configuration available on 486 desktop and laptop machines.

While this will permit a more aesthetically pleasing interface to be constructed, it is unlikely that more than four colour intensity levels will be used in the visual inspection of image data because of the problems mentioned above.

3.2.5 Data Boundaries

In order to establish the data boundaries to be used for the colour intensities mentioned above, there needed to be a mechanism that would permit the farmer to visually explore the information contained in the bands. An experienced image analyst might start with a histogram showing the number of pixels having each value (0 through 255) in the image, and then choose an initial set of boundaries based on the distribution. A commonly used initial set of boundaries are based upon equal areas of the image calculated from a histogram count of the number of times a pixel value appears in the image [Richards 86, p.90]. Using this approach the prototype would place boundaries in the histogram so that 25% of the number of pixels in the image were contained in each of the four colour intensities being displayed. This, of course, assumes that the whole range of values in the image are of interest. If the farmer knows that one portion of the image represents a particularly poor area of crop then it is likely that the four colour intensities would be better focussed on (say) lower values in the image, and so the maximum value would be lowered so that the equal areas would now be devoted to a finer dissection of the values of interest.

Equally possible would be the situation in which the farmer wishes to focus on the high yielding areas of the crop; necessitating the raising of the minimum value to be in-

29 Chapter 3 3.2 Required Processing for "types" of data

eluded in the equal area display. This leads to an interesting conclusion; vis, there will be multiple colour interpretations of the same band of an image depending upon what information is being highhghted. These interpretations will need to be stored, with some descriptive annotation, so that the farmer will be able to recognise them at a time in the future. Further, if the (say, four) bands being displayed are in fact either the same band with different interpretations, or bands from different images sampled at different times (say, throughout the growing season), then the individual pixel values convey very Httle information in an absolute sense and what is more important is the relative colour intensity of a pixel compared with its neighbours. Also, as the farmer becomes more familiar with the system, and finds new aspects which he wants to investigate, previous images will be revisited and reanalysed. This last point requires that all or part of a single image may have multiple classification categories applied to it. Rather than store multiple copies of the image for each classification it would, be better to permit each classification to access the original complete data.

The implications for the DeskTop GIS are that various classifications must be able to exist for the same image data, (or just a part of it at a particular resolution) and that they will need to be editable so that as a better understanding of the information emerges they can be fine tuned to deliver the level of analysis required.

3.2.6 Points

Points are used to store a vast range of data. The locations of power poles, taps and wells are typical examples. The point data carries an attribute code which is used in its selection for inclusion in the collection of items to be displayed. The location of a point can be refined as more accurate data becomes available, and the new location replaces the existing data. If a point actually moves (for example a broken electricity pole which is replaced at a slightly different location) then the temporal element must be considered. A range of dates must be defined as the window within which data is to be accepted so that only information consistent with that window will be displayed. Also, if two entries are located within the date range for the same point, then the most recent entry is the one displayed. This requires a more recent entry to supersede an earlier one.

30 Chapter 3 3.2 Required Processing for "types" of data

3.2.7 Linework

Linework is represented by the straight hne segments joining two or more points. Within the DeskTop GIS, Hnes forming closed polygons are used to delineate paddocks (fields) and roads, and as single line segments to show contours for altitude and salinity measures.

Experience with the prototype has shown that different methods for collecting the locations of the ends of the lines pose different data processing requirements. This is discussed in more detail in the following sections.

3.2.8 On-Screen Digitisation

The rough and ready method of "on-screen digitisation" requires either an image backdrop that has been correctly oriented and scaled and that has at least one known reference point, or a raw image backdrop on which four reference points forming an enclosing polygon of the farm area are identified.

In each case the user identifies the boundary of the object being recorded by mouse chcking on points on the image. In the first case a simple calculation based on the reference point and the scale will yield the datum points of the boundary. In the second case a slightly more involved calculation known as "rubber sheeting" [Bedell 88] is required to correct for the distortions in the unregistered image.

The accuracy of data point coordinates which such operations yield are dependent upon both the skill of the user in positioning the mouse cursor in the correct position, and the scale of the image being used as a backdrop. SatelHte images are usually supplied having been corrected for skew and yaw, and have typically a resolution of either 80 metre (Standard Landsat MSS), 30 metre (Landsat TM), 20 metre (SPOT multispectral XS) or 10 metre (SPOT PAN). On-screen digitisation from these images will be subject to average errors of plus or minus 40, 15, 10 and 5 metres respectively, but as an initial method of encoding major features it is highly productive for establishing a framework quickly. The ability to refine the boundary positions by editing the coordinates as new, more accurate, locations are established permits evolutionary refinement of the model layers.

31 Chapter 3 3.2 Required Processing for "types" of data

3.2.9 Keyboard Entry of Ordnance Survey Co-ordinates

Map-based coordinates for known boundary locations can be determined from Ordnance Survey Maps. The simplest method of doing this is to use a ruler and to estimate the Northing and Easting values from the grid on the map margins. As mentioned when discussing the selection of the co-ordinate system, care must be taken to note the grid reference which the map uses as there are several standards and a location can be as much as 60 metres different between versions. The moisture content of the paper on which a map is printed will also be a source of errors as paper shrinks as it dries out. This would not be a major problem if the shrinkage was even across the whole page. However, as maps are regularly stored one on top of another, the outside edges of the map are affected more than the centres of the maps. This shrinkage is a well known problem of high speed computer printers which use continuous fanfold stationery. The top and bottom few hundred pages of a 2,500 page box will be up to 2mm narrower than the pages in the centre of the box, and this difference, unless monitored and adjusted, will cause the paper to jam in the printer. These maps typically have scales of 1:25000 or 1:50000 and so every milhmetre of error (caused by using a thick pencil to draw lines, or by paper shrinkage) will introduce errors of 25 or 50 metres respectively in the position of the points recorded. This method was used for the initial creation of the property boundaries for both the McKay property at Burra, NSW Australia, and the Wright properties at Belgrade, Montana USA.

3.2.10 Co-ordinates collected from a digitising table

A third method was utilized in the capturing of linework for the CSU Farm property near Wagga Wagga NSW Australia. Here an Ordnance Survey map was fixed onto a digitising table and an operator recorded the end locations of linework using Genamap software and a digitising cross-hair cursor. The software permits the establishment of many co-ordinate grid reference points and automatically performs the previously mentioned rubber sheeting calculations in real time, and records AMG co-ordinates for the button cHcks.

These data were then exported in an ASCII format for incorporation into the DeskTop CIS, but required the following extensive processing before they were particularly useful.

• There were no tags or breaks in the data which indicated which line segments be- longed to which fields. In some cases (see Figure 3 below) a single line segment was

32 Chapter 3 3.2 Required Processing for "types" of data

actually forming the boundary for four or five different paddocks, even though its own endpoints were not included in any of those paddock boundaries.

Figure 3. Problem Boundaries

• If a program was written to simply draw the lines, (Appendix D) then the output looked like a set of paddock boundaries. However, no individual paddock boundary could be drawn because there was no record of which line segments made up which paddock boundary. The steps in allocating line segments to individual paddocks were firstly to draw all the linework, and then one line at a time, redraw each line in a different colour (highlight) and solicit from the User (multiple) paddock numbers for which this line was part of the boundary. These paddock number tags were determined by the operator with reference to a "Farm Map" provided by the farm Manager (Appendix E).

• These tags, together with the line's co-ordinates were then written to a new data file, the line was redrawn in the original colour, and the next line was highlighted. This new data file was then sorted on paddock number and the entries for each paddock were written into individual files.

• At this stage an individual paddock could be drawn. However, some hnework would extend beyond the actual boundary of the paddock. Also at this stage it was noticed that some of the paddock boundaries were not "closed" because of small errors in the polygon vertices' co-ordinates; and further, that the order of the lines making up the polygon were not in any particular sequence from a head to a tail and (hopefully) joining up.

The first attempt to correct this was a program which would automatically piece together the required hne segments and which would close small openings in the boundary. This turned out to be particularly difficult, and so a simpler strategy was adopted which was to

33 Chapter 3 3.3 Selection of Test Users draw the linework for a paddock and then have the user mouse cHck on the co-ordinates in sequence which made up the polygon. So as not to require exact positioning of the mouse, and so as not to introduce operator error, the location of each mouse cHck was not recorded, rather the location of the nearest Hnework co-ordinate to the mouse cHck. This "snap to closest coordinate" approach worked particularly well and the conversion for the 75 paddocks was accomplished in 7 operator hours and had the advantage that all polygons were known to be closed at the completion of the task and all line segments were connected in a regular order.

Again, it would be unreasonable to require a User to go to this level of pre-processing of data. What is emerging, however, is the need to be able to create new graphical objects using some other graphical object as an underlay, and then to permit editing and refinement of the new objects using a graphical editor. For example, if the original unconnected line segments had been just displayed in the DeskTop GIS and the User had been able to zoom in on the lines making up a single paddock, then the cursor could have been used to pick off the required coordinates either directly by mouse click, or using the "snap to closest coordinate" feature mentioned earlier. The coordinate editor could then have been used to refine the locations as new data became available. This approach would not have required the custom programming of the tagging of the original line segments and the sorting into paddock order, and should have been within the abilities of most Users.

As the sophistication of GIS packages develops, and as more users need to share data, standard file formats like DXF and DLG (for vector data) will simphfy the import and export between packages. Whether the farmer, a bureau or a vendor provides the initial bulk of the data, facilities will be required to maintain such data as errors are detected or more accurate data becomes available. If the farmer is the custodian of the data, he will need appropriate tools which do not require "a considerable level of skill or training" to perform these tasks.

3.3 Selection of Test Users

Communicating the implications of research to the end user community is an activity often poorly performed. Even finding joint commercial partners to fund the commercialization of highly successful scientific research is. a difficult prospect, not only because different languages are spoken in science and business, but often because one side is unaware of the activities on the other side. "There is Httle point in carrying out research if no-one gets to

34 Chapter 3 3.4 Summary find out about it." [Dawson 94]. The orientation of Structured Rapid Prototyping towards a high degree of User involvement in the establishing and testing of the functionahty of the model keeps the final outcome relevant to the target User group and prevents "interesting" side issues from hijacking the original thrust of the project. "Having farmers at these events (field trial days and workshops) is also very worthwhile, to ensure that the practical views of those at the sharp end can be heard." [Dawson 94

Following the presentation of the paper [Munro 92] (Appendix F) and the demonstration of the Amiga prototype, names and addresses of interested farmers and other researchers were received. The original idea was to release a version with a small amount of fixed data and an instructional tutorial which would guide Users through the facihties which were implemented. In reality, the developer's time was fully consumed by just working with mainly the data from two sites (CSU Farm near Wagga Wagga, NSW, Austraha, and the Wright properties at Belgrade, Montana, USA) and with the flood of good ideas and feedback which these generated.

As each new type of data was collected, routines would be written which would process and display it. Very often even the same type of data from two different sources would require different "pre-processing" before it could be included. This presented the dual problem of deciding just what processing had to be done (scahng, scanning, resamphng ... ) and then finding ways in which a farmer would have been able to identify that some changes needed to be made, and would have been able to accomplish them. As many farmers are quite capable with "spreadsheet" programs, this tabular layout seems to be the simplest representation of the data, and more automatic facilities for common elimination of problems can be provided (similar to macros in spreadsheets) which the farmer can initiate with a mouse click. This was tried by actually using a spreadsheet to perform the required pre-processing and seemed quite effective for numerical data (stock movements, yield readings and polygon boundary points). The major unresolved editing problem relates to images, in which cases the farmer needs a lot of information about how the image was captured, and what it represents before being able to perform processing upon it.

3.4 Summary

This chapter has acknowledged the rate of technological development of both hardware and software affecting the "domestic" microcomputer. It has provided details of each of the prototype versions, and the difficulties which were encountered in building them. 35 Chapter 3 3.4 Summary

Specifically, in the AMIGABasic environment, slow screen manipulation routines detracted from an otherwise simple and flexible, windows and mouse, programming environment to the extent that the prototype had to be a;bandoned. In the GFA-Basic environment, there were system malfunctions which would generate random errors when changes were made to the code. The prototypes did, however, provide a tangible model with which to explore the image processing and record keeping requirements of the farmers whose data was being used in the development. Solutions to problems have been identified, and the ramifications of those solutions to the target user community have been discussed.

36 Chapter 4

Chapter 4

Functional Requirements Identified

This chapter describes the functional requirements which were identified from the hterature and from constructing the prototypes and letting farmers use them to process some of their data.

4.1 GIS as a Spatial Decision Support System - SDSS

Farmers make spatial decisions and process spatial data most days that they operate a farm. Whether they are estimating the number of days of feed remaining in a paddock for a number of animals, or the time a certain piece of equipment will take to perform a process upon a given area, they are working with spatial data. The most common general purpose computing tool that they use is the "spreadsheet" and this is used to process figures, with the only graphics likely to be financial relationships within the data. These spreadsheets are used to analyse various aspects of agricultural management ranging from which varieties to plant under certain conditions, through to what substances to spray for various weeds, to which tractor to use for certain tasks and when to replace it. The common problem with these tools is that they all require the data to be entered each time, by hand, into the individual tools.

In a case study of the application of GIS to real estate investment analysis, Peterson has noted the limitations of the human information processing system as being almost entirely serial with the inputs and outputs of processes held in a small short-term memory with a capacity of only a few (i.e., four to seven) familiar symbols or chunks [Peterson 93, p. 382 Chapter 4 4.2 Establishing the Co-ordinate System

Much earlier, Simon asserted that "These characteristics of human information processing apply to the solution of both well-structured and ill-structured problems ..." [Simon 73] , and that "... only a small part of the potentially relevant information stored in long-term memory or in external reference sources plays an active role in the solution process at any given time" [Simon 78 .

Peterson argues that, "Given these characteristics of human problem solving behaviour, it follows that any computer-based decision support system should extend information processing limits and provide support in those subtasks where the problem solver makes mistakes" ... and that ... "Given the limited capacity of human short-term memory, the SDSS should serve as auxiliary short-term memory, making chunks of information available as needed in the problem-solving process." [Peterson 93, p. 383] Indeed, the goal of the DeskTop GIS is not only to extend the short term memory, but also to provide the long term "corporate memory" for the farming enterprise so that future generations of farmers would be able to compare previous land use and land treatment philosophies.

Peterson goes on to state that "Although land-use ... problems may be complex, and may involve conflicting or poorly-specified objectives and relationships, surprisingly little of this is apparent to the decision maker when first addressing the problem." [Peterson 93, p. 384] Thus the DeskTop GIS should permit exploration of diiferent alternatives, and should be able to maintain the "states" of a number of alternative scenarios which the farmer may be exploring. This is similar to performing "what-if" analysis on financial figures using a spreadsheet.

In his own study, Peterson uses map overlays to provide auxihary short-term memory which he states provides "insight that is difficult to obtain in any non-map based framework." [Peterson 93, p. 385] For example, the farmer need not remember the spatial patterning of acceptable soil types with respect to topography, nor struggle to recall how patterns of drainage, access, water proximity and common boundaries relate to each other. Accordingly, the system should provide methods of manipulating spatial data as well as displaying spatial data.

4.2 Establishing the Co-ordinate System

The Co-ordinate system is central to the functioning of the GIS. It forms the reference against which all data may be compared and analyzed. Authorities [DoE 87, p. 2] and

38 Chapter 4 4.2 Establishing the Co-ordinate System researchers [Dangermond 89, p. 25] have stressed that "the benefits of a geographical information system depend on hnking different data sets together" and that "it unifies and integrates that information. It makes available information to which no one had access before, and places old information in a new context. It often brings together information which either was not or could not be brought together previously." To be able to accomphsh this will require the DeskTop GIS to be able to accept data which has been assembled using different coordinate systems. Synder [Synder 82, p. 13] identifies "over a dozen principal elhpsoids which are still used by one or more countries" to describe the shape of the Earth. Most of these were only fitted to the Earth's shape over a particular country or continent, eg. The Australian 1965. Satellite data required a more consistent "World View" which resulted in the United States Defence Mapping Agency initially producing the "World Geodetic System 1966", (WGS66), followed by a 1972 revision (WGS72), and a 1980 revision (WGS80). While differences between these systems result in discrepancies of generally less than 100 metres in either Northing or Easting, they do become visible when digitised linework from paper maps is overlayed on satelhte images and when the resolution is such that a single paddock is being viewed full screen. This was, in fact, the way in which the existence of all these different projections was brought to my attention when a colleague [Tyler 94] with extensive surveying experience overheard my frustration with the non-alignment of objects though the coordinates had been checked thoroughly. The differences turned out to be due to two different systems being used for the objects.

Because most of the early maps being used were based on the Universal Transverse Mer- cator (UTM) projection called the Austrahan Map Grid (AMG), it was chosen as the display coordinate system for the DeskTop GIS. The formulae for converting (AMG) co-ordinates to and from other co-ordinate systems are well known (eg. Lat/Long), and translations to and from other formats will be accomphshed in future versions of the prototype for other spatial operations.

This approach was a compromise between being able to use data recorded from old maps by storing the actual co-ordinates from the maps without translation, and wantmg to use the most accurate measures available.

It is essential for correct translation that any data collection effort should record not only the co-ordinate points, but also the reference against which they were collected to permit the correct translation to take place in the future.

39 Chapter 4 4.3 Creating Data Layers

4.3 Creating Data Layers

Shepherd states that in spite of all the tools which have been developed, "the creation of a consistent database is still essentially a manual operation. It is frequently labour intensive, and usually requires the participation of those who are knowledgeable both in the characteristics of the source data and also in the application area for which the data are being assembled." [Shepherd 92, p 344] As the DeskTop GIS User is likely to be the agribusiness person (farmer) associated with the area being processed, this local knowledge will be readily available. He goes on to state that "More recently, however, many of the tasks undertaken to create consistent databases have been supported by software tools." Examples of the latter include software for rubber sheeting [Bedell 88], zipping [Beard k Chrisman 86], map conflation [Saalfeld 88], and vector to raster conversion [Steneker k Bonham-Carter 88 . In the DeskTop GIS these are to be available as modules that can be selected from various menus which become available when appropriate objects have been selected or are displayed.

Unfortunately, not all data inconsistencies are resolvable simply by using the battery of tools available. For example, the use of an interactive graphics editor to displace polygon boundary coordinates (what Dangermond [Dangermond 89] calls 'graphic fudging') may be constrained or prevented by legal definitions of one of the boundaries in question. However, the ability to refine the underlying points as more accurate data becomes available is an essential feature.

The operations needed to create a consistent geographical database can be implemented at various stages in the data conversion process [Dangermond 89

1. before data conversion; use of standard base maps

2. during data conversion; templating, on-line transformation, automatic text annotation, automatic snapping...

3. after data conversion; manual interactive editing, rubber sheeting, conflation, hne snapping, attribute consistency checking...

Elements of some of these capabilities have been designed into the DeskTop GIS, and facihties implemented as the requirement was encountered.

40 Chapter 4 4.4 Images

For example, before data conversion, a line selector tool was implemented to assist the user to tag digitised line segments and to relate them to particular paddocks. This was necessary because when the linework was being digitised the operator had not worked on a paddock by paddock basis, but had simply recorded the longest Hne segments first and so some line segments were partial "common boundary lines" for up to six different paddocks.

In another example during conversion, a point selector tool was implemented to permit the user to record the corner points making up the paddock in the correct sequence so as to have an enclosed polygon for each paddock. This was necessary because often there were very small errors in the digitising, particularly where a paddock boundary met the previously mentioned "common boundary lines" and there was a small gap through which a paddock would "leak" into its neighbours.

4.4 Images

Two approaches are generally taken to the inter-conversion of incompatible data formats and media: one-to-one conversion using direct translators (necessitating translators for n different formats); and translation to and from a "universal intermediate format" (requiring 2n translators for n different formats) [Shepherd 92, p 346]. Clearly, any strategy that reduces the number of data formats in general use simplifies this conversion problem.

So far the approach utilized for converting images in the DeskTop GIS has been to use, with assistance [Wood 94], the Public Domain shareware package called PBMplus. Writ- ten and co-ordinated by Jef Poskanzer, this package is under continuous development by an enthusiastic band of adopters who exchange fixes for identified problems, and create new conversion routines as new formats are introduced. The package uses the "universal intermediate format" approach mentioned above, and so an enormous amount of flexibility is achieved. The PBMplus source code is available, and can be incorporated into the prototype so that the facilities are available within the one package interface. At present, however, translations are achieved by transferring the image on to a UNIX host, performing the PBMplus conversion of the image using the command line interface, and then downloading the final image.

The advantage of this approach during the development of the prototype was that potentially only one import and export routine needed to be implemented for the graphics. However, GIS images typically contain a lot more information than a coloured picture

41 Chapter 4 4.5 Crop Yield Maps

(reference points, scale, bands and date of capture), and conversion was more difficult than may be first imagined.

New sources of spatial data are continuously being examined. Churchill and Attema Churchill k Attema 94] discuss a joint research project that examines the areas in which Synthetic Aperture Radar may be appHed. Indeed the entire contents of Volume 15 of the International Journal of Remote Sensing, Number 14, 20 September 1994 (251 pages) is devoted to papers associated with this project. As new sources become readily available the facilities must be developed which permit the easy incorporation of the image data into the existing data collection.

Existing satellite imagery is becoming cheaper, and Richards mounts a case for making it more available to the small user. He argues that if "data delivery" mechanisms can be effectively linked to the user community, then "there would be no need to compile independent spatial data bases ... but rather that [Users] could access data as and when required" [Richards 93, p. 294]. To achieve this aim "the data needs to be sold by smaller packets than full scenes, desirably, to suit any customer-specified area, and, the pricing structure needs to be such that ... the average User would be prepared to repurchase data for future appHcations."[Richards 93, p. 295] He gives the example of a SPOT HRV scene which (in 1993) cost $3000 for 60km x 60km (about $8 per 1000 hectares) which he argues could be delivered (even by doubling the cost to cover tariffs and other added costs) for about $10 per 500 hectare holding. In early 1996, a SPOT HRV scene costs just $1705 (digital, multispectral) which could be delivered for say $6 or $7 per 500 hectare holding, and an MSS scene (185km x 185km) costing $700 (digital) would cost just cents per 500 hectare holding. In the November 1995 ACRES UPDATE newsletter [ACR95, p. 4] AUSLIC and ACRES were advertising their new Web Home page (http://www.ausHg.gov.au) and were creating an on-line catalogue of their services. As mentioner earlier, if these costs were to be realised and if delivery could be achieved via the World Wide Web, then even small users could afford to access the information several times during a year.

4.5 Crop Yield Maps

Crop yield map data collection involves the use of two technologies, both of which from the experience of this project can be considered still in early stages of development and reliability. The technologies are the real-time yield monitors, which measure the rate at which the grain is entering the harvester storage bin, and the Global Positioning System

42 Chapter 4 4.5 Crop Yield Maps

(GPS) which provides the Northing and Easting position, as well as the altitude and GPS time for the yield reading.

Advertisements in trade journals in 1994, and the sales brochures of entrepreneurs at that time, were quoting positional accuracy of +/- 5mm for some post processed data, and better than 97% yield monitor accuracy with weighbridge totals. When discussing with them my data, and the problems (detailed below) which I was encountering, they could only say that the variations must have been due to "local conditions and settings". Undoubt- edly there will be developments and refinements in both positional and yield monitoring technologies. However, in 1994 the fieldwork research carried out in this project was close to the leading edge of equipment and techniques.

Real time yield monitors consist of a device that measures the rate at which the grain is entering the harvester's storage bin coupled to a device which simultaneously records the speed of the harvester (as measured by a device on the axle of the wheels), and the GPS location, (as measured by a GPS receiver). The width of the harvester cutting-boom (the "head") and the diameter of the wheels are entered during the calibration of the equipment and are assumed to be constant for the duration of the harvesting session. The yield monitor then calculates the instantaneous tons per acre being harvested. This, of course, assumes that the farmer is capable of driving the harvester in such a way as to keep the face of the header full of crop at all times. While this is of course the desired optimum, there are times when the "head" is less than full and the measurements recorded are lower as a result. Note that this does not invalidate the yield monitor's "total yield" figure for the paddock, but it has the potential to create artificial "lows" where the "head" is not full. Unfortunately the current accuracy of GPS locations (discussed further below) is not sufficiently precise to be able to recognise when, say, half of the head must be over an area already harvested.

Another variable is the time between the heads of grain first entering the header, and the grain being recorded as entering the harvester's storage bin. Different harvesters have different processes which are apphed to the crop after it has been cut and these take different times. In order to test the recording characteristics of the two brands of harvester to which this project had access, the harvesters were driven across open ground and then into the crop and the rate at which the readings rose was recorded. Then in the opposite direction the readings were taken as the harvester left the edge of the crop and continued across open ground, and the rate at which the readings reduced was recorded. It was found that for the International Harvester header the delay was about 15 seconds while for the Gleaner it was 50 seconds. Given that the header was travelling at about 4 miles per hour, the GPS

43 Chapter 4 4.5 Crop Yield Maps location could vary from the actual position of the crop yield position by as much as 80 metres.

Because GPS time is recorded with each position, and because the delay within the harvester seemed to be constant, it was possible to determine the position of the harvester at the time when the grain entering the header would have resulted in the yield monitor reading. This was only possible because GPS locations were being recorded every second, and header speed was quite steady at 4 mph. This steady speed also allowed the effect of some of the errors to be mentioned below to be overcome, as it was not physically possible for the header to have been at some of the'recorded positions given the steady speed. When such an error position was encountered the technique used was to continue reading data along the track of the header until a point which was physically possible was encountered and then use GPS time to approximate the true locations of the intermediate readings.

Figure 4 shows the "raw" track and Figure 5 the "post-processed" corrected track of the harvester for one paddock on the Wright property in Montana. For the corrected track, red Hnes indicate the reading points which are physically impossible to reach given the near constant speed. Usually only one of the Northing or Easting locations had been distorted.

This specific programming would be outside the skill level of most farmer Users, and so a graphical editor is to be included in the Visual Basic prototype which will allow the user to "drag" a reading to a new location, and it will change colour depending upon its Hkehhood of being correct, given near constant speed.

Appendix G shows a 3D colour surface map of the yields which were recorded. This map was produced [Dykes 94] using the GRASS pubUc domain GIS package. As the source code for the GRASS package is also available in the public domain, it would be possible to include in a future prototype version the code for selected routines without having to write them completely. Hence the current prototype was not immediately extended in this area. The usefulness of such displays is difficult to determine from this single trial. However,

. 44 Chapter 4 4.5 Crop Yield Maps they did generate a lot of discussion with the farmer concerned.

Figure 4: Uncorrected track plot

Figure 5: Corrected track plot - red hnes indicate physically impossible points

The actual GPS locations were also subject to error. While there were no difficulties experienced in accessing sufficient satellites to get location "fixes", because of the introduced error with which the US MiUtary degrades the accuracy of locations (Selective Availabil- ity, "SA", introduced in early 1990 to degrade autonomous accuracy to about 100 metres Gilbert 94, p. 52]), a "post processing" correction run was carried out using the readmgs

45 Chapter 4 4.5 Crop Yield Maps from a known reference base station and applying the same corrections to the harvester readings. This processing was carried out with two versions of commercial products and produced two quite different sets of corrected results. The difficulties experienced in this exercise stemmed from the fact that the base station readings were being taken only every five minutes, and the introduced errors change far faster than that. Each of the commercial products made different assumptions about the effects of SA for the readings which fell between the base station readings.

In order to test the nature and extent of the introduced error an experiment was established while on study leave at the University of Leicester during November 1994. As quickly as was possible, for one 24 hour period, the location of a fixed, known receiver was recorded. With 7739 recordings made, the sampling rate was about every 10 to 12 seconds. The results were summarised and then plotted using Excel5, giving Figure 6 on the following page. Each point in the graph represents at least one recording at that position. The axes show the number of meters from the actual location of the receiver. From the results it can be seen that the introduced errors follow a fixed pattern. This is quite different from the very random fluctuations in position reported by Gilbert, that are represented as Figure 7 on the following page [Gilbert 94, p. 57 .

46 Chapter 4 4.5 Crop Yield Maps

-86-

^iiliilliK;:!?

O) !Ec ro z

-2 200 300 400 5

Easting

Figure 6: Coordinate positions from 24 hours.

Noise - These yellow dots represent position data collected by a stationary GPS receiver at the blue triangle's location. These positions are a good representation of receiver noise. The noise in this case, is evident as a Random fluctuation in the positions.

Figure 7: GPS random noise [Gilbert 94, p. 57

47 Chapter 4 4.5 Crop Yield Maps

What is not clear from Gilbert's report is whether his diagram was produced from data collected prior to 1990 when the variations would not be caused by "SA" but by system noise. A further difficulty is that his diagram does not show the actual distance of points from his triangle.

For the Leicester test, the frequency of the number of times which a point was recorded are shown in Appendix H, and a sample of the second-by-second log is provided in Appendix I which illustrates the rate of change in the introduced error is far faster than the 5 minute base station recordings that were made. To illustrate the number of readings at each point, a surface plot was produced in which the height at a point represents the number of times that point was sampled in the 24 hour period. This diagram is shown in appendix J. This graph was produced, with assistance [Hoffman 95], by the package "Splus" running on a Unix system.

The graph shows that 335 of the 7739 readings were recorded within 3 metres of the location of the receiver (point 100,100 on the graph), and that the other high readings were clustered around that point. There is therefore a high degree of accuracy possible if the receiver is stationary and there is sufficient time to average a large number of readings. This is unfortunately not the case with farm machinery in operation.

The data shows that in fact the GPS was changing its selection of satellites in as short an interval as 8 minutes, but sometimes staying with the same satellites for up to 39 minutes.

This leads to two observations:

• Have base station recordings taken at the same rate as the readings in the field (so that the correct correction factors can be applied).

• Treat all result with some scepticism, as commercial packages will make different assumptions about how they handle the intervals between known error readings.

With reference to this last point, while visiting the Royal Agricultural College in Cirencester, I was provided with the output of a trial conducted by Juhan Swindell, Senior Lecturer in Building and Surveying. Julian had been able to borrow a harvester with a yield monitor and a GPS, and already had the Massey Ferguson programs "Yieldmap" and "Surfer" which could be used to generate yield maps of his paddocks. The Map which the package produced is included at Appendix K and appears to indicate regions which are

48 Chapter 4 4.6 Soils Maps differentiated from each other. On a second run his computer suffered a "disk full" error just before the final diagram was produced and left him with the temporary files which the package had created. One of these was the locations of the raw data, and is included as Appendix L. A comparison of the yield map and the locations of the raw data led him to be justifiably sceptical about the "accuracy" of the yield map, as several of the corrected locations (circled on Appendix L) were still outside the boundary of the field. His latest approach is to take the raw data into a GIS program called IDRISI 4.1, and to do the interpolation there. Further discussion on assumptions and accuracy is included in section 4.18 on Interpolation.

A recent development in the VHF band has been the implementation of the Radio Data System (RDS) which is the modulation of Differential GPS corrections (DGPS) onto the FM sub-carrier of commercial radio broadcasts or radio paging systems [Tiwari & Weber 94 . Hawksbee notes that this (RDS) "has significant impHcations for the in-car navigation market which has been previously forced to make use of extra communication links for receiving DGPS corrections or not using them at all and relying upon stand-alone GPS positions" [Hawksbee 94, p. 7]. He estimates that half of all new production Hne cars in Eu- rope now have RDS capability. Earth Observation Magazine [EOM Staff 94, p. 26] quotes the popularity of in-vehicle navigation systems in Japan where "nearly 40,000 new cars per month are sold with the system already equipped". Whether a real time correction capabihty will result in more accurate location co-ordinates remains to be seen. However, the "sub metre" accuracy of GPS units being advertised as currently available [Ashtech 94, p. 30] may only exist under very carefully controlled situations.

4.6 Soils Maps

Most farmers are aware that their paddock boundaries bear little relationship to the soil types contained in them. The Precision Farming motto "farm soils, not fields" points to a move away from the blanket appHcation of treatments to whole fields, both from an economic [Reichenberger k Russnogle 89, p. 11] and a sustainable agriculture view- point [Neilsen 94]. At the Wright property in Montana, and the University Farm in Wagga, detailed soil maps were available for the entire property (see examples in Appendix M). For the Wright property, the maps were scanned and rubber sheeted to correct for distortion, then the operator used a "line following" editor to move the mouse along the boundary lines and so capture the areas associated with each classification. For the University Farm the maps were mounted on a digitising table and a cross-hair cursor was used to record

49 Chapter 4 4.7 Contour Heights linework using the Genamap software. In'each case a series of closed polygons was created for each identified soil type.

4.7 Contour Heights

At the Wright property, for part of the test area, there had been an elevation map constructed several years previously using normal surveying techniques. This map had been used in a previous experiment monitoring soil water retention. This data was laid out on a regular grid and consisted of relative altitudes from a known corner of the paddock. This data was required to be scaled so that the grid offsets were converted to actual UTM co-ordinates, and the relative altitude converted to an absolute altitude.

For the second part of the test area the GPS altitude was used. This data was not on a regular grid, as the measurements were included whenever a yield reading required a "fix". Given the previous discussion on the accuracy problems associated with the GPS locations, these readings need to be treated with caution.

At the University Farm, contour hnes were digitised from paper maps that were mounted on a digitising table and a cross-hair cursor was used to record hnework using the Genamap software, (see Appendix N for a sample of output)

Altitudes are therefore represented in two different ways.

1. By point elevations on either a regular or irregular grid. This data needs to be interpolated to the scale required for the resolution desired to be displayed. This data consists of triplets of Northing and Easting co-ordinates and altitude.

2. By line segments made up of continuous Northing and Easting co-ordinate pairs which represent a particular altitude. From these lines intermediate estimates need to be generated for the required resolution.

The current version of the prototype will use kriging [Deutsch & Journel 92, p. 61] for all intermediate estimates required by either sparse data or required resolution.

50 Chapter 4 4.8 Natural Vegetation

4.8 Natural Vegetation

The natural vegetation details which have been included to date have been areas identified as "light timber" and "scrub". The types of crop being planted is recorded under the "Land Treatment" headings where dates and rates of seed are also recorded. The natural vegetation details were recorded as a series of Hne segments making up a closed polygon and being given the attribute tag identifying the nature of the area. These areas also tend to be the areas which are NOT defined as being anything else.

4.9 Weeds

While some researchers would classify weeds as "natural vegetation" most farmers pay more attention to them, particularly if they are present in their areas of crop. While analysis of satellite images can sometimes be used to determine the extent of particular weed infestations, the farmer is face-to-face with the problem while driving the harvester, as the weeds can be seen in the crop as they enter the harvester "head". In the trial on the Wright property, function keys on the data logging PC were set to capture the GPS location when pressed, and these were assigned to the weeds "thistle" and "morning glory", and also to indicate which areas were "lodged" (the crop was lying flat due to wind or animal trampling). The function keys were pressed when more than 20% of the square in front of the "head" was affected. Two presses in quick succession would indicate 40%, and so on. Even though the farmer is continuously visually monitoring, and adjusting the cutting height and angle of the "head", there seemed to be sufficient time for a good indication of weed levels to be recorded. This data is of interest to researchers [Maxwell 94] who are writing weed-spread simulation programs and studying the weed spreading effects of harvesters (chops them up and spreads them out the back), and the rate at which a single plant will be spread to the extent that it requires spraying to control it. As infestations are very localised, care should be taken not to interpolate weed readings across sparse areas as intermediate points are very likely to be completely weed free. In Australia, The New South Wales Department of Agriculture has developed a "weed detector" crop sprayer Pelton et al 91]. It works on fallow ground and has detectors for each spray nozzle. The nozzle only turns on when the detector sees a green colour (weed) in the fallow (otherwise bare) ground. If this device was also equipped with a GPS recorder then the DeskTop GIS would have the potential to be able to integrate these readings and so track the effectiveness of the weed spraying operation in the next harvest's yield data.

51 Chapter 4 4.IO Salinity

4.10 Salinity

The measurement of salinity at the University farm at Wagga was carried out using non contact ElectroMagnetic (EM) techniques [Slavich k H. 90] at points on a rough grid covering most of the paddocks. From these initial measurements a rough sahnity contour was established (see Appendix 0). This point data can be interpolated to give a surface measure, or the contours can be interpolated as well. A complexity is introduced when subsequent readings are taken at previously unsampled points. What is not clear is whether the new reading is to be treated as an addition to the original set, or whether it is the start of a new set of readings. The concern here is that following a very wet season, readings may be lower in areas which have been "flushed" and following evaporation other areas will test as being more concentrated. The dates of the individual readings are the key to which observations are to be included or not. When the interpolation is to be generated from a contour representation, the assumption is that the readings upon which the contours were based were all taken within an appropriate time frame. Again, the common "farm map" base of the DeskTop GIS has the potential for combining elevation, geology and vegetation in identifying and monitoring salinity problem areas.

4.11 Boundaries and Objects

Regardless of how the locations of boundaries and objects have been determined (on-screen digitisation, keyboard entry, digitising table or GPS), there needs to be a mechanism for updating co-ordinates as new, more accurate data becomes available. In real terms such changes to points and hnes are small, and usually relate to the partitioning of an existing paddock, or the construction of a new road perhaps leading to a new house or shed that has been built. This becomes important" when comparing total paddock yields, as while the physical borders of the paddock remain the same, there may now be an "island" of uncroppable area devoted to buildings. Monmonier devised a simple clockwise direction convention for the external boundary of the paddock, and with a "Hne-cut" from an external point to an internal point on the "island" with counter-clockwise direction of points for the enclave, returning down the same "hne-cut" to the external point [Monmonier 82, p. 69 . In this arrangement, the area of interest always lies to the right of the directional line segments making up the boundary. While this arrangement works well for area and display purposes it creates a problem for the simple calculation of perimeter lengths as the "line- cut" is purely imaginary and would need to be tagged as such, so as to avoid being included

52 Chapter 4 4.12 Activities in perimeter length calculations. The tagging of attributes to individual line segments has not been implemented in the current version of the prototype as this requirement was only discovered quite recently. In the next version there will be a distinction between "real" and "invisible" lines with real lines being things which have boundary lengths, and invisible hnes being artefacts used to tie objects'together (and therefore not being displayed or included in length calculations).

4.12 Activities

As the DeskTop GIS was conceived as a "complete" farm records system, there was a need to record other activities that did not fit neatly under the other more specific farming categories, like the two hours spent welding up a new lug onto the tractor or fitting a new GPS antenna mount on the harvester. It is proposed that these details are entered, together with the time that the farmer spends doing them, through a "spreadsheet" timesheet style of interface. Their use is to be able to allocate farmer time to the particular "enterprises" which are carried out on the farm. In this way costs can be allocated to "sheep" or "cattle" or "crop" and so rates of return can be calculated. While not all farmers are interested in "enterprise accounting" as a farm management tool, it does provide interesting comparisons between activities.

4.13 Land Treatments

These entries cater for the recording of ploughing, seeding, scarifying, spraying and burning- off of paddocks. They can also be used to record harvesting crop yields where there is no GPS and Yield Monitor in use, and only weighbridge figures available. Details entered are very flexible and can include which tractors and trucks have been used and the number of hours for each. In this way the economic model of the farm could relate costs back to produce sales on a paddock basis.

53 Chapter 4 4.I4 Animal Records

4.14 Animal Records

Farmers move animals between paddocks for the benefit of both animal and paddock. An interest was expressed in being able to display a map of the farm which would show the "average days per head per hectare" for each of the paddocks so as to become more aware of the farm manager's habits when moving or placing animals. These records will also detail treatments to the animals like shearing and dipping, and will Hnk to Activity time records for the "enterprise" costing. Exactly how these records will be brought together for analysis and reporting is yet to be determined.

4.15 Extreme Environmental Events

These records are a free format mechanism for the recording of "Acts of God" like bush- fires, flood levels and plagues. It is anticipated that should an occurrence become regular enough then a new type of standard entry would be invented that would standardise the information recorded for that event and the reporting mechanisms operating upon it. So far the prototype has included each event as a unique data type with its own attribute code.

4.16 Weather

Most farmers maintain their own rain gauges, and these entries are the "pocket book" equivalent of the readings. Additional details of maximum and minimum temperatures, and hail and snow can be recorded as well. At present there are no plans to include wind direction and velocity. However, as personal digital weather stations are becoming cheaper and more popular this may be required in the next prototype version.

4.17 Spatial Analysis and Reporting

With only a limited amount of data available, the analysis and reporting functions are still quite primitive. Most data currently accepted by the system is displayed in image format

54 Chapter 4 4 18 Interpolation

either as raster backdrops at various resolutions or as line vectors. As such, the analysis element is more of a "data visualisation" at this stage. As more "rich" data sources become available with the deployment of the next generation of the prototype to farmers for testing and feedback, so additional spatial analysis functions will be included.

What has been designed, but not yet implemented, is the ability to save a displayed collection of objects (images, lines and data) with a particular user definable name (like "sheep 95") so that a particular collection can be revised and refined without having to reassemble the display from the components each time it is required to be viewed or modified. These collections would form image templates for the user and would permit local customisation depending upon the types of data available.

At present there are simple "total" options included for the "spreadsheet" style of tabular data, however templates which draw together costings and operations for the various "enterprises" are seen as the first step towards a series of "operational views" of the farm enterprise. Ultimately, these views should be user customizable so that flexibility of simple reporting is achieved.

4.18 Interpolation

Almost everything needs to be interpolated at some time! This was not an immediately obvious requirement at the commencement of the project, but as the user "zooms in" on an area of interest, it is almost always the case that some of the data being displayed is at too coarse a resolution to be displayed without the generation of intermediate values.

There is much debate on the "best" interpolation techniques to be used under certain circumstances. Time did not permit this area to be extensively researched, and the use of "kriging" in the production of displays at the required resolution was simply to provide the prototype with one such method. Deutsch k Journel state that, "Although kriging was initially introduced to provide estimates for unsampled values, it is being used increasingly to build probabilistic models of uncertainty about these unknown values. In a nutshell, the kriging algorithm provides a minimum error-variance estimate of any unsampled value ... Kriging used as a mapping algorithm is a low-pass filter that tends to smooth out details and extreme values of the original data set. " [Deutsch k Journel 92, p. 61]

This can be useful when there are occasional readings in error. Cressie [Cressie 93,

55 Chapter 4 4.19 Temporal Considerations p. 249] analyses the data given by Mercer and Hall [Mercer k Hall 11] which consists of yields on a 20 x 25 lattice of plots approximately 1 acre in total area. Each of 20 rows runs in the east-west direction and each of 25 columns runs in the north-south direction. Although the data are given on a spatial lattice, he argues that it is possible to think about wheat yields on potential plots located between existing plots. In other words, the spatial index could run continuously over the 1 acre region. He then calculates the intermediate values and then uses those values to generate an error variance estimate of the original data. Using this method he highlights several data points which are highly likely to be in error, and argues that they should be discarded.

It is quite unlikely that the User will be sufficiently skilled in the use of geostatistical methods to be able to use them to weed out the data. The use of the kriging method will, however, provide a useful smoothing without requiring any User adjustment. The prototype will resist kriging certain types of data where the coding indicates that the data represents edges rather than sample values. For example, paddock boundaries or road edges should not be smoothed as the user "zooms in". It is anticipated that future versions of the prototype will have a variety of interpolation methods and will use the appropriate procedure for each data type, without user adjustment. Deutsch & Journel provide the source code (in FORTRAN) which can be translated for the prototype [Deutsch k Journel 92 .

4.19 Temporal Considerations

This project has implemented the abihty to restrict items displayed to a certain date range, but this is just the start of the complexity which is possible when considering the temporal element. Langran asserts that "Fundamental decisions concerning why and how temporal data are to be used have a striking impact on the implementation of a spatiotemporal system." [Langran 93, p. 305] Indeed the type of questions which the User may wish to investigate can change the entire method of access to the data. For example, if one chooses to focus on moments of change, or on overall data currency, or on individual vs. aggregate change. Similarly, a user may require only a simple snapshot of a past moment. Another might prefer to view what was generally true during a particular period [Langran 93, p. 306].

56 Chapter 4 4.19 Temporal Considerations

Langran also identifies alternate temporal interpolations [Langran 93, p. 309] "Imagine these instances of scale change:-

Create a time slice by defining the states of all data in an area as of the given moment. Generalise the time slice to the desired spatial resolution.

• Create a time slice that is a generalisation of a timespan, i.e., generalise to a desired temporal resolution. Then generalise to the desired spatial resolution."

The second case requires algorithms for temporal generalisation. Imagine a case where a feature which had existed for years was absent only for the moment of a requested timeslice, or where a feature exhibits periodicity of change. In the farming environment the rotation of cropping means that a particular paddock may only be used for growing, say wheat, every third year. So when comparing yields for the paddock it will be necessary to establish that the correct crops are being compared. Even if one were to imagine that a feature's trajectory over time is a simple line whose vertices are points of change, the choice of which approach to use for generalisation must be based on the goal of generalisation. Two possible goals exist.

• a) Find the state held for the longest time, i.e., a mode state, and,

• b) Find the state that is most representative of all the states during that time, i.e., a mean state.

Goal a) would be relatively easy to achieve on a feature-by-feature basis for a given timespan using simple arithmetic. Difficulties in reaching Goal b) would relate to how the term "representative" was defined. If some states held during the timespan are quite related, they should be aggregated so as to outweigh another less representative state. Langran states that, "The greatest difficulties would occur if 'state' referred to the overall state of the area during that timespan, rather than the states of individual features." [Langran 93, p. 309

At present the DeskTop GIS permits selection of items to be included in the display collection based upon the area being displayed, the type of data to be displayed, and also the date of the data being recorded. There are no temporal routines in the current version of the prototype.

57 Chapter 4 4.20 Cumulative Histories

4.20 Cumulative Histories

Langran also considers the effects of modifying or correcting the data over time [Langran 93, p. 311] and notes that "Incremental updates can cause edge effects and introduce artefacts that cause data to appear piecemeal or inx:orrect. Inevitably, if only a local area is altered, the borders of that area may not match the surrounding unaltered area." The DeskTop GIS will have this problem where a field's boundaries are altered, but it now overlaps part of its neighbours, or there is an unaccounted-for sliver of land in between. Two options have been identified when faced with such a situation [Langran 93, p. 311

• Leave the dangling linework to dangle.

• Add a closing line and tag it with the source "Cartographic License'

The problem already encountered with the first option is that unclosed paddocks "leak" out when being filled with particular colours, and so closing lines are necessary. The slivers and overlaps problem will need further diagnostic tools to permit Users to rectify potential problems. However, the initial experience with Users indicates they place such considerations in low priority. This would be consistent with the User's priorities being targetted to costs and productivity concerns, nevertheless. Farmers, as the users, will have to be responsible for the accuracy of their own data.

Of a greater consideration is the problem of keeping data in a current format. An attempt has been made to use the data in as close to its original format as possible. This has been accomplished by storing each set of data in its own file format, and having routmes that manipulate and display each type of data. In this way new facilities and data types can be introduced without upsetting the existing data. Langran states that the "least desirable option for guaranteeing the longevity of archived data is to translate the archives in bulk each time newly introduced standards or technology threaten to make them obsolete", and indicates a "better option is to take measures to ensure that the archives never become obsolete." [Langran 93, p. 313] This is a little simplistic as even the media will become obsolete in two to five years, and may not even exist at all in 10 years. For example. Commodore 64 disk format and cassette format databases and word processing formats which were extensively used in the mid to late 80's are now almost unusable. This need to address "technology freeze" and "data roll forward" has been explored by Haynes who arrives at the conclusion that data volume will always outstrip available storage and that

58 Chapter 4 4.21 Future Developments archiving is a selective process of sometimes "preservation", often "summary", and very often selective "abandonment" [Haynes 94 .

Not only do technological advances necessitate the rolling forward of data onto larger and faster devices, but software which existed on older machines is often never made available on the newer equipment, and hence software routines which existed on one platform may not be available on newer environments. Even some later versions of application packages (eg. Word6) will not process files from earlier versions (eg. Word2) requiring an intermediate version (eg. Word4) to read and translate the earlier format into an intermediate format which the latest version will recognise. The costs involved in custom translation of existing data to a new package have to be included in the costs of adopting that package.

4.21 Future Developments

4.21.1 Future Programming Environments

The impact of the programming environment should be considered as one of the variables which will be revisited when future versions of the prototype are constructed. The reason for choosing the AMIGABasic language was that it offered very simple and flexible commands for controlling the mouse and button clicks, windows and colours. The speed problems of a totally interpreted language environment were not initially apparent. The fact that the AMIGA supported a number of computer games with highly animated graphics indicated that the hardware was capable of better performance and that if the prototype had been rewritten in C it would have achieved acceptable window refresh speeds. The fear in moving to C was that the prototyping flexibility would have been lost and so GFA-Basic on faster hardware was the preferred solution. Again, when that environment proved unstable, the search for a new environment focussed on quick and flexible GUI development environments, and Visual-Basic filled that requirement, with adequate window refresh speeds. In the conversion of each version of the prototype to the next, the code which has changed the most has been the code for the GUI, the mouse and button clicks, windows and colours. The rest of the code had remained largely in the state in which it was first developed. Indeed, the file structures have proved to be flexible enough to have so far accommodated all the new data formats which have been encountered. This leads me to conclude from the experience that the perceived flexibility required of the prototyping environment has

59 Chapter 4 4.21 Future Developments assumed a larger than justified sway in the deliberations when choosing the programming environment.

For example, if the same modular coding approach and extensible file structures had initially been coded in C then the window refresh speed problems would not have been a hmitation. As the AMIGA lost out to IBM PC's in the struggle to gain a significant foothold in the marketplace, the prototype would still have had to have been converted, but C compilers with GUI libraries have always been available on the IBM PC hardware, and the effort of conversion may even have been less. Certainly, the current version of the prototype would not have been needed.

The success of evolutionary rapid prototypes therefore seems to rely as much on the approach to the construction of the prototype as it does on the flexibility built into the environment used. It is apparent that graphical applications benefit from the ability to take advantage of low level, machine specific code, when significant processing is required. Further, once written, such code is seldom changed. If future developments in the prototype require a further change of environment I shall pay greater attention to the ultimate performance considerations of the required processing rather than the perceived flexibility of the programming environment.

4.21.2 Economic Modelling

Just as GIS "layers" can be used to represent historical situations, so too can they represent alternate future scenarios. Dr. Duane Griffith is a Farm Management Specialist at Montana State University who is exploring the use of graphical displays for the simulation of farming decisions. His research seeks to allow a farmer to propose a particular farm strategy (ie, certain areas of particular crops and animals) and then to apply different weather and economic scenarios to arrive at a projected income for the farm. In this way a farmer could apply the weather pattern for a "late wet" year, and the market values for a "high return" year and store the projection to permit further "what-if" tuning of the proposed farm strategy. This is an exciting prospect for collaborative research in extending the DeskTop GIS as it will already be recording the data upon which such modelling takes place, and as Dr. Griffith is already experimenting with the models themselves [Griffith 94 .

60 Chapter 4 4.21 Future Developments

4.21.3 3D Projection

While 3D displays were not a high priority at the start of the project, Users respond very enthusiastically to the images which were generated by the other packages (for example, Appendix G). Whether this is just a novelty reaction, or whether the data representation actually allows them to perceive more information is an area worthy of more investigation. The current version of the prototype does not include 3D routines. However, the code is available in some public domain packages (GRASS) and so experimentation with the sorts of displays which Users would find informative will be possible.

61 Chapter 4 4.22 Summary

4.22 Summary

From the experience of using the prototype, and from functionahty identified in the hterature, this chapter has discussed the data processing required to provide farm users with the processing they require. Specifically:

• Decision Support functions;

• Data considerations for the coordinate system, images, and GPS related data, such as yield monitoring;

• Displaying the results of processing, such as analysis of yield maps using 3D pictures, and the interpolation of salinity and altitude readings from point data and from digitised contour lines; and

• Temporal considerations which will come into effect when new data supersedes existing data.

62 Chapter 5

Chapter 5

Conclusions

The DeskTop GIS project has been a very rapid learning experience, and has set the groundwork for on-going development of a more robust version of the prototype. Many challenging requirements have been uncovered. However, nothing has been discovered so far which would indicate that the vision of a DeskTop GIS was unattainable, and the demonstration disk and tutorial in Appendix P gives a good "feel" for the sort of system being contemplated. While the project is still a long way from being the definition of a commercial product it has been able to make some firm recommendations regarding the selection of a graphical prototyping tool, has vindicated the use of the Rapid Structured Prototyping methodology for maintaining a high degree of user enthusiasm in a graphical application, and has detailed the required functionality of some major aspects of a User- Operated DeskTop GIS for Farmers. In summary:-

1. Farmers need to have a certain basic PC dexterity, but they also need to have developed particularly spreadsheet manipulation capabilities to allow them to be happy editing and rearranging the tables of data which typically result from the files created by monitoring equipment. The "user driven" style of the integrated DeskTop GIS concept will require farmers to be custodians of their own data, but, being specifically tailored to a farm application will not require users to import, export and duplicate data between discrete mapping, spreadsheet and database products as many of the current offerings require.

2. More research opportunities exist for the development of the prototype, particularly the use of more colours to signify different attributes, but also faciHties to have multiple windows from different parts of the farm (or indeed from different properties), Chapter 5 5.1 Propositions Revisited

and to link the windows so that operations may be performed on both windows at once rather than having to repeat the actions for each window separately. Additional required functionahty has been identified, as well as the ability to import and export additional data formats.

3. Essential features of the prototyping environment should be tried by benchmark before the actual construction of the product, to estabUsh the performance of those features before making a commitment to that environment. While it is unhkely that this would have uncovered the problems experienced with the GFA-BASIC environment (which only became apparent as the size and complexity of the code grew), it would have identified the graphics Hmitations of the Amiga environment and would have saved considerable time. Indeed, the provision of a rich hbrary of GUI tools would seem, from experience, more important than the actual language facilities.

5.1 Propositions Revisited

Support, with quahfications, can be given to the three original statements:-

1. That the use of the Rapid Prototyping approach is valid for systems involving graphics processing.

This statement is supported. The farmers were eager to install the system upgrades and to enter new data and "see how it looked". User involvement and interest was maintained even in the face of some drawn out periods between revisions and the experience of working with real farm data and taking part in its collection enabled the analyst to better appreciate the user perspective.

2. That domestic ^'personal computer'^ hardware possesses sufficient processing and storage capacity and graphical capabilities to support Rapid Evolutionary Prototyping of a User Driven Desktop GIS.

At the time the project was started (1990) this statement would not have been supported. At present (1996) the entry level machine being purchased for under $2000 is an IBM compatible 486DX4/100 with about 8Mb of RAM and 800 Mb of hard disk. This level of machine appears to be sufficiently powerful to support the required environment.

64 Chapter 5 5.1 Propositions Revisited

3. That sufficiently flexible and efficient programming environments exist on such hardware to carry out the project.

The software field is developing almost as quickly as the hardware field. Windows 3.1 and Visual Basic 3.0 offer a stable environment which supports the facilities required and rich Hbraries of GUI tools exist for languages like C and C++. The initial perception of required flexibility in the programming environment has been eclipsed in importance by an "industrial strength" requirement for dehvering a robust prototype. Recent developments in the JAVA language which is supported by World Wide Web browsers may mean that the provision of imagery and processing may be possible at a reasonable cost from "warehouses" of data providers.

65 Chapter

Bibliography

ACR95 ACRES UPDATE. Austrahan Centre for Remote Sens- ing, Australian Land Information Group (AUSLIG) De- partment of Administrative Services (DAS), Nov 1995.

Arthur 92 L. J. Arthur. Rapid Evolutionary Development - Require- ments, Prototyping and Software Creation. Wiley Series in Software Engineering, 1992.

Ashtech 94 Ashtech. Now, kiss AS goodbye! G.P.S. World, Ad- vanstar Publication^ 5:7:30-31, Jul 1994.

Beard h Chrisman 86 M. K. Beard and N. R. Chrisman. Zipping: new software for merging map sheets. In Proceedings ACSM, volume 1, pages 1-153. ACSM, Falls Church Virginia, 1986.

Bedell 88 R. Bedell. WARP: a program to warp computer drawings, maps and plans. Terra Investigations and Imaging Ltd, Guilford Surrey., 1988.

Berghel 95 H. Berghel. Using the HTML Test Pattern to check HTML client comphance. Computer, pages 63-65, Sep 1995.

Carter 70 C. 0. Carter. Human Heredity. Penguin Books Ltd., 1970.

Chen 76 P. Chen. The Entity Relationship Model - Towards a Unified View of Data. ACM Transactions on Database Systems., 1(1), mar 1976.

Churchill k Attema 94 P. N. Churchill and E. P. W. Attema. The MAESTRO 1 European airborne polarimetric . In International Jour- nal of Remote Sensing, volume 15:14, pages 2707-2717. Synthetic Aperature Radar Campaign, 1994. Chapter BIBLIOGRAPHY

Connell & Shafer 89 J. 1. Connell and L. B. Shafer. Structured Rapid Prototyp- ing. Yourdon Press Prentice-Hall Inc., 1989.

Cressie 93 N. A. C. Cressie. Statistics for Spatial Data - Revised Edition. John Wileyand Sons, 1993.

Dangermond 89 J. Dangermond. The Organizational impact of GIS technology. ARC News, Summer, 1989.

Dangermond 91 J. Dangermond. The Commercial Setting of GIS. In D. J. Maguire, M. F. Goodchild, and D.W. Rhind, editors, Ge- ographical Information Systems - Principles and Applica- tions, pages 55-65. Longman Scientific & Technical, 1991.

Dawson 94 C. Dawson. Precision farming puts links in focus. In SILSOE LINK, volume Issue 7, Summer, page 10. Silsoe Research Institute, Wrest Park, Silsoe, UK., 1994.

Deutsch k Journel 92 C. V. Deutsch and A. G. Journel. GSLIB - Geostatistical Software Library and User's Guide. Oxford University Press, 1992.

DoE 87 DoE. Handling Geographic Information, report of the Committee of Enquiry chaired by Lord Chorley. HMSO, London. Department of the Environment, 1987.

Dykes 94 J. Dykes. Private communication. PhD Student, Univer- sity of Leicester, October 1994.

Edmonds et al 86 E. A. Edmonds, L. Candy, P. Slatter, and S. Lunn. Issues in the design of expert systems for business. In A. Hart and D. Berry, editors. Expert systems human issues. Ko- gan Page., 1986.

EOM Staff 94 EOM Staff. GeoTechnologies are Driving Automated Transportation and Vehicle/Highway Systems. Earth Ob- servation Magazine, April 1994.

Felton et al^l W. L. Felton, A. F. Doss, P. G. Nash, and K. R. McCloy. A mircoprocessor controlled technology to selectively spot spray weeds. Automated agriculture for the 21st century proceedings of the 1991 symposium: Americal Society of Agricultural Engineers, pages 427-432, 1991.

68 Chapter BIBLIOGRAPHY

D. J. Foley and A. Van Dam. Fundamentals of Interactive Foley & Van Dam 82 Computer Graphics. Addison-Wesley Pub. Co., 1982.

D. J. Foley, A. Van Dam, S. K. Seiner, and J. F. Hughes. Foley et al 90 Computer Graphics: Principles and Practice. Addison- Wesley Pub. Co., second edition, 1990.

Gilbert 94 C. Gilbert. Accuracy Specifications of GPS Data Collec- tion Systems. Earth Observation Magazine^ April 1994.

Govier 96 D. Govier. Private communication. P & D Systems, Jan- uary 1996.

Griffith 94 D. Griffith. Private communication. Montana State Uni- versity, August 1994.

Harker 87 S. D. P. Harker. The role of user prototyping in the system design process. In B. Knave and P. G. Wideback, editors. Work with Display Units 86, Holland. Elsevier Science Publications., 1987.

Hawksbee 94 D. J. Hawksbee. Offshore positioning systems - part 2. In Surveying World., volume 3:1, pages 17-20, November 1994.

Haynes 94 J. R. Haynes. Aeon-Term Electronic Archiving. Un- published M.Sc. thesis, Department of Computer Science, University College, University of New South Wales, Aus- tralian Defence Force Academy, 1994.

Henderson 86 D. A. Henderson. The trillium interface design environment. In Proceedings of CHr85, Human Factors in Com- puting Science. Boston ACM, New York., 1986.

Hix k. Hartson 86 D. Hix and H. R. Hartson. An interactive environment for dialogue development: its design, use and evaluation; or is aide useful? In Proceedings of CHPSO, Human Factors in Computing Science. Boston, ACM, New York., 1986.

Hoffman 95 D. Hoffman. Private communication. University College, ADFA, November 1995.

69 Chapter BIBLIOGRAPHY

Hutn 93 N. Hutn. The Driving Forces of Global Change. In As- pen Global Change Institute's Fourth Annual Walter Orr Roberts Memorial Public Lecture Series. Aspen, Colorado, USA, 1993.

Kehoe 95 L. Kehoe. Interactive video to be launched "next year". The Australian newspaper^ Tuesday, 10 October, 1995.

Langran 93 G. Langran. Issues of implementing a spatiotemporal system. International Journal of Geographic Information Systems, 7(4):305-314, 1993.

MacLean et al 86 A. MacLean, P. Barnard, and M. Wilson. Rapid prototyping of dialogue for human factors research: the easie approach. In Proceedings of the Second Conference of the British Computer Society Human Computer Interac- tion Specialist Group "People and Computers: Designing for UsabilityCambridge, England,. Cambridge Univer- sity Press., 1986.

Maxwell 94 B. Maxwell. Private communication. Cropping Systems Ecologist, Montana State University, August 1994.

Medyckyj-Scott et al 90 D. Medyckyj-Scott, I. A. Newman, D. R. F. Walker, and C. L. N. Ruggles. The use of HyperCard as a Rapid Pro- totyping Tool: A Case Study of the Development of Two Geographical Information Retrieval Systems. Research Re- port No 9. Midlands Regional Research Laboratory, 1990.

Mercer & Hall 11 W. B. Mercer and A. D. Hall. The experimental error of field trials. Journal of Agricultural Science, Cambridge, 4:107-132, 1911.

Monmonier 82 M. S. Monmonier. Computer Assisted Cartography. Prentice^Hall, Englewood Cliffs, N.J., 1982.

Muller 93 J. C. Muller. Latest developments in gis/hs. International Journal of Geographical Information Systems, 7(4):293- 303, 1993.

Munro 92 D. Munro. Defining the functionahty of a desktop gis: An apphcation of rapid structured prototyping. In Fourth

70 Chapter BIBLIOGRAPHY

Colloquium of the Spatial Information Research Centre. University of Otage, Dunedin, New Zealand, May 1992.

Neilsen 94] G. Neilsen. Private communication. Montana State Uni- versity, August 1994.

NFS 95] NFS. NFSnet backbone traffic distribution statistics. http://www. cc. gatech. edu/gvu/stats/NFS/merit.html^ Apr 1995.

Parker 94] D. Parker. Project management of land information. Sur- veying Worlds 3(1), November 1994.

Peterson 93] K. Peterson. SDSS for real estate investment analysis. International Journal of Geographic Information Systems., 7(4):379-392, 1993.

Reichenberger h Russnogle 89] L. Reichenberger and J. Russnogle. Farm by the foot. Farm Journal, Mid-March:ll-18, 1989.

Richards 86 J. A. Richards. Remote Sensing Digital Image Analysis - An Introduction. Springer-Verlag, 1986.

Richards 93 J. A. Richards. Digital image processing in remote sensing: Recent advances and future trend-s. In E. G. Mas- ters and J. R. Pollard, editors. Proceedings of Conference on Advanced Remote Sensing., pages 291-297. Centre for Remote Sensing and CIS, The University of New South Wales, 1993.

Saalfeld 88 A. Saalfeld. Conflation: automated map compilation. In- ternational Journal of Geographical Information Systems, 2(3):217-228, 1988.

Shepherd 92 I. D. H. Shepherd. Information integration and gis. In D. J. Maguire, M. F. Goodchild, and D. W. Rhind, editors, Geographical Information Systems - Principles and Applications, pages 337-360. Longman Scientific k Tech- nical, 1992.

Simon 73 H. A. Simon. The structure of ill structured problems. pages 181-201, 1973.

71 Chapter BIBLIOGRAPHY

Simon 78] H. A. Simon. Information-processing theorey of human

problem solving. In W. K. Estes, editor, Handbook of Learning and Cognitive Processes, volume 5, pages 271- 295. Hillsdale, NJ: Erlbaum, 1978.

Slavich k H. 90] P. G. Slavich and Petterson G. H. Estimating Average Rootzone Salinity from Electromagnetic Induction (EM- 38) Measurements. Australian Journal of Soil Research, 28(3):453-463, 1990.

Steneker k Bonham-Carter 88] M. Steneker and G. F. Bonham-Carter. Computer Pro- gram for Converting Arc-Node Vector Data to Raster For- mat, volume KIZ 8R7. Geological Survey of Canada, 1988.

STL, Woodside 95 STL, Woodside. STRUMAP. The Slough, Studley, War- wickshire, B80 7EN, UK, 1995.

Surveyor 94 Surveyor, 1994. 10 November :p. 40.

Synder 82 J. P. Synder. Map Projections Used by the U.S. Geological Survey, Geological Survey Bulletin 1532. United States Government Printing Office, Washington, second edition, 1982.

Tiwari k Weber 94 A. Tiwari and L. Weber. Proceedings of the Third Inter- national Conference on Differential Satellite Navigation Systems. DSNS94, Canary Wharf, London, UK., April 1994.

Tomhn 92 C. D. Tomlin. Cartographic modelling. In Goegraphical Information Systems - Principles and Applications, pages 362-374. Longman Scientific k Technical, 1992.

Tyler 94 D Tyler. Private communication. Montana State Univer- sity, August 1994.

Wood 94 J. Wood. Private communication. CIS Lecturer, Univer- sity of Leicester, October 1994.

72 Appendix A Charles Sturt University (CSU), Wagga Wagga, NSW, Australia. Image displayed using 16 colours.

A-1 Appendix B

Aerial Photograph of paddocks on the Wright Property, Belgrade, Montana, USA.

B -1 Appendix C

Display of different image bands in 2 x 2 pixel matrix.

Each band is in a single colour, and in only four intensities.

C-1 Appendix D

Paddock boundary linework, Charles Sturt University (CSU) Farm, Wagga Wagga, NSW, Australia.

D-1 fT g tf crq NLRTH Ct F 1. 35 p

HAIRY 36 3 FARM 37 o icl2 ET 1 CO 3i] ?r CA C/3 c

d M 3 ft)

n C/3 Cd

p CTQ QTQ

crq orq P >

C/3 rti 3 tSTELLA ESTATE: & J \ LEA:$EII FRGH V.'VCC X y W cs Jh AK Cl 275 METRES IR MAillNNESS FER 1991 SCALE Appendix F

DEFINING THE FUNCTIONALITY OF A DESKTOP GIS: AN APPLICATION OF RAPID STRUCTURED PROTOTYPING

Donald Munro

Department of Computer Science University College, Australian Defence Force Academy Northcott Drive, Campbell, ACT 2600 Australia E-mail: [email protected]

Presented at the Fourth Colloquium of the Spatial Information Research Centre, University of Otago, Dunedin, New Zealand, 18-20th May 1992.

ABSTRACT

The availability of relatively cheap remotely sensed imagery from a variety of sources has stimulated an interest in combining an analysis of this new data, with the more traditional data available to farmers, to provide a richer information base as the foundation for agribusiness decisions. In parallel, the continuing price/performance advances in the area of microcomputer equipment are delivering the sort of processing and data storage capabilities in the domestic desk top microcomputer which would once have cost hundreds of thousands of dollars and would have required complete rooms full of equipment contained in temperature sensitive environments.

This paper is part of a research effort aimed at the production of a microcomputer based, user-driven, DeskTop GIS. This effort is not a simple downsizing (taking a large-machine GIS and running it on a small machine), but a fundamental investigation of the facilities and capabilities required in such a system, and the mechanisms appropriate to the size and scale of the target users and equipment. This paper details the use of a Rapid Prototyping methodology for the investigation and analysis of the functional requirements of the DeskTop GIS.

INTRODUCTION

By and large the geographic information system (GIS) products on the market today are refinements and developments of high powered tools which have their origins in the scientific or research community. If those origins are more than six or seven years old then it is highly probable that the original programs were written in either a mainframe, or high powered minicomputer environment, and were controlled by a series of instructions and parameters typed in a command line. Furthermore, if graphic displays were employed at all they were often restricted to viewing only the output of operations. They were commonly on a separate display to that used to control the running of the program. Many of these programs were "evolutionary" in their construction with new features and additional commands being added as the requirement became apparent. Often a series of different progranmiers would contribute to the functionality of a program at different times, and unless strict controls on documentation and style were enforced the program would exhibit the multiple personalities of its multiple creators.

F-1 Appendix F

Modem, "user friendly", microcomputer based software is much more tlian just a downsizing and repackaging of existing programs. The conmionly provided graphical user interface (GUI) is more than just another way to build up a command line. The widespread penetration of some personal productivity software into a previously naive market bears testimony to the rapid acceptance of user required facilities, delivered via an intuitively simple interface. An example of this can be seen in the area of word processing. Early systems (nroff, runoff), had formatting conmiands embedded within the text, and required a previewer to be run in order to see the formatted results prior to printing. These programs were seldom used by other than people employed in the computing industry. The second wave was when many 8 bit, and some of the early 16 bit microcomputers, were supplied with the Wordstar word processing program which offered some of the first "what-you-see-is-what-you- get" (WYSIWYG) facilities by interactively displaying a representation of the finished text at the time the user typed the lines. Word processing came out of the technical closet and was embraced by a much wider clientele including its use by typists, secretaries and by some individuals. The third wave was heralded by more powerful microprocessors and graphics screens in which the user controlled the operation of the program utilizing not only the keyboard, but also pull down menu blinds, via a mouse. Such systems showed proportional spacing between characters, and provided full visual control over the size and style of the typefonts. Modem desk-top-publishing programs now provide facilities far beyond these and even some of the latest word processing programs allow the manipulation of images and the totalling of figures in columns.

It should be noted immediately that none of these facilities have made the user a publishing or layout expert, they have simply provided an appropriate vehicle to enable a segment of the potential users to achieve a desired end, with a minimum of time invested in training.

Which wave is the GIS movement riding? There are lots of examples on the first wave; technical tools often tailored and written for specific tasks and operated by highly trained individuals. There are also several systems on the second wave; although they tend to be targetted at specific market niches, and some still require extensive training investment. Who is on the third wave, or is at least paddling strongly toward it, and who is looking at the sort of facilities required by relatively small farming operations?

PROBLEM USERS

The design of a system for small farming operations would be very simple if the farmers would only tell the analysts what facilities they wanted! Conversely, if it was possible to simply tell the farmers, (in finite time!), the sorts of facilities which could be provided for them then they could indicate the things which they thought would be useful and the system could be built. The computer scientists know what is technically possible and the analysts know what other people have done in the past, but what is not known is the sorts of things a fanner would like to do, and how to empower them to do it through an intuitively consistent, user friendly interface.

The suggestion has been made that perhaps agricultural advisers or consultants would be useful intermediaries as they generally have a higher level of technical expertise and a broader perception of the possibilities. While this may be tme, they are not the ones who are going to be using the system day in and day out. How many managers would choose the word processing program their secretary would use? In effect, the choice of facilities is a moving target. In an initial exposure, the user will focus only on the main features which seem desirable. After a short time more advanced features are deemed as now desirable, and in time the vaulting user expectations may overtake the capability of the equipment The symbiotic relationship between user experience of the system and user requirements of the system makes the definition of requirement an ideal environment for the rapid stmctured prototyping methodology.

F.2 Appendix F

THE RAPID PROTOTYPING METHODOLOGY Connell and Schafer (1989) describe the methodology as producing "a dynamic visual model providing a communication tool for customer and developer that is far more effective than either narrative prose or static visual models for portraying functionality." This model has four key attributes:- 1. It is functional after a minimal amount of effort. 2. It is a means for providing users of a proposed system with a physical representation of key parts of the system before implementation commences. 3. It is flexible. Modifications should require minimal effort and be achieved quickly and without programmer resistance. Experimentation is encouraged. 4. It does not necessarily represent the complete system in either function or method of implementation. Of these the third attribute is often the most important The user may express a desire to do something in a different manner, or to revert to a previous approach when a current method becomes too tedious or unwieldy as operations become more complex. The efficiency of the processor and storage are not important considerations during the building of the prototype. For this reason the computer language used for the prototype may be completely different from the final language of implementation. What is important is that the developer record the rationale for the adoption or discarding of various features or approaches so that the "dead-ends" are documented along with the fruitful paths. Some features may be too complex to build completely in the prototype environment and may be replaced by gross approximations so as to give the "feel" of the final system. Delays are introduced where the approximation takes significantly less time to achieve than the real processing, so as to provide authentic "feel". It is most important that "momentum" be maintained in the provision of features and suggestions, and that the user is an active participant in the whole process. Where possible, samples of real data should be used in the prototype so that users can apply their intuitive "reasonableness" tests to the results.

THE IMPLEMENTATION AND RESULTS In a perfect world with no constraints the choice would have been a high level fourth generation language which supported graphics and came equipped with a variety of alternatives for the style of user interaction. In the real world, a historical situation existed in which easy access was possible to a laboratory of Amiga microcomputers, with access to other equipment more restricted. Also, Amiga programming experience was available, as were the facilities for transferring farm data and images from a minicomputer to the Amiga, The colour graphics capabilities of the Amiga were satisfactory for the prototyping task, and the AmigaBasic programming language, while only an interpreted environment, seemed flexible and fast enough for the task as it contained high level commands for the operation of windows and menus and supported mouse interaction. When prototyping in a third generation language it is very important to use a highly modular programming approach. This is required to isolate the extent of changes to just single routines, and to allow easy regrouping of functionality and reuse of common routines. The use of subprograms with local variables is recommended to further insulate working code from areas of change.

F-3 Appendix F

The initial interface utilized a high resolution screen (640 x 512) with up to 16 colours available for display. With this it was discovered that the choice of colours had to be user selectable as the extent of colour blindness of the operator greatly affected both the quality and quantity of displayed data which could be assimilated. In addition, some of the users were long sighted, and found difficulty reading the regular 80 column size of text on the computer screen, and so displays were changed to a double width 40 column size. The final nail in the coffin for the high resolution screen was the difficulty which older novice users had in attempting to direct the mouse pointer to desired locations. This required the menu items to be made wider and thicker and the mouse movements to be desensitized, and keyboard equivalents to be programmed for most instructions, to overcome the lack of dexterity.

The second interface utilizes a low resolution screen (320 x 256) with up to 16 colours. This provides thicker line drawings, large characters, and easy to hit menu items.

The initial prototype data available was for the Charles Sturt University Farm. This data was provided in several different formats which initiated consideration of complex questions regarding the extent of facilities which should be provided for user initiated data transfer.

Graphical data for fence boundaries, roads and creeks was presented as unordered vector line segments which had been captured either from a digitising tablet, or a student survey team. Specifically tailored routines were initially written to include each set, however it soon became apparent that some of the data was wrong and would need the provision of an editing facility to rearrange the order of the points, or adjust obvious position errors. In particular, sorting out which line segments made up which paddocks, and finding that 30% of paddocks lacked completed perimeters took more programming time than was initially anticipated. Graphical satellite image data was available in some "standard" formats, and was supplemented by artwork created with a PC painting/drawing package.

It became apparent that a high degree of flexibility would be required in loading different formats, with subsequent facilities for manipulating the image before storing it in the system. At the time of writing, exploratory efforts were being made to utilise the features of PBMPLUS, an Extended Portable Bitmap Toolkit created by Jef Poskanzer. This toolkit currendy converts over 50 image formats to and from a portable format which can be read and written by the system providing two way compatibility.

Many farmers already utilize spreadsheet and database programs for farm records, however these records do not usually include any spatial reference. Most of these programs provide the option of storing data in delimited ASCII format transfer files. In order to accept such data, the DeskTop GIS user must be able to create a data structure and load it from the transfer file. Once loaded the data needs to be given a spatial orientation, ie. to be located independently using a set of coordinates or to be tagged to other objects which have a set of coordinates (like a field or paddock). The "point and click" method is currently being explored. This allows the user to indicate the particular paddock of interest by locating the mouse pointer in an area of the farm outline. Only once the records have a spatial reference can they be analysed by location.

The development of the prototype has included control standards which are common in the use of other productivity tools. Thus a single click of the mouse locates a starting point, or activates a menu. A double click selects the item being pointed at, and depressing a key while double clicking makes an additional selection. Double clicking an akeady selected item turns off the selection. Once selections have been made, other operations can be called (eg, area and perimeter calculations, classifications, data entry or retrieval).

F-4 Appendix F

Where data must be entered through the keyboard, a form is presented on the screen to be filled in. Clicking on a field allows data to be entered or changed. These forms have to be dynamic to accommodate the user defined data structures. Analysis of this data includes totals and counts of selected items, as well as maximums, minimums and other statistical information. Consideration is being given to the provision of a "visual on-screen calculator" as there appears to be a requirement for small calculations to be made using figures on the screen. The calculator would allow figures to be copied from the screen into the operations and so eliminate keying errors.

One of the main challenges which the prototype development will face is to deliver advanced features to the experienced user without confusing or cluttering the options for the beginning user. The option currently favoured is the provision of "long" and "short" menu blinds. The user who selects short menu blinds will only be presented with the operations which have been shown to be of interest to beginning users. Once long menu blinds are activated the whole range of options are available.

At the time of writing, the exposure of the prototype to real fanners has been limited to the initial interface and simple graphics selections and statistics. Exposure will increase as a greater amount of data is loaded and more features are added. As the University Farm is the subject of study by agricultural students in the Faculty of Science and Agriculture, it is planned to trial the prototype with them also.

CONCLUSION

When using prototypes in determining the type and style of features required in a system the builder is always faced with making a compromise between delivering exacdy what the user asks for, or a much simpler, close approximation. My own experience with the law of diminishing returns is that when the prototyping tool is being fully stretched to provide the functionality then the compromise point has arrived. When effort is being spent researching the "best way" to make the prototyping tool achieve an objective, then the prototype should probably not be used to provide that objective, and an approximation should be substituted to provide a realistic simulation. Care has been taken to ensure that the time spent arriving at the approximation is not out of step with the rest of the system (ie, where the approximation is available in a few seconds but where the real result in a real system might take several minutes).

The prototyping methodology confronts problem areas very quickly and causes decisions of approach and style to be made at a very early stage. These decisions may need revision at later stages. A highly modular approach has proved effective in isolating the extent of programming changes in this third generation prototype.

The power and flexibility of the prototyping environment affects the extent to which it is feasible to develop the prototype. While the Amiga programming environment has been quick to change, and easy to use, many features which would be user adjustable in a real system have been hard coded in the interests of simplicity. This is a reasonable compromise for a third generation prototype.

The current effort is certainly not riding the third wave, but is paddling towards it, though it is not yet even in sight. The program will be demonstrated during the presentation to give a feel for the type of environment being researched. Demonstration disks will be available for those who would like to explore further. While conscious of the primitive nature of these struggling first steps it is encouraging to remember that the first Macintosh word processor (MacWrite), running from a single 400K floppy disk in a machine with 128K was restricted to approximately five pages of text; and yet it radically changed the way a person could achieve a professionally produced document. Perhaps that is a wave on the horizon!

F-5 Appendix F

REFERENCES Connell, J. L., and Schafer, L. B., Structured Rapid Prototyping, Yourdon Press, Prentice-Hall Inc., 1989. Poskanzer, Jef., PBMPLUS - Extended Portable Bitmap Toolkit.

ABOUT THE AUTHOR Donald Munro, BA A.N.V. MACS Don Munro is currently conducting research towards a M.App.Sci. at the Centre For Image Analysis, Charles Sturt University, Riverina, Australia. He entered the computing field in 1967 and worked as a programmer and analyst until 1976 when he was appointed System Director of Albury Computer Centre, a rural bureau operation. In 1979 he joined the (now) Charles Sturt University, Riverina, and held the position of Senior Lecturer and Course Coordinator of the Graduate Diploma in Applied Science (Computing). Since 1991, he has been a Senior Lecturer in the Department of Computer Science at the University College, Australian Defence Force Academy in Canberra, Australia.

F-6 Appendix G

3D colour surface map of Crop-Yield readings, Wright Property, Belgrade, Montana, USA.

Image produced using GRASS (Public domain GIS package).

G-1 Frequency of recorded locations Appendix H

Northing Easting Frequency 0 -3 335 0 6 318 6 -3 303 -5 -3 261 6 6 259 -5 6 212 0 -12 209 6 -12 202 -5 -12 189 12 -3 184 12 6 184 0 16 179 11 -12 170 -11 -3 167 -5 16 163 6 16 150 -11 -12 140 12 15 135 17 -4 134 -11 6 130 17 6 126 1 24 123 -11 16 111 -5 25 99 6 24 97 -6 -22 96 6 -22 96 17 15 96 17 -12 90 12 24 87 -17 -12 84 0 -22 82 -17 6 79 11 -22 76 -11 -21 74 -17 -3 67 23 -4 67 23 -13 60 -11 25 59 23 6 55 17 -22 54 0 -31 53 -17 -21 51 17 24 50 -11 -31 48 -17 16 47 1 34 47 23 15 45 5 -31 41 -22 -3 40 -5 34 39

H-1 Frequency of recorded locations Appendix H

6 34 39 -22 -12 37 -6 -31 35 29 -4 31 11 -31 30 -6 -40 28 29 15 27 -16 25 27 -22 6 26 28 -13 26 17 -31 25 12 34 25 0 -40 24 23 24 23 29 6 23 -22 16 23 22 -22 23 34 -13 21 -5 43 20 -28 7 19 -22 25 19 -10 44 19 18 34 19 29 24 19 -12 -40 18 -10 34 18 11 -40 18 1 43 18 -17 -31 18 -23 -21 18 5 -40 17 -18 -49 17 -12 -49 16 5 -50 15 -34 -12 14 34 -4 14 22 -31 14 -17 -40 14 28 -22 13 -16 44 13 -1 -49 13 1 52 13 -16 34 12 -4 52 12 28 -32 11 -28 25 11 -16 53 11 23 34 11 -28 -12 10 40 -4 10 34 6 10 -27 34 10 -22 34 10

H-2 Frequency of recorded locations Appendix H

-23 -31 10 -12 -59 10 7 43 10 29 34 10 -28 -3 9 7 52 9 34 24 9 34 15 9 -34 -3 8 33 -41 8 -16 62 8 -10 62 8 11 -50 8 12 43 8 39 -41 8 -19 183 8 -10 52 7 -6 -49 7 18 43 7 -28 16 7 39 -32 7 45 -32 7 -28 -21 7 40 24 7 -34 7 7 35 33 7 -4 62 7 -33 25 6 -22 44 6 -23 -40 6 12 52 6 39 -22 6 16 -40 6 -23 -59 6 7 62 6 -21 53 5 11 -59 5 34 -32 5 50 -41 5 16 -50 5 -29 -40 5 13 71 5 -34 -21 4 -39 -12 4 22 -40 4 -18 -59 4 34 -22 4 -39 -3 4 40 6 4 40 33 4 28 -50 3 -27 44 3 -21 62 3

H-3 Frequency of recorded locations Appendix H

-33 16 3 28 -40 3 -29 -49 3 22 -50 3 46 5 3 40 15 3 1 71 3 18 52 3 7 80 3 -40 -31 2 -39 -21 2 4 -115 2 4 -96 2 5 -87 2 40 -13 2 -45 7 2 -16 71 2 50 -32 2 45 -22 2 51 15 2 5 -68 2 -23 -67 2 -29 -58 2 1 62 2 18 80 2 18 89 2 7 71 2 13 62 2 24 52 2 45 -41 2 -23 -49 2 45 -13 1 -18 -86 1 -12 -77 1 -12 -68 1 -6 -77 1 -7 -87 1 -1 -87 1 10 -105 1 10 -87 1 51 -13 1 -6 -59 1 -34 -49 1 -51 -49 1 -45 -30 1 56 -41 1 62 -41 1 45 -4 1 63 5 1 57 5 1 74 23 1 46 15 1 -39 7 1

H-4 Frequency of recorded locations Appendix H

-45 -3 1 -14 173 1 -50 415 1 -24 229 1 -15 127 1 -25 211 1 -38 442 1 -39 378 1 5 -77 1 11 -68 1 5 -59 1 -1 -59 1 40 43 1 -24 -86 1 -23 -77 1 -27 62 1 -10 71 1 -4 99 1 -4 90 1 19 99 1 18 61 1 13 89 1 13 80 1 18 71 1 7 89 1 29 52 1 24 61 1 -33 53 1 -33 44 1 50 -60 , 1 50 -50 1 45 -50 1 39 -60 1 -28 -31 1 46 24 1

H-5 Sample of Data Log Appendix I

Count GPS Time Northing Easting Satellites Used

1 15.84583 52.623 -1.12333 16 17 26 27 2 15.84861 52.623 -1.12317 16 17 26 27 3 15.85194 52.62283 -1.12317 16 17 26 27 4 15.85444 52.623 -1.123 16 17 26 27 5 15.85778 52.62283 -1.123 16 17 26 27 6 15.86083 52.62283 -1.123 16 17 26 27 7 15.86361 52.623 -1.12317 16 17 26 27 8 15.86639 52.62283 -1.123 16 17 26 27 9 15.86861 52.62283 -1.123 16 17 26 27 10 15.8725 52.62283 -1.123 16 17 26 27 11 15.87361 52.62267 -1.123 16 17 26 27 12 15.87361 52.62267 -1.123 16 17 26 27 13 15.87361 52.62267 -1.123 16 17 26 27 14 15.90917 52.62267 -1.1235 12 23 26 27 15 15.9125 52.62283 -1.12333 12 23 26 27 16 15.91528 52.62267 -1.12333 12 23 26 27 17 15.91833 52.62283 -1.12333 12 23 26 27 18 15.92111 52.62283 -1.12367 12 23 26 27 19 15.92389 52.62267 -1.12333 12 23 26 27 20 15.92667 52.62283 -1.1235 12 23 26 27 21 15.92972 52.62267 -1.1235 12 23 26 27 22 15.9325 52.62267 -1.12333 12 23 26 27 23 15.93528 52.62283 -1.12333 12 23 26 27 24 15.93806 52.62267 -1.12333 12 23 26 27 25 15.94111 52.62267 -1.12317 12 23 26 27 26 15.94389 52.62267 -1.12317 12 23 26 27 27 15.94667 52.62267 -1.123 12 23 26 27 28 15.94944 52.62267 -1.12333 12 23 26 27 29 15.9525 52.62267 -1.12333 12 23 26 27 30 15.95556 52.62267 -1.12333 12 23 26 27 31 15.95778 52.6225 -1.12333 12 23 26 27 32 15.96111 52.62267 -1.1235 12 23 26 27 33 15.96444 52.62267 -1.1235 12 23 26 27 34 15.96722 52.62283 -1.12333 12 23 26 27 35 15.97028 52.62267 -1.1235 12 23 26 27 36 15.97306 52.62267 -1.12333 12 23 26 27 37 15.97611 52.62283 -1.1235 12 23 26 27 38 15.97889 52.62283 -1.1235 12 23 26 27 39 15.98194 52.62267 -1.1235 12 23 26 27 40 15.985 52.62283 -1.1235 12 23 26 27 41 15.98778 52.62267 -1.1235 12 23 26 27 42 15.99056 52.62267 -1.12383 12 23 26 27 43 15.99361 52.62267 -1.12367 12 23 26 27 44 15.99639 52.62267 -1.1235 12 23 26 27 45 15.99917 52.62267 -1.1235 12 23 26 27 46 16.00222 52.62267 -1.1235 12 23 26 27 47 16.005 52.62267 -1.1235 12 23 26 27 48 16.00806 52.62267 -1.1235 12 23 26 27 49 16.01056 52.62267 -1.1235 12 23 26 27 50 16.01361 52.62267 -1.12333 12 23 26 27 51 16.01667 52.62267 -1.12317 12 23 26 27

I-l Sample of Data Log Appendix I

52 16.01944 52.62267 -1.12317 12 23 26 27 53 16.0225 52.62267 -1.12317 12 23 26 27 54 16.02556 52.62267 -1.123 12 23 26 27 55 16.02833 52.62267 -1.12317 12 23 26 27 56 16.03139 52.62267 -1.12317 12 23 26 27 57 16.03444 52.6225 -1.12283 12 23 26 27 58 16.03722 52.62267 -1.12283 12 23 26 27 59 16.04028 52.62267 -1.12283 12 23 26 27 60 16.04333 52.62283 -1.12317 12 23 26 27 61 16.04611 52.62267 -1.123 12 23 26 27 62 16.04944 52.62267 -1.123 12 23 26 27 63 16.0525 52.62283 -1.12333 12 23 26 27 64 16.05472 52.62267 -1.12317 12 23 26 27 65 16.05778 52.62283 -1.12317 12 23 26 27 66 16.06083 52.62267 -1.12317 12 23 26 27 67 16.06361 52.62283 -1.12333 12 23 26 27 68 16.06667 52.62283 -1.12333 12 23 26 27 69 16.06972 52.62283 -1.1235 12 23 26 27 70 16.0725 52.62283 -1.1235 12 23 26 27 71 16.07528 52.62283 -1.12333 12 23 26 27 72 16.07806 52.623 -1.12333 12 23 26 27 73 16.08139 52.62283 -1.12333 12 23 26 27 74 16.08389 52.62283 -1.12317 12 23 26 27 75 16.08694 52.62267 -1.12317 12 23 26 27 76 16.09 52.62283 -1.12317 12 23 26 27 77 16.0925 52.62283 -1.12333 12 23 26 27 78 16.09556 52.62267 -1.12333 12 23 26 27 79 16.09833 52.62267 -1.12333 12 23 26 27 80 16.10139 52.62267 -1.12317 12 23 26 27 81 16.10389 52.6225 -1.123 12 23 26 27 82 16.10722 52.62267 -1.123 12 23 26 27 83 16.10944 52.6225 -1.123 12 23 26 27 84 16.11306 52.6225 -1.123 12 23 26 27 85 16.11583 52.6225 -1.123 12 23 26 27 86 16.11889 52.62233 -1.123 12 23 26 27 87 16.12167 52.6225 -1.123 12 23 26 27 88 16.12472 52.6225 -1.123 12 23 26 27 89 16.1275 52.62233 -1.123 12 23 26 27 90 16.13056 52.62233 -1.12283 12 23 26 27 91 16.13361 52.62233 -1.123 12 23 26 27 92 16.13639 52.62233 -1.123 12 23 26 27 93 16.13917 52.62233 -1.12317 12 23 26 27 94 16.14194 52.62233 -1.123 12 23 26 27 95 16.14222 52.62233 -1.123 12 23 26 27 96 16.14222 52.62233 -1.123 12 23 26 27 97 16.14222 52.62233 -1.123 12 23 26 27 98 16.165 52.62233 -1.12333 26 27 16 17 99 16.16833 52.62233 -1.1235 26 27 16 17 100 16.17083 52.62233 -1.1235 26 27 16 17 101 16.17417 52.62233 -1.1235 26 27 16 17 102 16.17694 52.62233 -1.12333 26 27 16 17 103 16.17972 52.62233 -1.1235 26 27 16 17 104 16.18278 52.62233 -1.1235 26 27 16 17

1-2 Sample of Data Log Appendix I

105 16.18556 52.62233 -1.1235 26 27 16 17 106 16.18833 52.62233 -1.12317 26 27 16 17 107 16.19139 52.62217 -1.12333 26 27 16 17 108 16.19444 52.62233 -1.12333 26 27 16 17 109 16.1975 52.62233 -1.12317 26 27 16 17 110 16.2 52.6225 -1.12317 26 27 16 17 111 16.20306 52.62233 -1.12317 26 27 16 17 112 16.20583 52.62233 -1.123 26 27 16 17 113 16.20861 52.62233 -1.12317 26 27 16 17 114 16.21111 52.6225 -1.123 26 27 16 17 115 16.21444 52.6225 -1.12283 26 27 16 17 116 16.21722 52.6225 -1.123 26 27 16 17 117 16.22 52.6225 -1.12283 26 27 16 17 118 16.22361 52.62233 -1.123 26 27 16 17 119 16.22639 52.6225 -1.12283 26 27 16 17 120 16.22944 52.6225 -1.123 26 27 16 17 121 16.23194 52.6225 -1.12283 26 27 16 17 122 16.235 52.6225 -1.123 26 27 16 17 123 16.23778 52.6225 -1.123 26 27 16 17 124 16.24083 52.62267 -1.12317 26 27 16 17 125 16.24389 52.62283 -1.12317 26 27 16 17 126 16.24639 52.62283 -1.123 26 27 16 17 127 16.24944 52.62267 -1.12283 26 27 16 17 128 16.2525 52.62283 -1.123 26 27 16 17 129 16.25472 52.62267 -1.123 26 27 16 17 130 16.25806 52.62283 -1.12317 26 27 16 17 131 16.26111 52.62267 -1.12317 26 27 16 17 132 16.26417 52.62267 -1.12317 26 27 16 17 133 16.26667 52.62267 -1.12317 26 27 16 17 134 16.26972 52.62267 -1.12317 26 27 16 17 135 16.2725 52.62267 -1.12317 26 27 16 17 136 16.27528 52.62267 -1.12317 26 27 16 17 137 16.27806 52.62267 -1.12317 26 27 16 17 138 16.28111 52.62267 -1.12317 26 27 16 17 139 16.28389 52.62267 -1.12317 26 27 16 17 140 16.28667 52.62267 -1.12333 26 27 16 17 141 16.28972 52.62267 -1.12317 26 27 16 17 142 16.2925 52.62267 -1.12317 26 27 16 17 143 16.29528 52.6225 -1.123 26 27 16 17 144 16.29833 52.62267 -1.123 26 27 16 17 145 16.30139 52.6225 -1.12317 26 27 16 17 146 16.30389 52.6225 -1.12317 26 27 16 17 147 16.30611 52.62267 -1.12317 26 27 16 17 148 16.30611 52.62267 -1.12317 26 27 16 17 149 16.30611 52.62267 -1.12317 26 27 16 17

1-3 Appendix J

3D plot of frequency of recorded locations from 24 hour GPS sampling

Receiver was at location 100,100

X axis recorded in metres showing Northing Y axis recorded in metres showing Easting Z axis is the count of the frequency at that point

09S COS 0S3 002 091 001 09 0

J-1 Appendix K

Julian Swindell's yield map

Harnhill, Field 15 Plot B (winter barley)

Qualitative Crop Yield Map 1994, 5 levels

lOOm

Crop yield levels • low level m low-mid

mid level m mid-high • high level

K- 1 Appendix L

Julian Swindell's raw data locations

Harnhill, Field 15 Plot B, 1994 (winter barley) Location of sample points, as determined by GPS

100m

sample poi

L-1 GO O O sr p i-i ro Crt cy3 'ST" p CD O rt- d 3

ft) 3 <-1 CTQ ^ P CTQ O o C/D •-t d p O 3

CTQ crq

p CTQ CTQ P

c/}

p pcr.

rt) 3 e-. Appendix M

Soil key for CSU Farm Soil Map

Taa Series Te;;ture Parent Mat •r-r 1 a .1

Ab f.=. 1, Aber-Feldy -Fine sandy loam alluvium next, to Hareenya silty clay loam

Ab si.c.l. Aber-feldy silty clay loam alluvium higher than other a 11uvium-based units

Ab si.l. Aber-Feldy silty loam alluvium occurs in poorly-drained depressions

Ab si.1.(A)Aberfeldy silty loam alluvium apparently developed on outwash fan from depression

Ct s1. Cartiwright sandy loam aeolian sand small area

Ga s-1. Gambeth sandy loam granite below Jeral gravelly loam

6a l,s. Gambeth loamy sand granite

below Gambeth sandy loam

G b c 1. Gomba. 1 i n c 1 ay 1 oam p ar na

Gb I.e. Gombalin influencelight clad yb y Ordovician parnmetasedimena t colluvium

Ha si.c.l. Hareenya silty clay loam alluvium along Hou. 1 aghan' s Creek

Je q.l. Jeral gravelly loam granite upper slope immediately below exposed rock

Md c.l. Mundawaddery clay loam metasediments upper slope immediately below exposed rock

Na s.c. Narua fine sandy light clay metasediments less steeo slopes below Mundawaddery clay loam

colluvium

M-2 Appendix M

Soil Map for Wright property, Belgrade, Montana, USA

U.S. DEPARTMENT OF AGRICULTURE SCS-CONS-l S SOIL CONSERVATION SERVICE OCTOBER 1 974 SOIL MAP

Owner- AJ ^IG i- Oi»cralor County Snte M ^^^ "Pa N) A Soil survey sheet(s) or co

M-3 210-22 190-/200

g> >a 0 £L a 180-190 o o a rt- O •GI a (T>

n cr •-«

S C/3 rt- C :x a B. rt><

180-190

o C/3

crq CTQ

P CfQ CTQ P 170-180 2: C/3 (/) g & cr 3. •65 O O o c

(tai Osr

ftC/-) -50 c a B. ^

o C/3 CI (0 CTQ

CfC} QTQ sF (n &a X Appendix P

Demonstration Disk Tutorial Instructions

Unless otherwise stated in the individual steps which follow, all menu selections are made with a single click of the left hand button of the mouse. The "drag and release" style of menu operation is not supported for menu selection in GFA-Basic.

1. Either from MS-DOS, or from a MS-DOS window running under windows, create a "GIS" subdirectory on your hard disk by typing MD C:\GIS at the DOS prompt. Then make that directory your "current" directory by typing CD C:\GIS. Your prompt should now be something like C:\GIS>

2. Place the demonstration disk in your drive (these instructions assume it is drive A:)

Type the command AiPKUNZIP A:DEMO which will decompress the demo program and data into your GIS subdirectory. It takes less than 3 Mb of disk space which is all within the one directory which you have created (GIS) and so it is easy to delete it when you are finished. Now remove the DEMO disk from the drive.

3. Start the program by typing GISMAIN. This is the name of the executable file. You are presented with the opening screen which is a satellite image of the area containing the Charles Sturt University Farm, in Wagga Wagga, NSW, Australia.

4. At this point press the F1 key, or mouse click on the Menu bar in the area where F1=HELP is displayed. Moving the mouse over the entries, or pressing the up and down arrow keys will select an entry while clicking on an entry or pressing ENTER will execute that selection. It is also possible to just press the underlined letter in an entry to simultaneously select and execute that entry in one operation.

5. Activate the About Help to get information on interactive on-line help. Press the space bar to close the Help window. Notice that at the bottom right hand comer of the screen is the message m/pixel: 30 which is indicating that the scale of each screen pixel (point) is currently 30 metres in diameter.

P-1 Appendix P

6. Choose the Menu "Display" and activate "Locations" and then click the left mouse cursor anywhere on the image and see that the x,y screen coordinates of the cursor position are displayed at the top of the right hand window.

7. Now choose the Menu "Display" and activate "AMG" and click on one comer of what looks like a paddock, and see the Easting and Northing locations of the cursor position. Click on the next comer of the same paddock and get the new location at the top of the display, the previous location at the bottom of the display, and the distance between the points displayed in between.

8. Note at the foot of the right hand window the instmction to use the + and - keys to sum the distances. Press the + key (keyboard or keypad) to get a progressive total. Now click on another comer of the paddock and press + to continue to total the perimeter.

9. Use Menu items "Display/Location" and "Display/AMG" a second time to turn them off.

10.Choose Menu "Display/Object" and you are presented with the attribute "Air seed". Use the arrow keys to step through the options displayed to "Paddock" (about 16 down arrows). You may need to tum on the "Num Lock" key and use the keypad arrows on some machines (the keypad arrows are usually on the numbers 8, 4,6 and 2 on the numeric keypad on the right hand end of the keyboard). Press Enter to select paddocks. You are now asked for paddock numbers or ALL. Just press Enter to select ALL paddocks, and then use the arrows to select NO for paddock labels and press Enter. The outlines of the paddocks are now drawn on the initial image.

P-2 Appendix P

11 .Choose Menu "Display/POSzoom". Notice that on the very bottom line of the left hand window is the instruction for Help. To view Help click on CANCEL and then F1=HELP and Now, and see that Help has changed (context sensitive) to the zooming operation. Press any key once the instructions have been read, then Choose Menu "Display/POSzoom" once again. Now "drag" out a box containing the entire farm by placing the cursor arrow at the top right of the farm area and while holding down the left mouse button, move the cursor to the bottom right hand comer of the farm area. Then release the left mouse button. While dragging, and also when released, the shape of the selected area is visible. If you make a mistake, simply reposition the cursor and drag again. When you are happy with the selection, click the RIGHT mouse button.

12.While the image is being redrawn (can take up to a few minutes depending upon the speed of the equipment), notice that the m/pixel value at the bottom right of the screen has changed to a number more like 11, and that the satellite pixels are now larger (and the display is not so exact). Notice also that once the image is drawn then the paddocks are also drawn at the new resolution.

13.Click on Menu "Display/Object" and using the arrow keys choose "Salt affected", ALL and NO labels to see salt contour lines drawn as well. The display starts to get a bit messy as all the lines are currently drawn with the same colour (to be User selectable in the next version).

14.Click on Menu "Display/POSzoom" again and drag a box around the top left hand paddock only. Right mouse button click. While the display refreshes notice that m/pixel is now a value of about 1, 2 or 3 and the satellite pixels (which are 30 metres diameter) are distinct squares. The paddock lines only are now displayed. Notice how the paddock edges in the satellite image does not match up exactly with some of the lines (the effect of different map grids for the boundary digitising - see section 4.2 of the report for discussion).

P-3 Appendix P

15.Click on Menu "Display/AMG" and click where you think the edge of a paddock should be, and then click on the actual line. Northing differences (vertical on the screen) will usually be between 10 and 20 metres, and Easting differences (horizontal on the screen) 20 to 30 metres different. Notice that the AMG routine has adjusted itself to the screen resolution automatically.

16.Turn off the AMG display (Click on Menu "Display/AMG" a second time) and click on Menu "Display Band" (at the top right of the menu bar on the top of the screen) and item "Histogram". Type in the file name BAND3 and press Enter to get a histogram of BandS of the image. Moving the cursor arrow into the body of the histogram activates a counter display. This show the frequency with which a pixel value is found in the image. Press the space bar to erase the histogram. Repeat this step for BANDS and BAND7.

IT.Choose Menu "UTILS" and item "mod Objects". This is the object editor. Type record number 1 and press ENTER and see the details which are stored for paddock 1. Do not change any values, just press ENTER. Now try record 90 for a contour line, and record 150 for a salt "EM" reading of level 70. Record 200 is for "scattered timber" and record 250 is for a soil classification. Notice that each record contains the coordinates for a bounding rectangle, and that the actual data is stored in a different file. In this way the object file points to completely different structures, and different program routines are called to process the different file structures. Just press ENTER to close the object editor.

18.Choose Menu "UTILS" and item "Select palette" which allows you to force various palette changes.

19.Now choose "Display" and item "Exif to leave the program. This next section is a little buggy and may not work on all machines. It was at this point that development of this prototype environment was abandoned.

20.As in step 3. start the program again. Choose Menu "Display" item "Clear" and the picture refreshes. Now choose Menu "Display" item "Object" and choose "Paddock" again, ALL with NO labels.

P-4 Appendix P

21.Now choose Menu "Display" item "POSzoom" and drag out an area which is OUTSIDE of the paddocks (the top left comer is good). Click the right mouse button and you should have a black window.

22.Choose "Display Band" and item "Bandl" and just press ENTER for "Oieq.area 4c red" and select "Top Left" as the display position. Each pixel is now a 2 x 2 matrix with Bandl displayed in 4 shades of red in the top left comer of the matrix, (sorry about the white line down the window boundaries).

23.N0W choose menu "Display Band" item "Band?" and use the arrow keys to select the CLS (colour) file "2: eq.area 4c blue" and display the image "Bottom Right". Now tum up the brightness and contrast on your screen and you will see some areas which are red only, some blue only, and others mixed.

24.N0W choose menu "Display Band" item "Band5" and use the arrow keys to select the CLS (colour) file "1: eq.area 4c green" and choose "Top Right". It should now be possible to identify some areas as only red, blue or green, and others as mixtures. By selecting certain ranges of values from the different bands it will be possible to visually correlate different measurements. While the current prototype only does this for satellite images, there is no reason why salt readings, water content or soil types could not be displayed alongside a satellite image permitting yield estimates to be compared with other data. Further refinement of this approach will be continued in a more robust environment in the next prototype.

P-5