a distributed spatial architecture for bush fire ... - Semantic Scholar

5 downloads 5703 Views 445KB Size Report
The philosophy of this research is to pro- vide general spatial data functionality via a central web-server and devolve specialist distributed spatial modeling requirements to remote machines as ...... Display. Data retrieval. Future: +transmission.
A DISTRIBUTED SPATIAL ARCHITECTURE FOR BUSH FIRE SIMULATION Peter Eklund and Stephen Kirkby and Jonathan Mann National Key Centre for Social Applications of GIS University of Adelaide Adelaide, S.A. 5005, AUSTRALIA

Correspondence to Peter W. Eklund Department of Computer Science The University of Adelaide Adelaide SA 5005, AUSTRALIA

[email protected]

Abstract This paper describes a spatial systems architecture allowing clients to modify parameters and run their own bush re simulations via map data provided by a world wide web server. The simulations conform to the model of bush re behaviors as well as operational requirements. A wavelet model and re simulation over a distributed network are considered in this paper and we demonstrate how the architecture is general enough to accommodate other spatial simulations for emergency management using the world wide web.

1

KEYWORDS: Distributed spatial information systems,

web-based spatial

simulation, bush re modeling.

SHORT TITLE: Distributed Spatial Simulation Architecture

:::

2

1 Introduction The World Wide Web (WWW) is proving a useful vehicle for the delivery of spatial data and is particularly e ective for the timely broadcast of maps, and situations presented as maps. The philosophy of this research is to provide general spatial data functionality via a central web-server and devolve specialist distributed spatial modeling requirements to remote machines as web clients. The world wide web is therefore used as a convenient platform through which broadcast spatial data is pushed. One application of distributed spatial information architectures is emergency management, i.e. during conditions of civil disaster. In these circumstances it is important that reliable and co-ordinated information be broadcast to emergency service units. At the same time, customized decision support should also be made available, e.g., permitting forward simulation from the most recent broadcast data. Our study uses a bush re simulation model as the decision support artifact. The problem of bush re simulation allows us to prototype a distributed spatial web-based architecture for emergency services management delivered via the WWW. In Australian bush res, emergency service response is coordinated via a central command center to a series of distributed eld posts with varying operational responsibility. In South Australia, these eld posts are the Country Fire Service (CFS), The State Emergency Service (SES) and the Police Department. These authorities are co-ordinated by the State Emergency Management Committee. Under re emergency conditions, broadcast spatial information to these units should:

 describe the extent of re-front; 3

 predict the direction and projected spread of the re-front;  forecast the type and density of fuel in the re's path;  evaluate the property and population centers under threat;  permit analysis of road networks servicing the threatened area;  identify spatial resources to combat the re's spread. Under present day operational circumstances data is communicated via telephone/radio or via fax as text or maps. In South Australia, as in many other places in the world, established infrastructure to reliably convey digital spatial information during civil emergency does not presently exist. The WWW suggests itself as an obvious platform for delivering spatial data. Our research therefore aims to serve two purposes: (i) develop a generic webbased architecture for distributed spatial information suitable for emergency management; (ii) provide a practical and operationally relevant prototype for civil bush re emergency. Our e orts have developed a Java application called FireMaster which is the subject of this paper.

2 FIREMASTER: System Architecture FireMaster is a Java application that displays a number of raster map lay-

ers onto which a re-front can be simulated and overlayed. Map layers are broadcast from a web server and simulations run on the local client machine conditioned by input parameters: wind direction and speed, ambient temperature etc. Platform-independence is provided via Java which is an interpreted language. Compilation of a Java class yields a class- le 4

that consists of byte-codes interpreted at run-time by the Java virtual machine. The software engineering principles of Java derive from object oriented design with the emphasis being on the creation of a series of object speci cations termed \classes" [Meyer 1988, Meyer 1991, Meyer 1992, Musser and Stepanov 1994, Plauger et al 1996, Coplien 1992].

2.1 System Constructs FireMaster has three levels illustrated in Figure 1:

1.

Data | the Data Level controls all static and dynamic information required and generated by the system. Initial data is stored to be used in the Operational Level and displayed in the user level. New information generated on the Operational Level is routed through this level. This propagates the fact of its generation to the User Level and other `interested' components. Information from other users and services also arrives via the Data Level, e.g. on-line weather parameters;

2.

Operational | contains large-scale operations over the data initiated and controlled via the User Level; others;

3.

User | Contains the graphical user interface. The Data component

is created immediately in this level. Operations are created and invoked when required by the user. New information can be entered to propagate to the lower levels.

2.2 The Data Level The Data Level maintains all static and dynamic data used. This consists of data layers, incidents, routing source points, routings from points and so 5

on. An incident is a re event or outbreak. Data layers are in raster format at a resolution of 30m2 per cell. The layers are:

 re history;  vegetation communities;  slope;  aspect;  fuel loads;  road network. In FireMaster, data is loaded as ArcInfo TM export format derived from the initial sources | mostly South Australian Government agencies. A Java interface to FireMaster will enable real-time access to ArcInfo TM data via ERSI's SDE TM and Maptek's Vulcan TM (currently under development [Gibbs 1997]). Each map layer is implemented as an object called DataLayer, providing methods by which the layer can be manipulated in an abstract fashion. A method is also implemented to produce an image from the data using a given color map. Fire perimeters denote the spatial extent of a re and are grouped into incidents. An incident is classed as a sequence of re perimeters, F0 ; : : : ; Ft , for which any perimeter Fi for i 2 1; : : : ; t is generated from Fi?1 . The simulation time is stored with each perimeter, as time intervals between perimeters vary depending on the consistency of the step and iteration size generating new perimeters. This provides a simple way to roll back the simulation. Incidents are grouped into an IncidentTree. Each incident may 6

be started from an initial re perimeter or a single point on the map and a pair of incidents may merge into a new perimeter encompassing both. In the tree a list is kept of the currently active incidents. Each node of the tree keeps pointers to:

 the incidents it was formed from (may be empty);  the incident it has merged into (if this incident is now inactive). Each incident in the tree is accessed by a key, and the keys of all active incidents are available to DataDisplay (see Figure 1). This allows incident trackers to swap between incidents. The use of this structure means the progress of the re can be recreated at a later stage. The incident tree can be modi ed, by adding perimeters to existing incidents or creating new incidents. Also, by merging incidents into a new incident when overlap occurs. These modi cations to the structure are stored as a list of updates within the tree. Changes in the Data Level result in all DataObservers being noti ed. Each DataObserver receives notice of new data items, modi cation of existing items and the removal of data items no longer useful. In the public domain version1 , the single observer is the local display component at the user level. To share results with other users a local thread acting as an observer sends and receives updates from other users via the central webserver.

be found at http://www.cs.adelaide.edu.au/~kvo/software. FireMaster will run from a Java enabled web browser, Netscape Navigator 2.02 or better. 1

The

public

domain

FireMaster

7

can

2.3 The Operational Level The Operational Level can consist of a large number of components (in the public domain version of FireMaster, two operational modules are included). The relevant components for the public domain FireMaster are the WaveletModel, an implementation of a wavelet re-model, and SPath, a shortest-path route nding algorithm [Eklund et al 1996]. WaveletModel keeps track of the latest re from every incident. An incident is a sequence of re perimeters generated by the model and passed to the Data Level. At the data level, each incident can be referenced by a key. This key is returned when a incident is rst created, and used by the model to inform the data level to which incident a generated re perimeter belongs. The main operation of WaveletModel is advance, called from the user level to signify that all incidents should be advanced by a certain time period t. The accuracy of this operation is a ected by changing two settings: the time period t, and the step size s, which is the largest time step used in advancing the re perimeter. n = floor( st ) is the number of steps that will occur, each of equal step size nt . Details of the SPath shortest-path component of FireMaster are omitted here for brevity. A full description can be found in [Eklund et al 1996, Kirkby et al 1996].

2.4 The User level The User level consists of two objects making up the front end of FireMaster:

FireApp/FireApplet. The rst of these is a Java application, i.e., it be-

haves as a single-user, platform-dependent program with direct le 8

I/O. The second is a Java applet viewed through a browser such as Netscape TM Navigator/Communicator or through Sun's appletviewer. An applet has no direct le access due to security restrictions. The di erence between the two a ects the choice of data object at the Data Level. Most behavior at this level is shared, however; both create other components in the system, choose the dataset on which to operate, route new information to the operational level and allow the user access to alter weather conditions at the data level. Both use a subsidiary graphical component, (DataDisplay).

DataDisplay. The methods required to transform any piece of data to a

visual format are encapsulated within this object; DataDisplay, with some knowledge of the format of di erent data items, combines all data items to be displayed. DataDisplay contains three main graphical components as shown in Figure 2.

MapPanel: The central map: can display combinations of data layers

at various zoom levels, and vector information may be added and removed (see Figure 2). Data layers, in their current representation as a two-dimensional array of bytes, can be mapped (given a ColorMap as argument) to an intermediate format called PixelMap. PixelMaps are maintained for each viewable layer by DataDisplay passed to its subcomponents; they may be combined in a bitwise-AND fashion to achieve map overlay operations. 9

Fire perimeters are transformed to a polygon matching the current zoom level. These polygons are drawn directly onto the image of the data layers. This is done primarily to obtain smooth scrolling of the map.

LegendPanel: The map legend, which displays information on the

layers shown and passes changes made by the user to the other display components (see Figure 5). LegendPanel consists of a KeyPanel for each layer displayed, using as input an object of type KeyData. A KeyData object consists of a list of colors matched by a list of descriptions. This object is obtained from each DataLayer using the information of its attached DataTranslation object. The color palate may also be manipulated from here.

Incident Trackers: Components designed speci cally for the Fire-

Model operation. These dynamically change scale and location to display a re incident and surrounding information (see Figure 6). A complaint of re simulations allowing multiple res is the dif culty following the progress of each re. FireMaster provides a separate incident tracker for each re for this purpose. Each incident maintains, along with a sequence of generated re perimeter, the maximum and minimum easting and northing values used by the perimeters. These values are updated when a perimeter is added to the incident. The values are useful in determining when separate incidents overlap, and determine the 10

appropriate area for display. A zoom factor is also displayed, which is the ratio of pixels cell?1 for the data layers. implements the interface DataObserver, and is registered with the Data Level as such. This means that changes or additions to the dataset, due to actions at the operational level or communication from other users via the server, will result in a noti cation to DataDisplay of the data and how it can be accessed. DataDisplay can then choose whether to add data to its display or ignore it.

DataDisplay

2.5 Architecture Summary The FireMaster architecture is designed to permit new operational modules. It does this by de ning three distinct levels, User, Operational and Data, which loosely interact. New operations are introduced at the Operational Level. In the public domain version of FireMaster the Operational Level includes both SPath and WaveletModel classes. Map data is retrieved from a central server to be cached within the Data Level. Operations are de ned which, when invoked from the graphical interface, will operate on the data and produce results. These results are passed through the Data Level to be stored, before being passed to objects designated as DataObservers. The graphical interface has a large subcomponent that can be treated as a DataObserver. Results generated by any operation will thus be propagated back to the User Level via the display. The Data Level must receive all data, partly to store and check the results of operations, but also to act as a node from which results can be sent or received. The use of DataObservers that receive noti cation of changed 11

data allows the use of any component ful lling the interface DataObserver. This may be DataDisplay, another operation, or a set of functions which pass the results to other clients. Finally, the User Level o ers an interaction with the system. Operations are invoked from here, and the data of the Data Level displayed in a meaningful manner. The interface is able to display all changes reported by the Data Level, and can access the Data Level separately to obtain relevant results. The interface also allows the user to change simulation conditions between invocations of any operation. The paper now illustrates the architecture by describing the re simulation model. Since the simulation is itself interesting, we allocate considerable space to its discussion. Apart from SPath and WaveletModel classes, we have implemented a number of other modules at the Operational Level. These include: (i) a civil evacuation model; (ii) spatial resource allocation (for combating the re's spread); (iii) a second two-dimensional bush re model [Richards and Bryce 1995, Richards 1995]; (iv) a three dimensional cellular re simulator [Goncalves and Diogo 1994] and, in another emergency management domain (v) a ood and watershed simulation module.

3 Bush Fire Simulation 3.1 Background to Bush Fire Modeling To model bush res, McArthur [McArthur 1966], [McArthur 1967], [Noble et al 1980] developed the re danger index (FDI), quantifying the chances of a re starting, its rate of spread, intensity and suppression diculty. The FDI can be calculated to on a scale of 1 to 100 (Table 1). The 12

FDI varies according to vegetative conditions i.e.; Forest Mk 5 FDI = 2  e(0:987log(D)?0:45?0:0345H +0:0338T +0:0234V ) : p p Grassland Mk 4 FDI = 2  e(5:01log(C )?23:6+0:0281T ?0:226 H +0:633 V ) :

where D is the Drought Factor on a scale of 1 to 10, H is the relative humidity, T is the temperature in  C, V is the wind speed in km hr?1 , C is grass curing, and W is the fuel load in tonnes/ha. Determining the fuel load is an operation in itself, involving the vegetation type and time since the last re. This is done by producing a new data layer from re history and vegetation community data layers, using a negative exponential function to approximate fuel growth (fuel initially accumulates rapidly with time, with the rate decreasing and fuel eventually approaching a maximum level). By combining the FDI with the fuel load the basic re characteristics may be determined according to the model. These are:

 Rate of spread (ROS), for level to undulating terrain, ROSforest = (0:0012  FDIforest  W )km hr?1 : ROSgrassland = 0:13  FDIgrassland km hr?1 : ROS is an average only, as res are rarely steady or predictable.

 Rate of spread on sloped terrain, ROS = (R e0:069 )km hr?1 : 13

 Flame height (Z ) (for forested areas), Z = (13  R + 0:24  W ? 2)m :

 Distance of spotting from the ame front (S ), S = (R  (4:17 ? 0:033  W ) ? 0:36)km : By gathering enough data to obtain values for each point at any time t, we have the basis of a re model. Weather factors are, in practice, usually assessed locally by re crews. Under unstable re conditions the wind speed may change frequently, and so should not be assumed constant over the entire terrain. This factor is important because it in uences the FireMaster architecture. Field units should be able to simulate the bush re according to their knowledge of local conditions. Naturally, this needs to occur in a controlled way according to the operational responsibilities assigned the unit.

3.2 The Fire Shape Tests have shown that re, under spatially invariant conditions, expands approximately as an ellipse, even with irregular starting shapes and undulating terrain [Anderson et al 1982]. The shape of the ellipse has been shown to bear a strong relationship to wind speed (v), in the ratio:

LengthtoBreadth = 1 + 0:0012  v2:154 for v < 50 km hr?1 [Alexander 1995]. 14

If the re starts at a point, we nd the point forms one of the loci of the re ellipse. Thus the forward rate-of-spread (ROS) is proportional to the length a + c of the ellipse; ank ROS is b; and rear ROS is a ? c. Given LtoB = a=b of the major axis to the minor axis of the ellipse, and the forward ROS R, we nd a and b as follows:

R (L ? to ? B )2 ? 1 + LtoB a = b  L ? to ? B

b= p

3.3 Wavelet Propagation The wavelet propagation model delineates the re perimeter, the outer boundary of a burned area, at time t. The perimeter can be regarded as a discrete number of points approximating a continuous curve. The model assumes each point on the re perimeter expands as a small ellipse, with the focus of the ellipse coinciding with the point on the perimeter. The new re-front at time t +t is de ned as the outer envelope formed by the small ellipses (see Figure 7). For each point on the perimeter, local conditions a ecting re behavior: fuel, terrain and wind, can be collected. These local parameters are used to compute ellipse parameters for each small ellipse. Each point is evaluated independently of its neighboring points. To map the re perimeter from ellipses, Richards [Richards 1990] suggests applying a linear transformation to compress ellipses to circles; allowing the new perimeter to be obtained from tangents from these circles. This method is limited by the assumption that wind velocity is spatially independent. Roberts [Roberts 1989] uses an algorithm based on line elements 15

(segments). The new re-front is approximated with a number of segments, each evolves outwards in the direction of its normal. In each time step a line element moves a distance L determined by the ellipse parameters a, b, and c: the direction of the wind and the direction of the outward normal. The method we adopt was proposed by Knight and Coleman [Knight and Coleman 1993]. This resembles Richards in its use of tangents, but is designed to emulate the process used by the human eye in determining the re perimeter. This algorithm has the bene t of being deterministic and ecient. This is an obvious advantage in the simulation but since re spread is nondeterministic, a somewhat arti cial constraint. Other twodimensional re modules are being implemented [Richards and Bryce 1995, Richards 1995] but the main emphasize of this research is toward an environment that supports a three dimensional spatial re simulation model [Bak et al 1990], [Grassberger and Kantz 1991, McGrattan et al 1994], [Goncalves and Diogo 1994, Baum et al 1996]. Given the computational demands of three dimensional spatial simulation, the web-based architecture is ideal to farm out computational modeling tasks to other server machines (including supercomputers).

3.4 Implementing the Wavelet Model The problem determining a new re perimeter using the wavelet propagation model is the selection of the correct points from propagating ellipses. Beer [Beer 1991] describes an early attempt in which four points from each ellipse are selected as candidate points for the new perimeter. A process is then applied to select a subset of these points as an approximation to the envelope. This fails in areas of concavity in the re-front, both at a small scale, where 16

a small loop or rotation is formed, and at a larger scale where two separate sections of the re front meet and overlap. The algorithm used by Knight and Coleman [Knight and Coleman 1993] solves this problem by dividing the process into two steps: generation of an uncorrected perimeter, and correction of this perimeter. In our implementation, perimeter generation is the main step of the re model operation, perimeter correction is included as a method of the FirePerimeter object. This separation of steps is considered reasonable, since di erent perimeter expansion models utilize the same correction algorithm. Also, perimeter correction requires unrestricted access to the data representation, best done by implementing the correction as a method of the FirePerimeter object.

3.5 Perimeter Generation It is a simple task for the human eye to de ne a new perimeter enveloping the propagating ellipses. The enveloping perimeter will be tangential to the propagating ellipses where it meets each of them, and also to the `outside' of the previous perimeter. The wavelet propagation algorithm emulates this by nding points on the propagating ellipse with gradient matching that of the old perimeter at that point. The gradient at any point on this ellipse is,

dy = dy  dS : G = dx dS dx So for a gradient G, the required value of the parameter S is, () ? cos()) ) ; S = tan?1 ( ab((Gsin Gcos() + sin()) which has two solutions for 0  S  2. 17

These solutions correspond to two points on opposite sides of the ellipse, one on the `outside' of the previous perimeter, one on the `inside'. This is where the representation of the re perimeter comes into e ect to choose between them. The perimeter is maintained as a linked list of points; more precisely, a loop, in which the last point has a pointer to the rst. Points are maintained in a clockwise order. Vectors between points are de ned implicitly, by using points at its head and tail. We can use the fact that points are ordered clockwise to compute which point on an ellipse is outside the old perimeter. For any vector ~v we determine the outward normal n by rotating ~v by =2 anti-clockwise. We can de ne vectors p~1 and p~2 joining the focus of the ellipse to the two tangential points p1 and p2 respectively. If we then take n  p~1, the dot product of one of these vectors and the normal, we get the cosine of the angle between the vectors. If n  p~1 > 0, then the deviation between n and p~1 is less than =2, and so p1 is the point to the outside of the old perimeter. Otherwise, p2 is the outer point. This process can be repeated around the entire perimeter to obtain a new set of points, in a clockwise order, de ning the new perimeter. One more de nition is needed, namely curvature; for a point p (the ith point on the perimeter at time t), this is a classi cation of the de ection between the vectors p ?1; p and p ; p +1 (the pre- and post-vectors). t;i

t;i

t;i

t;i

t;i

3.6 Perimeter Correction The perimeter as generated has two major sources of error; these are:

Rotations: occurring at concave points in the old perimeter, a small loop or rotation can form in the perimeter. The intuitive correction is to 18

replace the points in the rotation with the intersecting point.

Overlaps: occurring when the front overlaps itself after surrounding an

area of low re spread. This produces a large internal loop, which should be removed in favor of the outer loop.

Knight and Coleman [Knight and Coleman 1993] describe methods to detect and correct each of these errors.

3.6.1 Rotations Rotations are detected by checking along the entire perimeter to nd the de ection at each point between its pre- and post-vectors. We keep a running total of the de ections at the last two points p and p +1 (see Figure 11). If this total falls outside [?; ] we check the surrounding line elements for an intersection. An intersection might still escape detection if it is not close to the candidate point, or if the total de ection stays within the normal range. In this case, the rotation is likely to grow until it is detected and removed by overlap correction (below). t;j

t;j

3.6.2 Overlaps Overlaps could conceivably be detected by checking for intersections between every possible combination of line segments, or by narrowing the search space. We can produce a better solution. The rst step is to divide the re perimeter into a number of vertical zones of equal width. Knight and Coleman suggest using the square root of the total number of points as the number of zones; this is the approach im19

plemented. The re perimeter can be broken up into a number of segments, de ned as points in a length of perimeter falling within the one zone. The rst and last points in segments each fall in one or another adjacent zones. The important attributes of a segment are the points contained within it, the zone it falls in, and the minimum and maximum y-coordinates held by its points. Neighboring segments will fall into di erent zones. We then proceed to check pairwise any segments that fall in the same zone. If they overlap, i.e., the y-extents de ned by the minimum and maximum y-coordinates of each overlap, then we check each line element of one segment against each line element of the other for intersections. If we nd an intersection x between line segments p ; p +1 and p ; p +1, we can identify two perimeters, one with p connected to x which is connected to p +1, and another with p connected to x0 and then to p +1. To nd which of these two perimeters to keep, we nd the one enclosing the larger area. The wavelet model is an ecient re perimeter expansion algorithm closely resembling the physical manifestation of bush re events. Coding, and subsequent representation of the algorithm, require perimeter correction, rotation and overlap detection. t;j

t;j

t;i

t;i

t;j

t;i

t;i

t;j

4 Conclusion One aim of our research is to develop a practical and convincing bush re simulation tool relevant to the operational requirements of civil bush re emergency. For this reason, this paper has spent considerable space describing FireMaster's public domain bush re simulation module. We believe it 20

is important to declare the model, so there can be no confusion as to its accuracy and source. Furthermore, our experience with the McArthur model suggests it is inappropriate for the South Australian environment. For this reason, we are concentrating our e orts studying other bush re models, both two and three dimensional simulations. A comparative evaluation of several bush re simulations against ground-truth data from real bush res will provide quantitative evidence on the appropriateness of these models to the Adelaide Hills. This is an important aspect of our research. Our second aim is develop a generic web-based architecture for distributed spatial simulation. Although there is some question mark about the re simulation model, the software architecture of FireMaster has been well-received and is easily reused. An approach to emergency management that allows the timely broadcast of map and other operational data via a client/server architecture provides timely data services to remote clients with little or no additional equipment or network overhead. The addition of new operational modules, facilitated by the architecture, gives us a framework for reusing the FireMaster for other distributed spatial systems and services.

References [Alexander 1995] M.E. Alexander. Estimating the Length to Breadth Ratio of Elliptical Forest Fire Systems. Environment International, 17:101{10, 1991. [Anderson et al 1982] D.H. Anderson, E.A. Catchpole, N.J. de Mestre, 21

T.Parks. Modelling the Spread of Grass Fires. Journal Australian Math. Soc. (Series B), 23:451{66, 1982. [Bak et al 1990] P. Bak, K. Chen and C. Tang A Forest- re Model and Some Thoughts on Turbulence Phys. Lett. A147, pp. 297{300, 1990. [Baum et al 1996] H.R. Baum, McGrattan, K.B. and Rehm, R.G. Three Dimensional Simulations of Fire Plume Dynamics Journal of the Heat Transfer Society of Japan 35:45{52, 1996. [Beer 1991] T. Beer. Bush re-control decision support systems. Environment International, 17:101{10, 1991. [Coplien 1992] J.O. Coplien. Advanced C++ Programming Styles and Idioms. Addison-Wesley, Reading, MA, 1992. [Eklund et al 1996] P.W. Eklund, S. Kirkby and S. Pollitt. \A Dynamic Multi-source Dijkstra's Algorithm for Vehicle Routing" Australian and New Zealand Conference on Intelligent Information Systems (ANZIIS '96), pp. 329{333, IEEE press, 1996. [Grassberger and Kantz 1991] P. Grassberger and H. Kantz. On a Forest Fire Model with Supposed Self-Organized Criticality J. Stat. Phys. 63, pp 685{700, 1991. [Kirkby et al 1996] S. Kirkby, S. Pollitt and P.W. Eklund. Implementing shortest-path algorithms in a 3 Dimensional GIS 7th International Symposium on Spatial Information Systems, Delpht, The Netherlands, p7B, 31. International Geographical Union Commission on GIS, 1996. also in 22

Advances in GIS Research II, (eds) M.J. Kraak and M. Moleraar, Taylor and Francis, London, 1997.

[Knight and Coleman 1993] I. Knight and J. Coleman. A Fire Perimeter Expansion Algorithm Based on Huygens' Wavelet Propagation. Int. J. Wildland Fire, 3(2):73{84, 1993. [Gibbs 1997] A. Gibbs. Platform Independent Access to a Remote Spatial Database Management System Honours Thesis, Department of Computer Science, The University of Adelaide, 1997. URL: http://www.cs.adelaide.edu.au/~kvo/reports

[Goncalves and Diogo 1994] P.P. Goncalves and P.M. Diogo. \Geographic Information Systems and Cellular Automata: A new approach to forest re simulation" EGIS `94. Utrecht: EGIS Foundation, 1:603-617, 1994. [McArthur 1966] A.G. McArthur. Weather and Grassland Fire Behavior. Forestry and Timber Bureau, Canberra, Lea et 103, 1966. [McArthur 1967] A.G. McArthur. Fire Behavior in Eucalypt Forests. Forestry and Timber Bureau, Canberra, Lea et 107, 1967. [Meyer 1988] B. Meyer. Object-Oriented Software Construction. Prentice Hall, Hertfordshire, UK p. 534, 1988. [Meyer 1991] B Meyer. Design by Contract Advances in Object-Oriented Software Engineering, (eds) D. Mandrioli and B. Meyer, pp. 1{50, Englewood Cli s, N.J. Prentice Hall, 1991. [Meyer 1992] B Meyer. Applying \Design by Contract", Computer, pp. 40{51, October 1992. 23

[McGrattan et al 1994] K.B. McGrattan, K.B., Rehm, R.G. and Baum, H.R., Fire-Driven Flows in Enclosures Journal of Computational Physics 110(2):285{292, 1994. [Musser and Stepanov 1994] D.R. Musser and A. Stepanov. Algorithmoriented Generic Libraries, Software { Practice and Experience 24(7):623{642, July 1994. [Noble et al 1980] I.T. Noble, G. A. V. Barry, and A. M. Gill. Mcarthur's Fire-danger Meters Expressed as Equations. Australian J. Ecology, 5:201{203, 1980. [Plauger et al 1996] P.J. Plauger, A. Stepanov, M .Lee and D .Musser. The Standard Template Library. Prentice-Hall, 1996. [Richards 1990] Gwynfor D. Richards. An Elliptical Growth Model of Forest Fire Fronts. Int. J. for Numerical Methods in Engineering, 30:1163{79, 1990. [Richards and Bryce 1995] G.D. Richards and R. Bryce. A Computer Algorithm for Simulating the Spread of Wildland Fire Perimetres for Heterogeneous Fuel and Meteorological Conditions Int. J. Wildland Fire, 5(2):73-79, 1995. [Richards 1995] G.D. Richards A General Mathematical Framework for Modeling Two-Dimensional Wildland Fire Spread Int. J. Wildland Fire, 5(2):63-72, 1995.

24

[Roberts 1989] S. Roberts. A Line Element Algorithm for Curve Flow Problems in the Plane. Centre for Mathematical Analysis, Australian National University. CMAR5889, 1989.

25

TABLES AND FIGURES Table 1 | FDI classi cation. Figure 1 | FireMaster: Component Architecture and ow control. Figure 2 | The interface provided by FireApp. Figure 3 | DataDisplay, subcomponent of FireApp/FireApplet. Figure 4 | MapPanel at zoom of x2; res are highlighted by polygons. Figure 5 | LegendPanel, currently showing details of several layers. Figure 6 | Incident Trackers, each tracker window displays one re incident. Figure 7 | Propagating ellipses de ne the new perimeter. Figure 8 | Selection of the outer tangent point. Figure 9 | A rotation formed at a concave point. Figure 10 | A large internal loop, formed when the re-front surrounds an area of low re spread. Figure 11 | Detection and removal of rotations. Figure 12 | A perimeter divided into four zones and ten segments, A through J .

26

Degree

Low Moderate High Very High Extreme

Range 0-5 5 - 12 12 - 24 24 - 50 50+

Table 1: FDI classi cation.

27

Front End

User

Data Display

Choice of dataset

Operational

Operation interfaces

Wavelet Model

SPath

Operation results

Data

Notification of data changes

Local/Applet Data

Data retrieval Future: +transmission

Server

Figure 1: FireMaster: Component Architecture and ow control.

28

29 Figure 2: The interface provided by FireApp.

Figure 3:

DataDisplay,

subcomponent of FireApp/FireApplet.

30

Figure 4:

MapPanel

at zoom of x2; res are highlighted by polygons.

31

Figure 5:

LegendPanel,

currently showing details of several layers.

32

Figure 6: Incident Trackers, each tracker window displays one re incident.

33

wind direction

Ft

F

Figure 7: Propagating ellipses de ne the new perimeter.

34

n v p1

p

2

Figure 8: Selection of the outer tangent point.

35

F wind direction

F

Figure 9: A rotation formed at a concave point.

36

F

wind direction

F

Figure 10: A large internal loop, formed when the re-front surrounds an area of low re spread.

37

p

t,i+1

p

t,i-1

p

t,i

p

t,i+2

Figure 11: Detection and removal of rotations.

38

0

1

2

3

A a

B

j’ b

C

a’ c b’ e

d’

c’

i’ j

d

g

f

f’

p

e’

h’

i g’

h

Figure 12: A perimeter divided into four zones and ten segments, A through J . Segment A includes all points from a to a'; Segment B = (b1; b01) includes all points from point b to b' etc. Segments C and G share the same zone number and their y-extents overlap, so intersections between line elements C and G are tested. The intersection point p is found, and the internal loops are masked out of the perimeter.

39