...

Overview

Input

When running a simulation Phoenix obtains input data from 3 sources.

1. Data entered into the application directly, and saved in the project file,
2. Files in the Gridded_Weather directory, and
3. Files in the Data directory.

This document describes the data files that are obtained from the Gridded_Weather and Data directories.

The Gridded Weather directory is expected to contain NetCDF files obtained from the BOM.

The Data directory contains a variety of possible input layers that must be created by hand.

Gridded Weather

TBD - populate this section with a description of how to use the weather downloader

Refer to the manual for how to use weather entered directly into the UI/project file

Data layers

General Requirements

...

Possible input layers

Phoenix will detect, and use, the following input layers if they are found in the Data directory:

1. Fuel Layer
2. Digital Elevation Model
3. Disruption Layer
4. Fire History Layer
5. Wind Modifiers Layer
6. Assets Layer

TBD - pull more out of both PHOENIX_data_preparation_20080413.pdf and Phoenix User Manual

Input data to the model must be prepared in a GIS such as ESRI's ArcGIS or MapInfo. This base data
is then converted into a format read by PHOENIX which is an ASCII grid broken into data "tiles", 30 x
30 cells wide. This tiling can be easily done in ArcGIS using a specially developed "Toolbox". The
base input data is usually at 20 or 30 m resolution, but when it is read into PHOENIX it is averaged
into larger cells to speed computations. Typically the grid cell size for PHOENIX computation is 100
or 200m, but could range from 50 to 500m depending on the nature of the terrain and the level of
detail required.

Files needed to run

Data directory

Image Removed

An example of the type of files in
the "Data" sub-folder. Notice they
are "zip" files. This makes copying
from one drive to another faster
and easier. The "data.prj" file
defines the geographic projection of
all the data files (input and output)

The only data layer that must exist to run PHOENIX is the "Fuel" data layer, however all the other layers make the
simulation more realistic. If there is no data file location specified, then the input value will be zero.

Gridded Weather directory

The "Gridded_Weather" folder holds the gridded forecast weather produced twice a day
by the Bureau of Meteorology. A downloading process has to be put in place to get this data, but it
is restricted to registered users. PHOENIX will also run on a single stream of weather data .

Info about the weather downloader required.

...

Datum and Coordinate System
All data needs to be prepared in a consistent projection that has a scale in metres.
You cannot use a geographic coordinate system using measurement in degrees. For
consistency across Australia, we recommend using the
GDA_1994_Geoscience_Australia_Lambert projection.
Figure 1. Details of coordinate system recommended to be used in PHOENIX.
GIS Software Requirements
GIS software is an ongoing problem. We have decided to write PHOENIX to use
ESRI ArcGIS 9.2, sp4. You need a licence to operate ArcGIS 9.2 ArcView (or
similar Arc product such as ArcEditor, ArcInfo). It is our intention to keep the
PHOENIX software compatible with the most recent version of ESRI ArcGIS.
Source Data
PHOENIX uses five GIS datasets:
1. Fuel Types – developed from a vegetation layer.
2. Fire History – from which to calculate the current level of fuels across the
landscape.
3. DEM – from which to calculate slope, aspect, and elevation.
4. Road Proximity – from which to determine the level of assistance given to
suppression.
5. Fuel Disruptions – from which to determine the effect of linear features, such
as roads, rivers, railway lines and fire breaks, on fire behaviour and spread.
The fuel type layer is the only essential data required to run PHOENIX. The other
layers improve the simulation reality, but the PHOENIX will work without them.
PHOENIX_data_preparation_20080413.doc Page 1
PHOENIX – Data Preparation Tolhurst (April 2008)
Detail on how to prepare these layers will be given later in this document.
Geographic Reference Data
In addition to the source data for running the PHOENIX model, it is also necessary to
have a visual reference layer such as a satellite image or topographic map on which to
setup the simulation area and to overlay the results of the simulation.
This geographic reference layer(s) is encapsulated in an ArcGIS project. Apart from
the basic visual reference layer, other GIS information may also be included in this
project for display in PHOENIX. However, within PHOENIX, these layers can only
be turned on or off for display, no other manipulation of these layers is possible in the
PHOENIX environment.
Figure 2. Examples of geographic reference layers. The top image shows a satellite
image overlayed with major rivers, roads and town names. The bottom
image shows a section of a 1:250,000 topographic map.
PHOENIX_data_preparation_20080413.doc Page 2
PHOENIX – Data Preparation Tolhurst (April 2008)
Source Data Preparation
1. Fuel (Vegetation)
The Fuel layer is used in conjunction with the fire history layer to create the fuel
attributes used in PHOENIX. It has been assumed that the vegetation layer is the
layer most likely to be kept up-to-date and more readily available than a purpose built
fuel type layer. However, it is also acknowledged that there are several vegetation
type classifications and a range of mapping detail and quality within some states and
between states. Therefore, the approach taken in PHOENIX has been to convert
various vegetation classifications into a standard set of fuel types, e.g. there are about
700 vegetation types mapped in Victoria and these are classified into about 40
different fuel types (see a list of fuel types in Appendix 1.).
The user needs to assign a fuel type to every vegetation type in the area of interest.
To enable this, a code for each vegetation type is needed, e.g. 97 – Semi-arid
Woodland. This code is used in a lookup table and joined to a fuel-type code. This
fuel type code must then be added to the attribute table for the vegetation map in a
GIS. The setting up of the conversion process is beyond the scope of these notes, but
it can be done by “Joining” the lookup table to the vegetation attribute table in the
GIS.

The fuel mapping must cover the whole area. Areas with no fuel type mapped will be
assumed to carry no fuel and therefore will not carry fire (e.g. a water body).
The fuel type layer (and all other input data layers for PHOENIX) needs to be
converted to an ASCII grid (.asc) format. The cell size units must be in metres (m),
and the cell size must be in whole numbers. A cell size of 30 m is recommended for
vegetation. The ASCII file must be called: “fuel.asc”.
Once the “fuel.asc” file has been prepared, it is processed in PHOENIX to compress
the data, divided into tiles, and stored in a folder called: “fuel”. This process will be
explained in more detail.
PHOENIX_data_preparation_20080413.doc Page 3
PHOENIX – Data Preparation Tolhurst (April 2008)
Vegetation data preparation process (Manual Method)
It is necessary for the user to prepare a comprehensive vegetation data layer for the
area to be used. Each vegetation type must be identified with a unique code. Figure 4
shows an example of an attribute table associated with a vegetation layer (shapefile).
“VEG_ID” is the unique code that will be used to assign each vegetation type to a fuel
type. Once the vegetation layer has been attributed with the fuel type codes, it can be
used to create the ASCII grid layer. The name given to this fuel type field is not
critical. Producing an ASCII grid is a two step process with the intermediate process
being the production of a raster layer with the ESRI grid format.
Step 1. Create a unique integer code for each fuel type. (ArcMap)

Two tools are available to convert the shapefile to an ESRI GRID (raster), “Feature to
Grid” (Fig. 5) and “Polygon to Grid”. Specify the output file as “vegetation (no
extension)” and the output cell size as 30m.
PHOENIX_data_preparation_20080413.doc Page 4
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 2. Convert the shapefile to an ESRI GRID file. (ARCMap)

Once the ESRI GRID (raster) file has been created, it must be converted to an ASCII
grid format. To do this, use the Conversion Tool – From Raster to ASCII tool. The
output ASCII file must be called “fuel.asc”.
PHOENIX_data_preparation_20080413.doc Page 5
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 3. Convert the ESRI GRID file to an ASCII grid file. (ARCMap)
Figure 6. The ESRI GRID to ASCII conversion tool to create the “fuel.asc” file.
This ASCII grid file must now be compressed and broken into tiles using a facility in
PHOENIX. The fuel, or any other layer, can be converted on its own, or all together,
the choice will be yours.
Start by opening PHOENIX. Then select the “Phoenix GIS Data Converter” from the
“Data” dropdown menu (Fig.7).
Figure 7. Phoenix GIS Data Converter facility.
Navigate your way to the folder containing the vegetation ASCII grid file and select
it. “Start” the compression and tiling process (Fig.8). The data files will be output to
a folder within the one you selected with the ASCII grid file. This folder will be
called “fuel” and if it does not already exist, it will be created.
Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files.
(PHOENIX)
PHOENIX_data_preparation_20080413.doc Page 6
PHOENIX – Data Preparation Tolhurst (April 2008)
Figure 8. The “Date Converter” tool in PHOENIX converts the ASCII grid data into the
format needed to run PHOENIX simulations. Note: in this case only the
fuel data is being processed, but other layers could be processed at the
same time if desired.
This fuel data will be used in conjunction with the fire history layer to convert them
into a current fuel levels when a fire grid is created in PHOENIX. The process of
doing this will be explained later.
The fuel layer is now ready for use.
Fuel data preparation process (ArcGIS Toolbox Method)
The data preparation process can be simplified by using a set of customised tools
developed to be used in ArcGIS 9.2 to produce the data files required as input to
PHOENIX.
In order to use these tools, first they must be installed on your GIS program.
Installation
Pre-Check
The toolbox and scripts are stored in a folder in the PHOENIX root directory called
Scripts. This will typically be C:\Phoenix\Scripts
It is important to check that these files are in the Scripts folder:
• DEM.py
• Disruption.py
• Fire_History.py
• Phoenix Data Optimiser.exe
• Phoenix.Grid.dll
• PhoenixTools.tbx
• Road_Proximity.py
• Fuel.py
PHOENIX_data_preparation_20080413.doc Page 7
PHOENIX – Data Preparation Tolhurst (April 2008)
The five files denoted with the .py extension are the Python scripts. These are written
in Python 2.4 and should work with a standard ArcGIS 9.2 installation.
The .exe and .dll are the files required to perform data conversion from a shapefile or
grid format to PHOENIX format. This will be run in the tool, but it is a standalone
program that can be run separately on other ASCII files.
The .tbx file is the ArcGIS Toolbox that the user adds to the built-in toolboxes.
Adding the Toolbox to ArcGIS
In this section the user will add the toolbox to the ArcGIS tool list.
Step 1
Open ArcGIS to either the default environment or a previous project.
Step 2
Open the toolbox panel by clicking icon 1
1
ation_20080413.doc Page 8
This will open the ArcToolbox panel shown above here.
PHOENIX_data_prepar
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 3
Right-click inside the panel so that the context menu opens up and select “Add
Toolbox…” as shown below.
Step 4
Navigate to the Phoenix\Scripts directory and select PhoenixTools. Do not double
click as this opens the toolbox as a folder, but doesn’t add it. Once selected, click
Open.
PHOENIX_data_preparation_20080413.doc Page 9
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 5
Once added, click the + next to Phoenix Tools and then the Data Preparation tab and
this should expand to reveal the five scripts.
PHOENIX_data_preparation_20080413.doc Page 10
PHOENIX – Data Preparation Tolhurst (April 2008)
Applying the “Fuel” tool
1
2
3
4
The Vegetation tool takes in a Feature Class which has an ID field for every feature.
Inputs
1. Input Fuel Feature Class – This is the input feature class that has the fuel
type polygons in it.
2. Fuel Type Value field – This is an integer field. This is the field that
provides the attributes for the raster layer (an ASCII grid layer).
3. Output Phoenix Data Directory – This is the output folder where all the
PHOENIX data folders will be saved. A folder called “Fuel” will be created
in this directory.
4. Cell Size – This is the finest level of detail to be stored in the data files. The
default is set at 30 m which is suited to most modelling.
PHOENIX_data_preparation_20080413.doc Page 11
PHOENIX – Data Preparation Tolhurst (April 2008)
2. Fire History
There are two main options for preparing the fire history data layer. The first is to
produce a data layer showing the “Last Burnt” fire history where the most recent fire
is shown where a previous fire history is replaced by a more recent fire (Fig. 9). The
second option is where the extent of all known fires is kept, including overlapping fire
areas and an effective Last Burnt fire history can be produced for a specified time in
the past. This second option has much greater flexibility and is therefore preferred.
The fire history is used in PHOENIX during the fuel layer creation process. Based on
the time specified in the simulation, fuel levels will be determined by the combination
of fuel type and the time since the last fire.
1985_04_21
1972_02_13
2008_01_19
1985_04_21
1972_02_13
Figure 9. On the left, two fires have been mapped, one in 1972 and the other in 1985.
On the right, a new fire in 2008 has overlapped these earlier fires and has
replaced their fire history. There is only one layer of fire history.
At present, there is no distinction made between fires of different intensities on fuel
accumulation rates. Users should be aware that intense fires that have resulted in
structural changes to the vegetation may result in fuel accumulation rates different to
those used in PHOENIX.
Fire History Data Preparation Process (Manual Method)
As with the vegetation layer, the aim of this process is to produce an ASCII grid layer
containing the fire history information to be used in the simulation. It is
recommended that a grid cell resolution of 30 m be used. The fire history attribute to
be used in the ASCII grid layer is the fire start date MUST be expressed as an integer
in the format “YYYYMMDD” (e.g. 19850421). If the actual date is not known then
assume the date to be the 1st January for the season of the fire (e.g. 19850101).
a. Assuming You Have a Current “Last Burn” Layer
Using the GIS, make sure you have a field in the attribute table that contains a fire
start date expressed as an integer in the format “YYYYMMDD” (Fig.10).
PHOENIX_data_preparation_20080413.doc Page 12
PHOENIX – Data Preparation Tolhurst (April 2008)
Figure 10. “Burn_Date” is an integer field that contains the fire start date in the format
YYYYMMDD.
There are a number of ways of creating the Burn_Date. However, first of all, you
must create the field in ArcCatalogue. Do this by opening the fire history shapefile
and go to the “Fields” tab on the Feature Class Properties and add “Burn_Date” as a
long-integer data type. This field MUST be called “Burn_Date”.
Figure 11. Adding a field to the fire history shapefile using ArcCatalogue.
Having added the new field “Burn_Date”, you can now either write a Python script to
create the data for this field from within ArcGIS, you can use the ArcGIS Field
Calculator or you can open the attribute table in MS-Access and fill the fields there. It
is always safer to create new fields from within the GIS environment rather than make
them in Access, to make sure all the links are maintained.
In MS-Access, you can use the Update Query process to convert an existing date (or
some other combination) into an integer Burn_Date. One example is shown in
Fig. 12.
PHOENIX_data_preparation_20080413.doc Page 13
PHOENIX – Data Preparation Tolhurst (April 2008)
Figure 12. Creating an integer Burn_Date using an Update Query in MS-Access.
Within ArcGIS you can also create an integer Burn_Date using the Field Calculator,
by opening the attribute table, selecting the Burn_Date field and right click to select
the Field Calculator window. How you use this calculator will depend on the existing
date information in the attribute table already. In the example below, it is just a
matter or reformatting an existing date using the “Format( )” function. An alternative
approach to achieve the same end is to use the “Data Management Tools”, toolbox
and select the “Fields”, “Calculate Fields” option.
Figure 13. Creating an integer date for Burn_Date using the Field Calculator and the
Format function.
PHOENIX_data_preparation_20080413.doc Page 14
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 1. Create a Field in the fire history layer called Burn_Date with an integer
date code. (ArcMap)
The following steps are similar to those used in creating the vegetation data.
Step 2. Convert the fire history layer into an ESRI GRID layer using the Burn_Date
as the attribute for gridding. (ArcMap)
Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)
Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files.
(PHOENIX)
PHOENIX_data_preparation_20080413.doc Page 15
PHOENIX – Data Preparation Tolhurst (April 2008)
b. Assuming You Have a Composite (overlapping) Fire History Layer
The first step is to create a Burn_Date field in the fire history layer as described
above.
Step 1. Create a Field in the fire history layer called Burn_Date with an integer
date code. (ArcMap)
1985_04_21
1972_02_13
2008_01_19
1985_04_21
1972_02_13
Figure 14. In the case of a composite fire history layer, the full extent of all recorded
fires is stored in the layer file indicating areas burnt more than once in the
recorded history.
In the second step, it is necessary this time to use the “Polygon to Raster” Tool. This
tool has an option of specifying a “Priority” field (Fig.15). This can be used to
specify the “Burn_Date” field so that the most recent (largest) date is used to create
the raster layer and all underlying layers (fires) are ignored. In this way, only the
most recent fires are recorded for each raster cell.
Figure 15. Polygon to Raster tool for selecting the most recent fire on a site.
PHOENIX_data_preparation_20080413.doc Page 16
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 2. Convert the fire history layer into an ESRI GRID layer using the Burn_Date
as the attribute for gridding and priority field and the “Polygon to Raster”
tool. (ArcMap)
The remaining two steps are the same as for previous instructions.
Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)
Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files.
(PHOENIX)
The advantage of keeping this overlapping fire history data is that you can create
historic fire history layers for recreation of fire scenarios in the past. Where fires have
overlapped, the most recent fire has not removed the older fire information (compare
Fig. 9 with Fig. 14).
)
in
lass that has
is best if it has the
complete fire history polygons in it (i.e. showing overlapping fires), but it will
Fire History Data Preparation Process (GIS toolbox method
1
2
3
4
The Fire History tool takes in a polygon feature class that represents areas of fire.
These areas must have a field that has an integer value representing the burn date
the format YYYYMMDD. Once rasterised it is then converted to an ASCII file.
Inputs
1. Input: Fire History Feature Class – This is the input feature c
the fire history polygons in it. [This fire history layer
PHOENIX_data_preparation_20080413.doc Page 17
PHOENIX – Data Preparation Tolhurst (April 2008)
also work on “Last Burnt” or “Most Recent” fire history data, but this will
limit the ability to do retrospective simulations.]
2. Burn Date Value Field – This is an integer field in the format
lder where all the
PHOENIX data folders will be saved. A folder called “Fire_History” will be
e
fire history layer, then the fire history data on or
rior to the simulation date needs to be selected using the query tool in the GIS. It is a
good idea to then save this selected fire history and store the output files created in a
subdirectory that includes the date of the retrospective simulation to identify it as not
being a contemporary data set.
YYYYMMDD. This is the field that gets rasterised.
3. Output: Phoenix Data Directory – This is the output fo
created in this directory.
4. Cell Size – This is the finest level of detail to be stored in the data files. Th
default is set at 30 m which is suited to most modelling.
Special Note: If the it is intended to run the PHOENIX model on an historic fire or at
a date earlier than the data in the
p
PHOENIX_data_preparation_20080413.doc Page 18
PHOENIX – Data Preparation Tolhurst (April 2008)
3. Road Proximity Layer
Road Proximity Data Preparation Process (Manual Method)
The road proximity layer is used to determine if there is a road within 2000 m of a
specified point in the landscape, and if it is, how far away it is to the nearest 50 m.
This information is used in PHOENIX to assess, how much, if any, roads will assist in
providing access to fire suppression resources.
In order to develop this layer, first you must have a road layer. This will be a
“Polyline” feature layer. Next you will use the Euclidean Distance tool in the Spatial
Analyst toolbox to create the Road Proximity layer (Fig. 16). The suggested output
cell size is 50 m and the suggested maximum distance is 1000 m. The output file
name has to be “Road_Prox”. This is a raster data set.
Figure 16. Creating the Road Proximity layer from the Road layer using the Euclidean
Distance tool in ArcMap.
Step 1 (and 2). Create a road proximity layer called “Road_Prox”. (ArcMap)
The following steps are similar to those used in creating the vegetation and fire
history datasets. Because the Road_Prox layer is already in ESRI GRID format, Step
2 has already been completed
Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)
PHOENIX_data_preparation_20080413.doc Page 19
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files.
(PHOENIX)
Road Proximity Data Preparation Process (GIS toolbox method)
1
2
3
The Road Proximity tool takes in a Polyline road feature class and uses the Spatial
Analyst Euclidean Distance function to create a Euclidean distance raster representing
the proximity of a cell to the road. This is to a maximum distance of 1,000 m with
cells of 50 m. This Euclidean raster is then converted to an ASCII file.
Inputs
1. Input: Road Feature Class – This is the input Polyline road class.
2. Output: Phoenix Data Directory – This is the output folder where all the
PHOENIX data folders will be saved. A folder called “Road_Prox” will be
created in this directory.
3. Cell Size – This is the finest level of detail to be stored in the data files. The
default is set at 50 m which is suited to most modelling.
PHOENIX_data_preparation_20080413.doc Page 20
PHOENIX – Data Preparation Tolhurst (April 2008)
4. Fuel Disruptions Layer
The Fuel Disruption Layer defines the location and width of linear features such as
roads, streams, firebreaks, and railway lines which are generally devoid of fuel and
may act as barriers to the progress of a fire. There is likely to be a number of GIS
layers needed to describe all the linear fuel disruptions in the landscape, however,
each of these GIS layers MUST have a field in it called: “WIDTH” which described
the effective width of the fuel-free area along the length of the linear feature
(polyline).
The width of the disruption will be used in PHOENIX to determine the extent of the
disruptions on the local fire intensity and will determine if the local fire intensity is
sufficient to breach the disruption.

...

PHOENIX_data_preparation_20080413.doc Page 21
PHOENIX – Data Preparation Tolhurst (April 2008)

Fuel Disruption Data Preparation Process (Manual Method)
It is most likely that different disruptive types such as roads, railways and streams will
have been mapped in different layers, therefore each layer will need to be prepared
and then a combined disruptive layer with a common field “WIDTH” will need to be
compiled by appending the files to a master disruptive layer file.
The following instructions assume that the disruptions will be compiled into a raster
file, with 30 m cells.
Step 1. Create a field in the first disruptive layer called “WIDTH”. (ArcCatalog)
Fig.17.
Step 2. Populate the “WIDTH” field with an effective width (m) for each feature
using either a lookup table joined to the attribute table of the layer or use the Field
Calculator to create a width based on one or other of the attributes in the table.
(ArcMap) Fig.18. (Note: step 1 can be omitted if the name of the width field in the
join layer is already “WIDTH”.)
PHOENIX_data_preparation_20080413.doc Page 22
PHOENIX – Data Preparation Tolhurst (April 2008)
Figure 17. Add a field called “WIDTH” to each of the disruptive layers.
Figure 18. Join the widths of features to the GIS layer based on a classification of the
features such as the AS2482 code.
PHOENIX_data_preparation_20080413.doc Page 23
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 3. Create a single disruption layer by Merging the individual layers into a new
layer called “Disruption”. (ArcMap) Fig.19.
Figure 19. Merge all the disruptive layers into a single layer called “Disruption” using
the Merge tool in ArcMap. All files must contain a common field called
“WIDTH”.
PHOENIX_data_preparation_20080413.doc Page 24
PHOENIX – Data Preparation Tolhurst (April 2008)
Step 4. Create a new layer that has a buffer around each polyline, the width of this
buffer should equal the size of the raster grid to be used. Use 15 m as a default for a
30 m raster grid. (ArcMap) Fig.20.
Figure 20. Create a new layer for disruptions such as streams by applying a buffer
(15 m) around each polyline.
Step 5. Convert the buffered disruptive layer into an ESRI grid. (ArcMap) Fig.21.
Figure 21a. Converting the buffered fuel disruptions into an ESRI grid format using the
Feature to Raster conversion tool. (see Fig.21b for an alternative method).
PHOENIX_data_preparation_20080413.doc Page 25
PHOENIX – Data Preparation Tolhurst (April 2008)
F
ation_20080413.doc Page 26
igure 21b. Converting the buffered fuel disruptions into an ESRI grid format using the
ore options
than the feature to raster tool, i.e. the method of picking up polygon
Polygon to Raster conversion tool. Note that this tool has m
attributes (Cell_Centre) and the ability to discriminate which one of a
number of overlapping features you will include in the final grid file
(Priority Field).
Step 6. Convert the ESRI grid into an ASCII grid. (ArcMap) Fig.22.
Figure 22. Convert the ESRI grid into an ASCII grid using the Raster to ASCII
conversion tool. The output file must be called “disruption.asc”.
Step 7. Convert the ASCII grid file into a compressed set of ASCII tile files.
(PHOENIX)
PHOENIX_data_prepar
PHOENIX – Data Preparation Tolhurst (April 2008)
Fuel Disruption Data Preparation Process (GIS toolbox method)
1
2
3
The Disruption conversion tool takes in a number of Polyline feature classes, joins
them together and rasterises them. Once rasterised it is then converted to an ASCII
file.
There is one requirement for the input Polyline classes. They MUST have a fully
populated (i.e. every feature) field called WIDTH that represents the width (in whole
meters) of the feature.
Inputs
1. Input: Disruption Feature Class – These are the input Polyline feature
classes that are to be merged into the output ASCII.
2. Output: Phoenix Data Directory – This is the output folder where all the
PHOENIX data folders will be saved. A folder called “Disruption” will be
created in this directory.
3. Cell Size – This is the finest level of detail to be stored in the data files. The
default is set at 30 m which is suited to most modelling.
PHOENIX_data_preparation_20080413.doc Page 27
PHOENIX – Data Preparation Tolhurst (April 2008)
5. Digital Elevation Model Layer
Digital Elevation Model Data Preparation Process (GIS toolbox method)
1
2
The DEM conversion tool takes in a Digital Elevation Model raster and converts it to
an ASCII file, with optional optimising for Phoenix.
Inputs
1. Input: DEM Raster – This is the DEM raster that needs to be converted. It
can be in any format readable by ArcMap 9.2
2. Output: Phoenix Data Directory – This is the output folder where all the
PHOENIX data folders will be saved. A folder called “DEM” will be created
in this directory. The resolution of the ASCII data will be the same as the
original DEM data.
PHOENIX_data_preparation_20080413.doc Page 28
PHOENIX – Data Preparation Tolhurst (April 2008)
Appendix 1.
Fuel Types currently recognised in southern Australia.
PHOENIX_data_preparation_20080413.doc Page 29
VegType FuelCode No. Description

...

Bare Herbs Grass/sedges G01 16 High Elevation Grassland dense sward of tussock grasses or herbs, high cover
Shrubs Heaths Mallee Woodland Forest PlantationsInput data to the model must be prepared in a GIS such as ESRI's ArcGIS or MapInfo. This base data is then converted into a format read by PHOENIX which is an ASCII grid broken into data "tiles", 30 x 30 cells wide. This tiling can be easily done in ArcGIS using a specially developed "Toolbox". The base input data is usually at 20 or 30m resolution, but when it is read into PHOENIX it is averaged into larger cells to speed computations. Typically the grid cell size for PHOENIX computation is 100 or 200m, but could range from 50 to 500m depending on the nature of the terrain and the level of detail required.

This document describes the data files that are obtained from the Gridded_Weather and Data directories. 

The actual location of these directories is specified in the project file, and usually defaults to subdirectories of C:\Phoenix

Sub directories :-

Image Added

The Data Directory

The Data directory normally contains input layers that have been created by hand.

General Requirements

1. All data layers must be in the same coordinate system, and this must be a map grid projection (grid reference in metres) not a geographic one (latitude and longitude in degrees).
   In Victoria, we suggest using "VicGrid 94" which is a Lambert Conformal Conic Projection with a GDA 94 reference Datum.
   Across Australia, we suggest "Geoscience Australia Lambert 94" projection which is a Lambert Conformal Conic Projection with a GDA 94 reference Datum.
   
   
2. The only data layer that MUST be provided is the Fuel Layer.
   However, other layers make the simulation much more realistic. If there is no data file location specified, then the input value will be zero.
   
   
3. As all data layers must be in the same coordinate system only one projection file is required.  The default name of this file is data.prj and is best located in the root of the Data directory.
   The format of the projection file conforms to the requirements of ESRI ArcGIS 9.
   
   
4. Layers can be provided as zip files, to decrease the size of data that has to be copied around.

Possible Input Layers

The actual layers that Phoenix will use in a simulation are configured in the Project window, on the Data tab. The list below is the complete set of possible layers:

Mandatory

• Fuel Layer - developed from a vegetation layer

Optional

• Digital Elevation Model (DEM) - from which to calculate slope, aspect and elevation
• Fire History Layer, with an optional Supplementary Fire History Layer - from which to calculate the current level of fuels across the landscape
• Road Proximity Layer - from which to determine the level of assistance given to suppression
• Disruption Layer - from which to determine the effect of linear features such as roads, rivers, railway lines and fire breaks, on fire behaviour and spread
• Assets Layer - assists in assessing asset impact during the fire simulation.  Assets include Housing, Infrastructure, Plantation and Rainforest
• Wind Modifiers Layer - assists in making changes to local wind speed and direction
• Curing Layer
• Drought Factor Layer

Example :-

Image Added

Other files in the Data directory

In addition to the source data for running the PHOENIX model, it is also necessary to have a visual reference layer such as a satellite image or topographic map on which to set up the simulation area and to overlay the results of the simulation.  More on this below.

Gridded Weather

The Gridded_Weather directory is expected to contain gridded forecast weather data in the form of NetCDF files normally obtained from the Bureau of Meteorology.  This data is produced twice a day by the BOM. A downloading process has to be put in place to get this data, but it is restricted to registered users. PHOENIX will also run on a single stream of weather data 

TBD - Info about the weather downloader required.

Image Added

The Tools dropdown menu provides the options to

• Download Gridded Weather - get the latest gridded weather from the Bureau of Meteorology ftp server (only available to registered users)
• Shut Down Phoenix Workers - a facility to run separate simulations, in a parallel process, on a cluster of computers or on different processors for multi-core processors such as Quad-cores. This is a function set up for large simulations.
• Unpack Phoenix Datafile - unpack the zipped input data tiles to compile a single ASCII file
• Edit Fuel Types
• Edit Suppression Rates
• Push data to nodes - such as write the simulation inputs and outputs to the ignition points

TBD - populate this section with a description of how to use the weather downloader

Refer to the manual for how to use weather entered directly into the UI/project file

Other directories

Application

This is where you'll find Phoenix.exe which you can use to run the application.

Image Added

Outputs

This will ultimately contain the range of files produced from the simulations.

Projects

This will store the .xml files containing the settings for each simulation created.

Data Preparation Requirements

Datum and Coordinate System

All data needs to be prepared in a consistent projection that has a scale in metres. You cannot use a geographic coordinate system using measurement in degrees. For consistency across Australia, we recommend using the GDA_1994_Geoscience_Australia_Lambert projection.

GIS Software

GIS software is an ongoing problem. We have decided to write PHOENIX to use ESRI ArcGIS 9.2, sp4. You need a licence to operate ArcGIS 9.2 ArcView (or similar Arc product such as ArcEditor, ArcInfo). It is our intention to keep the PHOENIX software compatible with the most recent version of ESRI ArcGIS. 

Source Data Preparation

1. Fuel (Vegetation)

The Fuel layer is used in conjunction with the fire history layer to create the fuel attributes used in PHOENIX. It has been assumed that the vegetation layer is the layer most likely to be kept up-to-date and more readily available than a purpose built fuel type layer. However, it is also acknowledged that there are several vegetation type classifications and a range of mapping detail and quality within some states and between states. Therefore, the approach taken in PHOENIX has been to convert various vegetation classifications into a standard set of fuel types, e.g. there are about 700 vegetation types mapped in Victoria and these are classified into about 40 different fuel types.

The user needs to assign a fuel type to every vegetation type in the area of interest. To enable this, a code for each vegetation type is needed, e.g. 97 – Semi-arid Woodland. This code is used in a lookup table and joined to a fuel-type code. This fuel type code must then be added to the attribute table for the vegetation map in a GIS. The setting up of the conversion process is beyond the scope of these notes, but
it can be done by “Joining” the lookup table to the vegetation attribute table in the GIS.

Image Added

An example of a list of vegetation codes and their matching fuel type code.  Several vegetation types may be in the same fuel type.

The fuel mapping must cover the whole area. Areas with no fuel type mapped will be assumed to carry no fuel and therefore will not carry fire (e.g. a water body).

The fuel type layer (and all other input data layers for PHOENIX) needs to be converted to an ASCII grid (.asc) format. The cell size units must be in metres (m), and the cell size must be in whole numbers. A cell size of 30 m is recommended for vegetation. The ASCII file must be called: “fuel.asc”.

Once the “fuel.asc” file has been prepared, it is processed in PHOENIX to compress the data, divided into tiles, and stored in a folder called: “fuel”. This process will be explained in more detail.

Fuel data preparation process - Manual Method

It is necessary for the user to prepare a comprehensive vegetation data layer for the area to be used. Each vegetation type must be identified with a unique code. Below
shows an example of an attribute table associated with a vegetation layer (shapefile).  “VEG_ID” is the unique code that will be used to assign each vegetation type to a fuel
type. Once the vegetation layer has been attributed with the fuel type codes, it can be used to create the ASCII grid layer. The name given to this fuel type field is not critical. Producing an ASCII grid is a two step process with the intermediate process being the production of a raster layer with the ESRI grid format.

Step 1 - create a unique integer code for each fuel type (ArcMap)

Image Added

Two tools are available to convert the shapefile to an ESRI GRID (raster), “Feature to Grid” (below) and “Polygon to Grid”. Specify the output file as “vegetation (no extension)” and the output cell size as 30m.

Step 2. Convert the shapefile to an ESRI GRID file. (ARCMap)

Image Added

Once the ESRI GRID (raster) file has been created, it must be converted to an ASCII grid format. To do this, use the Conversion Tool – From Raster to ASCII tool. The output ASCII file must be called “fuel.asc”.

Step 3. Convert the ESRI GRID file to an ASCII grid file. (ARCMap)

Image Added

This ASCII grid file must now be compressed and broken into tiles using a facility in PHOENIX. The fuel, or any other layer, can be converted on its own, or all together, the choice will be yours.
Start by opening PHOENIX. Then select the “Phoenix GIS Data Converter” from the “Data” dropdown menu.

Image Added

Navigate your way to the folder containing the vegetation ASCII grid file and select it. “Start” the compression and tiling process. The data files will be output to a folder within the one you selected with the ASCII grid file. This folder will be called “fuel” and if it does not already exist, it will be created.

Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files.

Image Added

The “Date Converter” tool in PHOENIX converts the ASCII grid data into the format needed to run PHOENIX simulations. Note: in this case only the fuel data is being processed, but other layers could be processed at the same time if desired.

This fuel data will be used in conjunction with the fire history layer to convert them into a current fuel levels when a fire grid is created in PHOENIX. The process of doing this will be explained later.

The fuel layer is now ready for use.

Fuel data preparation process - ArcGIS Toolbox Method

The data preparation process can be simplified by using a set of customised tools developed to be used in ArcGIS 9.2 to produce the data files required as input to PHOENIX.

In order to use these tools, first they must be installed on your GIS program.

Installation

Pre-Check

The toolbox and scripts are stored in a folder in the PHOENIX root directory called Scripts. This will typically be C:\Phoenix\Scripts

It is important to check that these files are in the Scripts folder:

• DEM.py
• Disruption.py
  
• Fire_History.py
  
• Phoenix Data Optimiser.exe
  
• Phoenix.Grid.dll
  
• PhoenixTools.tbx
  
• Road_Proximity.py
  
• Fuel.py
  

The five files denoted with the .py extension are the Python scripts. These are written in Python 2.4 and should work with a standard ArcGIS 9.2 installation.

The .exe and .dll are the files required to perform data conversion from a shapefile or grid format to PHOENIX format. This will be run in the tool, but it is a standalone program that can be run separately on other ASCII files.

The .tbx file is the ArcGIS Toolbox that the user adds to the built-in toolboxes.

Adding the Toolbox to ArcGIS

In this section the user will add the toolbox to the ArcGIS tool list.

Step 1. Open ArcGIS to either the default environment or a previous project.
Step 2. Open the toolbox panel by clicking icon 1

Image Added

Step 3. Right-click inside the panel so that the context menu opens up and select “Add Toolbox…” as shown below.

Image Added

Step 4. Navigate to the Phoenix\Scripts directory and select PhoenixTools.

Image Added

Do not double click as this opens the toolbox as a folder, but doesn’t add it. Once selected, click Open.

Step 5. Once added, click the + next to Phoenix Tools and then the Data Preparation tab and this should expand to reveal the five scripts.

Image Added

Image Added

2. Fire History

There are two main options for preparing the fire history data layer. The first is to produce a data layer showing the “Last Burnt” fire history where the most recent fire is shown where a previous fire history is replaced by a more recent fire (see below). The second option is where the extent of all known fires is kept, including overlapping fire areas and an effective Last Burnt fire history can be produced for a specified time in the past. This second option has much greater flexibility and is therefore preferred.

The fire history is used in PHOENIX during the fuel layer creation process. Based on the time specified in the simulation, fuel levels will be determined by the combination of fuel type and the time since the last fire.

Image Added
On the left, two fires have been mapped, one in 1972 and the other in 1985. On the right, a new fire in 2008 has overlapped these earlier fires and has replaced their fire history. There is only one layer of fire history.

At present, there is no distinction made between fires of different intensities on fuel accumulation rates. Users should be aware that intense fires that have resulted in structural changes to the vegetation may result in fuel accumulation rates different to those used in PHOENIX.

Fire History Data Preparation Process - Manual Method

As with the vegetation layer, the aim of this process is to produce an ASCII grid layer containing the fire history information to be used in the simulation. It is recommended that a grid cell resolution of 30m be used. The fire history attribute to be used in the ASCII grid layer is the fire start date MUST be expressed as an integer in the format “YYYYMMDD” (e.g. 19850421).  If the actual date is not known then
assume the date to be the 1st January for the season of the fire (e.g. 19850101).

a. Assuming You Have a Current “Last Burn” Layer

Using the GIS, make sure you have a field in the attribute table that contains a fire start date (Burn_Date) expressed as an integer in the format “YYYYMMDD”.

Image Added

There are a number of ways of creating the Burn_Date. However, first of all, you must create the field in ArcCatalogue. Do this by opening the fire history shapefile and go to the “Fields” tab on the Feature Class Properties and add “Burn_Date” as a long-integer data type. This field MUST be called “Burn_Date”.

Image Added

Having added the new field “Burn_Date”, you can now either write a Python script to create the data for this field from within ArcGIS, you can use the ArcGIS Field Calculator or you can open the attribute table in MS-Access and fill the fields there. It is always safer to create new fields from within the GIS environment rather than make them in Access, to make sure all the links are maintained.

In MS-Access, you can use the Update Query process to convert an existing date (or some other combination) into an integer Burn_Date. One example is shown below.

Image Added

Within ArcGIS you can also create an integer Burn_Date using the Field Calculator, by opening the attribute table, selecting the Burn_Date field and right click to select the Field Calculator window. How you use this calculator will depend on the existing date information in the attribute table already. In the example below, it is just a matter of reformatting an existing date using the “Format( )” function. An alternative approach to achieve the same end is to use the “Data Management Tools”, toolbox and select the “Fields”, “Calculate Fields” option.

Image Added

1. Create a Field in the fire history layer called Burn_Date with an integer date code. (ArcMap)
   The following steps are similar to those used in creating the vegetation data.
   
2. Convert the fire history layer into an ESRI GRID layer using the Burn_Date as the attribute for gridding. (ArcMap)
   
3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)
   
4. Convert the ASCII grid file into a compressed set of ASCII tile files.

b. Assuming You Have a Composite (overlapping) Fire History Layer

The first step is to create a Burn_Date field in the fire history layer as described above.

Step 1. Create a Field in the fire history layer called Burn_Date with an integer

Image Added
In the case of a composite fire history layer, the full extent of all recorded fires is stored in the layer file indicating areas burnt more than once in the recorded history.

Step 2. Convert the fire history layer into an ESRI GRID layer

Image Added

It is necessary this time to use the “Polygon to Raster” Tool. This tool has an option of specifying a “Priority” field. This can be used to specify the “Burn_Date” field so that the most recent (largest) date is used to create the raster layer and all underlying layers (fires) are ignored. In this way, only the most recent fires are recorded for each raster cell. 

The remaining two steps are the same as for previous instructions.

Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)

Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files. (PHOENIX)

The advantage of keeping this overlapping fire history data is that you can create
historic fire history layers for recreation of fire scenarios in the past. Where fires have
overlapped, the most recent fire has not removed the older fire information.

Image Added
Image Added

3. Road Proximity Layer

Road Proximity Data Preparation Process - Manual Method

The road proximity layer is used to determine if there is a road within 2000m of a specified point in the landscape, and if it is, how far away it is to the nearest 50m.  This information is used in PHOENIX to assess, how much, if any, roads will assist in providing access to fire suppression resources.

In order to develop this layer, first you must have a road layer. This will be a “Polyline” feature layer. Next you will use the Euclidean Distance tool in the Spatial Analyst toolbox to create the Road Proximity layer. The suggested output cell size is 50m and the suggested maximum distance is 1000m. The output file name has to be “Road_Prox”. This is a raster data set.

Image Added

Step 1 (and 2). Create a road proximity layer called “Road_Prox”. (ArcMap)

The following steps are similar to those used in creating the vegetation and fire history datasets. Because the Road_Prox layer is already in ESRI GRID format, Step 2 has already been completed

Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)

Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files. (PHOENIX)

Road Proximity Data Preparation Process - GIS toolbox method

Image Added

4. Fuel Disruptions Layer

The Fuel Disruption Layer defines the location and width of linear features such as roads, streams, firebreaks, and railway lines which are generally devoid of fuel and may act as barriers to the progress of a fire. There is likely to be a number of GIS layers needed to describe all the linear fuel disruptions in the landscape, however, each of these GIS layers MUST have a field in it called: “WIDTH” which described
the effective width of the fuel-free area along the length of the linear feature (polyline).

The width of the disruption will be used in PHOENIX to determine the extent of the disruptions on the local fire intensity and will determine if the local fire intensity is sufficient to breach the disruption.

Fuel Disruption Data Preparation Process - Manual Method

It is most likely that different disruptive types such as roads, railways and streams will have been mapped in different layers, therefore each layer will need to be prepared and then a combined disruptive layer with a common field “WIDTH” will need to be compiled by appending the files to a master disruptive layer file.

The following instructions assume that the disruptions will be compiled into a raster file, with 30m cells.

Step 1. Create a field in the first disruptive layer called “WIDTH”. (ArcCatalog)

Image Added

Step 2. Populate the “WIDTH” field. 

Image Added

Use an effective width (m) for each feature using either a lookup table joined to the attribute table of the layer or use the Field Calculator to create a width based on one or other of the attributes in the table.
(ArcMap). (Note: step 1 can be omitted if the name of the width field in the join layer is already “WIDTH”.) Join the widths of features to the GIS layer based on a classification of the features such as the AS2482 code.

Step 3. Create a single disruption layer

Image Added

Merge all the disruptive layers into a single layer called “Disruption” using the Merge tool in ArcMap. All files must contain a common field called “WIDTH”.

Step 4. Create a new layer that has a buffer around each polyline.

Image Added

The width of this buffer should equal the size of the raster grid to be used. Use 15m as a default for a 30m raster grid. (ArcMap)

Step 5. Convert the buffered disruptive layer into an ESRI grid. (ArcMap)

Image Added

The above show converting the buffered fuel disruptions into an ESRI grid format using the Feature to Raster conversion tool. (see below for an alternative method).

Image Added

Converting the buffered fuel disruptions into an ESRI grid format using the Polygon to Raster conversion tool. Note that this tool has more options than the feature to raster tool, i.e. the method of picking up polygon attributes (Cell_Centre) and the ability to discriminate which one of a number of overlapping features you will include in the final grid file (Priority Field).

Step 6. Convert the ESRI grid into an ASCII grid. (ArcMap)

Image Added

Convert the ESRI grid into an ASCII grid using the Raster to ASCII conversion tool. The output file must be called “disruption.asc”.

Step 7. Convert the ASCII grid file into a compressed set of ASCII tile files. (PHOENIX)

Image Added

5. Digital Elevation Model Layer

Digital Elevation Model Data Preparation Process - GIS toolbox method

Image Added

6. Assets Layer

Phoenix incorporates an asset impact model that can calculate asset impact during the fire simulation process. Impacts can calculated for up to 99 asset types and evaluated against up to 99 loss functions, these functions can express loss as a percentage of any of the fire characteristics calculated during the simulation process.

Characterising fires by asset impact provides an additional means of comparing fires. This can be useful for prioritising fires in a tactical scenario or strategically for quantifying the effectiveness of a specific treatment. Asset impact can be a more meaningfully measure than traditional characteristics like fire area, average intensity, perimeter length, etc.

Assets are incorporated as a standard Phoenix dataset. The major limitation of this process is that only one Asset can be recorded against a 30 m cell which requires assets to be in a priority order.

Asset Code Description

The Phoenix asset code is an unsigned 9 digit integer (max integer length supported by shapefile .dbf files). The code is composed of the following 4 parts:

Image Added

7. Wind Modifiers Layer

The "Wind Modifiers" data layer assists in making changes to local wind speed and direction due to the influences of the topography. Phoenix uses a "Mass Conservation" model called "Wind Ninja" developed by Jason Forthofer in 2007. A mass conservation model allows for winds to speed up over hills and be channeled up valleys to some extent, but it does not reproduce the full fluid dynamics of wind flow. However, it is considered worthwhile to take some account of topography on local wind speed and direction rather than assume that it is uniform across the landscape.

The only input data needed to create the Wind Modifiers layer is the Phoenix DEM (topography) layer. Winds of all speeds and directions are modelled across this terrain to determine the appropriate wind modifiers for all situations.

Use the "Wind Modifiers" tool in the Phoenix Toolbox to create this data layer for Phoenix. The output file will be in the same folder as the DEM layer used. This process can take a very long time.

Image Added