Transcript FTS#3

Evaluation of Existing Fire
Tracking Systems
FEJF Meeting
Day 1, 1030a – Albuquerque, NM
1
Project Overview
• Is there an existing FTS system, with few or
minor modifications, that will satisfy the
WRAP’s requirements for an FTS.
• Web-based and historical systems (e.g.,
wildfire systems) to be reviewed.
• Primary emphasis of this project is on realtime data import and export capabilities.
• Evaluation made from the perspective of an
FTS user.
2
Project Goals
• Evaluate existing FTS and provide:
– A feasibility assessment of existing systems.
– An analysis of modifying each system to
include WRAP needs.
– Estimate resources needed to modify the system
to meet the required elements for tracking
prescribed fires.
3
Systems Evaluated
1.
2.
3.
4.
5.
6.
7.
San Joaquin Valley Smoke Management System
Wayne Clark
Airshed Management System (formerly, RAZU)
Dave Grace, USDA – Forest Service
Smoke Management Database – New Mexico
Lisa Bye, USDOI – BLM, NPS, FWS in New Mexico
Nez Perce Tracking System
Andrea Boyer, Nez Perce Tribe
South Carolina Tracking System
Ken Cabe, South Carolina Department of Forestry
Florida Tracking System
Jim Brenner, Florida Division of Forestry
USDA Smoke Management System
Dale Guenther, USDA – Forest Service
4
Project Methodology
• Develop evaluation
chart that includes:
– Basic data elements
– System information
– Front- and Back-end
applications
– Indexing and reporting
– Optional modules
– Interface/exchange of
data
• Conduct interviews
with current FTS
users/managers.
• Feasibility assessment
of 7 systems.
• Shortlist and assess 3
systems
– Necessary
modifications
– Cost to modify & host
5
Feasibility Assessment
• Reviewed all FTS for all elements and
system characteristics listed in the
Workplan.
• Developed a point system to rank the
evaluated FTS.
– Importance of each category of elements
reflects Project Team judgment.
• Maximum possible points:
Basic Elements = 55 System-Related Features = 45.
6
Feasibility Assessment
•
Bonus Point Categories
1. 2 points per each Basic Elements category
-- the majority of listed elements were included in the
FTS and/or if all critical elements were included.
2. 5 bonus points to overall score
-- if the Project Team identified some unique
flexibility, an apparent ease in transfer of the FTS to
the future WRAP system , and/or an expressed
willingness of the current FTS host to support
transfer to the WRAP system.
7
Table 1 - FTS Evaluation Point System
Data Elements
Task 2.A. Basic Data Elements
Critical Elements Evaluated
Max
Possible
Points
Burn Date Start date; end date
Burn Location Latitude/longitude
Burn Area Size of burn (acres); fuel type
Components related to Annual Emission Goals
Emission Reduction Techniques Any ERT element
Bonus Ranking
Total for Basic Data Elements
Task 2.B. System Information
Web-based, exporting capabilities
Task 2.C. Back-End and Front-End Applications
Task 2.D. Indexing and Reporting
Task 2.E. Optional Modules
10
10
10
15
5
5
55
15
10
10
5
Task 2.F. Interface and/or Data Exchange
Total for System-Related Features
5
45
Total Maximum Possible Score
100
8
Feasibility Assessment
•
Points assigned in a 2-step process:
Step 1 – Each individual element listed in the
evaluation table was objectively scored (0 =
not included; 1 = included; 3 = critical
elements included) and an overall bonus for
the category was scored (0 = few if any
elements are included; 2 = most and/or critical
elements included).
9
•
Step 1 Example – For the Burn Date category (14 points total).
–
8 listed elements
•
•
•
•
•
•
•
•
•
start date – CRITICAL 3 POINTS
start hour – 1 point
multi-day start dates – 1 point
multi-day start hour – 1 point
end date – CRITICAL 3 POINTS
end hour – 1 point
multi-day end dates – 1 point
multi-day end hour – 1 point
2 bonus points if majority of elements or all critical elements are present in
the FTS.
FTS#1 - both critical elements and none of the other listed elements. - FTS#1 receives an objective total score of 8.
FTS#2 - includes 1 critical element (start date) and 3 listed elements.
- FTS#2 receives an objective total score of 6.
FTS#3 - includes all listed elements and receives the maximum of 14
points.
10
Feasibility Assessment
Step 2 – Based on the objective scores in step 1,
each FTS was assigned a score for the
category based on the maximum possible
points for the category. Within a category, the
relative points assigned to an FTS accurately
reflected how well it stacked up against all of
the other FTS.
11
•
Example (Burn Date category): Total possible
points for the Burn Date category is 10.
FTS#1 (objective score of 8) is assigned a 7 (all
critical elements; no additional listed elements).
FTS#2 (objective score of 6) is assigned a 5 (one
critical element; two of four other listed
elements).
FTS#3 (objective score of 14) is assigned a 10 (all
listed elements).
12
Table 2 - FTS Evaluations
Max
Possible
Points
San Joaquin
Valley
Airshed
Management
System
(MT/ID)
Burn Date
Burn Location
Burn Area
Components related to Annual Emission Goals
Emission Reduction Techniques
Bonus Ranking
Total for Basic Data Elements
Task 2.B. System Information
Task 2.C. Back-End and Front-End Applications
Task 2.D. Indexing and Reporting
Task 2.E. Optional Modules
Task 2.F. Interface and/or Data Exchange
Total for System-Related Features
10
10
10
15
5
5
55
15
10
10
5
5
45
5
7
9
12
0
0
33
6
3
4
0
0
13
3
8
9
4
0
5
29
10
6
4
0
0
20
5
8
9
13
0
5
40
12
8
8
3
0
31
7
2
6
10
0
0
25
4
10
0
5
0
19
Total Maximum Possible Score
100
46
49
71
44
Data Elements
Task 2.A. Basic Data Elements
Smoke
Nez
South
Management
Perce
Carolina
Database
Tracking Tracking
(NM)
System System
Florida
Tracking
System
USDA Smoke
Management
System
5
9
9
10
0
0
33
4
5
4
0
0
13
5
10
7
10
0
0
32
4
3
4
0
0
11
5
8
7
10
0
5
35
12
10
10
0
0
32
46
43
67
13
Short-Listed Systems (3)
•
•
State of New Mexico Smoke Management
Database (total score 71)
USDA Smoke Management System (total score
67).
Summary: --
Both include most of the critical elements.
-- Both received the five bonus points for apparent
flexibility, ease in transfer, and/or willingness of host
to support transfer the FTS to the WRAP FTS.
-- Both scored well in the Indexing and Reporting category.
-- No obvious incompatibilities with transferring over
either system to the WRAP FTS.
14
Short-Listed Systems (3)
A 3rd FTS was considered and added to the
short list (as approved by the FTS Task
Team)
• Airshed Management System (MT/ID).
Summary: --
The unique aspects of this FTS include a standard
and rigorous architecture, an interactive mapping
website, and features that promote regional
coordination.
15
Technical Mods and Costs
• List of Essential Elements developed based on:
– WRAP Policy – Fire Tracking System (April 2, 2003),
– “Needs Assessment for Evaluating and Design of an Emission
Data Reporting, Management, and Tracking System” (July 25,
2003 – in particular those sections pertaining to fire tracking),
– “Fire Tracking System” presentation from the Coeur d’Alene,
Idaho meeting on May 15-17, 2001, and the WRAP Emissions
Data Management System (EDMS) design information,
– The detailed list of basic and system elements for an FTS as
presented in the Final Workplan for this Project.
– Materials prepared by the Regional Coordination Task Team of the
FEJF
16
KEY FEATURES OF WRAP FTS
Elements
Date of Burn
Burn Location
Area of Burn
Fuel Type
Pre-Burn Fuel Loading
Type of Burn
Nat/Anth
Annual Emission Goal Info
AEG (addl)
Projections
Emissions
Emissions (addl)
System Features
Real time data import and export
Web based
Can info easily be shared between states
GIS/mapping capabilities
Conventional system language & design
Important
Characteristics
Straightforward queries
Straightforward reporting
Important Elements for Regional Coordination
Basic Elements of FTS Policy
17
Technical Modifications - Method
• Assessment of technical modifications to
create an FTS with all essential elements
and key system characteristics.
– Devised an system to evaluate merits of one
FTS in relationship to the other FTS
• -1 or -2 – system deficient compared to other FTS
• 0 – system essentially as proficient as other FTS
• +1 or +2 – system more proficient compared to
other FTS
18
Technical Modifications - Summary
• WRAP FTS Requirements
– Existing FTS are evaluated to be very similar in
terms of meeting the WRAP FTS Requirements
• NM – Score +2 (PM emissions and track multi day
burns)
• MT/ID – Score +1 (flexible user permissions)
• USDA – Score +1 (flexible user permissions)
19
Technical Modifications - Summary
• WRAP FTS System Characteristics
– MT/ID and USDA have the system edge over NM
• NM – Score 0 (plus - simple ACCESS system; minus – size
and user limits; not protected well from corruption)
• MT/ID – Score +4 (plus - built in automation; supports many
users and records; minus - more complex to manage; expensive
to implement Web GIS)
• USDA – Score +4 (plus - built in automation; supports many
users and records; minus - more complex to manage; system
currently under development so features could not be tested)
20
Table 4 - WRAP FTS Requirements
FTS Requirements Total Points:
Element
What required fields are
missing?
2
New Mexico
Burn hour, location of closest town, burn
agency info., blackened acres, ERT
emission factors, emission reductions,
responsible agency
0
Yes with limitations (see Table 2)
Can the system perform
emissions calculations?
PM10 emissions are estimated by means
of emission factors, acreage, and
tonnage.
1
Is there ERT support?
ERT’s are recorded but no emission
reduction information
0
0
Queries must be created by user with
access to the application server
Is there an ability to assign Yes, only at the database level
different user permissions?
Is there Annual Emission
Goal support?
0
0
0
No ERT information.
0
Is there ad-hoc query
support?
Burn hour, location of closest town,
emissions, emission factors, ERT, burn
agency info., blackened acres, ERT
emission factors, emission reductions,
responsible agency
Yes
USDA
No emissions.
Predetermined map images
Yes
Is there multi-day burn
support?
No
Is there support for
Importing from or exporting
to other systems?
1
MT/ID
Is the system web-based?
Is there a GIS capability?
1
1
Currently developing a web-based
interactive ArcGIS server application to
display burn locations and associated
database information.
No
0
Queries must be created by user with
access to the application server
All FTS have essentially the same missing data
elements.
0
Web-friendliness of all FTS is similar.
0
NM has the edge here, with PM emission
calculation cabability. While not sophisticated,
it's funtional and relatively simple to add
pollutants and use the same calculation method.
0
Capability to deal with ERT's is essentially nonexistent with all FTS. Would have to build this
capability from scratch.
0
Currently, systems deal with GIS is a limited
way, at best. MT/ID does provide a client-based
interactive system that can only be used by one
user with access to the application. Waiting for
MT/ID or USDA is an option. Our assumption for
this assessment is that GIS functionality would
have to be added to any of the FTS.
0
NM is currently the only system that supports
this.
0
Ability to communicate with other systems would
have to be added to any FTS chosen.
0
Similar query capabiliites for all three FTS.
Whether the WRAP takes query support as-is or
enhances it, it would be the same effort for all
FTS.
1
Permission capabilities essentially the same for
all FTS.
0
Capability to deal with AEG is essentially nonexistent with all FTS. Would have to build this
capability from scratch.
Currently developing a system that uses
Google Earth to display burn locations
and associated database information.
0
0
No
No
0
Yes, per record, table, or view
Queries must be created by user with
access to the application server
Yes, per record, table, or view
1
No
0
0
No ERT information.
0
0
No
Currently developing a link to
CONSUME.
0
No
0
Burn hour, location of closest town,
emissions, emission factors, ERT, burn
agency info., blackened acres, ERT
emission factors, emission reductions,
responsible agency
Yes*
Assessment
No
0
* Latest version of the interface is in beta and some new features including the add/change burn data are not yet functional.
21
Table 5 - FTS System Characteristics and Requirements
FTS Requirements Total Points:
Ease of use of web interface
0
4
New Mexico
Montana/Idaho
Easy button navigation and plenty of help.
Use of acronyms provides some confusion
of web page organization.
1
Not clear that you can indicate type of fuel.
Relationship between preseason and
proposed burn is not clear.
Can only set-up permissions at the file
level.
0
Can set-up permissions by table, view, or
record.
4
4
Assessment
0
Easy button navigation with clear labels.
Latest version of the interface is in beta
form and not currently available for testing
by the Project Team. Some of the new
features are not yet available.
-1
Web interfaces are relatively straightforward…with
the potential for some confusion with MT/ID and
upcoming improvements for USDA.
1
Can set-up permissions by table, view, or
record.
1
MT/ID and USDA have greater flexibility for
permission settings. May or may not be a critical
aspect of the WRAP FTS.
1
Perhaps the biggest limitation to the NM system.
If the WRAP FTS is limited to approximately 30
total users with concurrent access limited to 10
users, then this limitation becomes unimportant.
1
MT/ID and USDA have more flexibility to execute
scheduled jobs automatically.
1
MT/ID and USDA are more robust systems.
1
Quite possible that NM system will bump up
against storage limitations without expansion of
backend.
1
Quite possible that NM system will bump up
against storage limitations without expansion of
backend.
-1
NM system requires less software expertise to setup and maintain. Although the sophistication of
the WRAP FTS in general may require enough
database/software expertise to maintain that the
expertise required by MT/ID and USDA would be
in place anyway.
0
Essentially no software costs associated with NM.
Modest software expense for MT/ID and USDA.
0
Signigicant software expense for MT/ID for the
ArcGis Server, modest expense for NM and
USDA.
0
Essentially the same basic server requirements for
all FTS.
USDA
System Characteristics
Permission
Users
Automatic Scheduled Jobs
Robust Queries
System Storage Capacities
Database Record Limits
Limited to approximately 10 concurrent
users in a web environment.
-1
Able to support hundreds of concurrent
users
Difficult to create automatic scheduled jobs
such as back-ups or data aggregation.
0
Database can become corrupt if client
query fails to complete.
-1 from becoming corrupted because of
1
Use of transaction logs prevent database
1
incomplete queries.
More than 1,000,000 TB
2 GB database size limit. Includes data,
queries, and forms
-1
One database will hold approximately
2,000,000 fire records
0
1
Built-in ability to set-up scheduled jobs that
run automatically.
Use of transaction logs prevent database
from becoming corrupted because of
incomplete queries.
More than 1,000,000 TB
1
Limited by server storage.
Easy to set-up database and develop
queries and forms.
Ease of Use of System
Built-in ability to set-up scheduled jobs that
run automatically.
1
Able to support hundreds of concurrent
users
Limited by server storage.
1
Somewhat complex to set-up and manage
database. Requires good knowledge of
SQL language.
-1
Somewhat complex to set-up and manage
database. Requires good knowledge of
SQL language.
Hardware and software
requirements
MS Access 2000 (~ $230)
1
Software
ArcView desktop software (~ $1,500)
required to generate maps.
0
Web/GIS Server
Database Server
Server with 1 GB RAM, 120 GB hard drive,
and 1.0 GHz processor (~ $1,100)
0
SQL Server 2000 standard edition for single
processor (~ $6,000)
No Web/GIS server currenlty required. With
development of user-based GIS
capabilities, ArcGIS Server ($30,000 for
one server with 2 processors)* would be
required.
Server with 1 GB RAM, 120 GB hard drive,
and 1.0 GHz processor (~ $1,100)
*Used for interactive GIS system that is currently being developed
0
SQL Server 2000 standard edition for single
processor (~ $6,000)
Cold Fusion Server (~ $1,300)
-1
0
Server with 1 GB RAM, 120 GB hard drive,
and 1.0 GHz processor (~ $1,100)
22
Cost Estimate - Method
• Primarily based on input from FTS managers –
should be considered approximate.
• Cost estimate to include:
– Development hours
– Additional hardware costs
• Cost estimates most useful as an assessment of
relative costs to modify the FTS evaluated.
23
Cost Estimate - Summary
• To create a WRAP FTS with essential elements
and system characteristics, NM FTS can be most
efficiently transferred (580 hours).
• Similar effort required to modify any of the three
FTS to include preferred elements and system
characteristics (1300 – 1340 hours).
• Similar effort required to modify any of the three
FTS to build WRAP FTS with all bells & whistles
(1400 – 1500 hours).
24
Table 3 - FTS Modifications and Resources
(E)ssential
(P)referred
or (O)ptional
E
P
E
E
E
Modifications
Final design of database and
structure
Types of records to be included,
classes of users, editing
protocols, and burn approvals if
appropriate
Address system shortcomings:
permissions; user number;
automation; query limitations;
size limitations.
Add fields needed to meet WRAP
requirements
Web interface modifications to
enhance ease of use
Add features to compute
emissions
Develop approach
New Mexico
Level of Effort
(hours)*
Montana/Idaho
Level of Effort
(hours)*
USDA
Level of Effort
(hours)*
60
80
80
Assessment/Notes
SQL Server database requires more work
than Access database
120
0
0
NM Access database could be upgraded to
SQL Server database. MT/ID and USDA
already use SQL Server.
80
100
80
40
40
40
40
40
40
40
60
60
MT/ID is missing more required fields than
NM or USDA.
All require slight changes.
Options:
E
O
A. WRAP Phase II/III
emission inventory
Develop queries to
compute emissions by
using look-up tables of
emission factors, acreage,
and tonnage
B. Inter RPO (FEPS)
Develop queries to
compute emissions by
using fuel specific
emission and
consumption factors and
fuel moisture options
NM already has some of the query structure
in place.
60
80
80
NM already has some of the query structure
in place.
C. Link to CONSUME
O
O
O
1) Identify CONSUME
inputs that can be pulled
from the database
80
80
80
2) Create fields in the
database to hold
CONSUME output
3) Develop Visual .NET
application to control
CONSUME
20
20
20
Note "a" for USDA: USDA is currently
developing a link between their FTS and
CONSUME.
100
100
100
Note "a" for USDA: USDA is currently
developing a link between their FTS and
CONSUME.
Note "a" for USDA: USDA is currently
developing a link between their FTS and
CONSUME.
25
Table 3 - FTS Modifications and Resources
(E)ssential
(P)referred
or (O)ptional
New Mexico
Level of Effort
(hours)*
Montana/Idaho
Level of Effort
(hours)*
USDA
Level of Effort
(hours)*
Develop approach
40
40
40
Create menu of ERT's and
associated emission reduction
credits
Develop queries to compute ERT
impacts
GIS
20
20
20
40
40
40
Predetermined maps
20
80
80
Interactive system
600
600
600
E
Regional coordination features &
methods
Assess current protocols
40
40
40
40
60
60
E
Modifications to accommodate
import from different federal and
state systems
Modifications
Assessment/Notes
ERT
E
E
E
E
P
E
E
Add export feature to interface
20
20
20
Assign different levels of user
permissions
Support for Annual Emission
Goals
Develop queries to report
number of times ERT’s are
used
Total Level of Effort (hours)
20
20
20
20
20
20
1,560
1,620
1,600
E
E
Note "c" for MT/ID & USDA: No hours may
need to be expended since interactive GIS
system is currently being developed.
Less effort required to modify Access
database than SQL Server database.
Export data to modeling and/or
projection system
Assess input requirements of
federal or state system such as
EDMS, WFMI, FACTS, or
TEISS
Create queries to output data in
NIF or flat file format
E
Note "b" for NM: New Mexico FTS already
displays some predetermined maps of burn
locations.
40
40
40
20
40
40
Queries in NM Access database are easier
to create than in the MT/ID and USDA SQL
Server databases.
*Level of effort does not include estimate for workplan development. We estimate that 160 labor hours would be required for workplan development.
Essential:
580
740
720
Preferred:
720
600
600
Optional:
60/200
80/200
80/200
26
Recommendations - Method
• Extended the Technical Modifications
assessment to Post-Modification period.
– By dedicating a estimated amount of labor, how
would each FTS perform as the WRAP’s FTS?
– Tabulated this assessment and used results to
inform the Project Team’s recommendations.
27
sen
tial
Mo
dific
Afte
atio
ns
r Pr
efe
rred
Mo
dific
atio
ns
r Es
sen
tial
Mo
dific
Afte
atio
ns
r Pr
efe
rred
Mo
dific
atio
ns
As Is
r Es
Afte
New Mexico
Afte
sen
tial
Mo
dific
Afte
atio
ns
r Pr
efe
rred
Mo
dific
atio
ns
As Is
r Es
Afte
As Is
Table 4 - FTS Post Modification
Analysis
MT/ID
USDA
WRAP FTS Requirements
What required fields are missing?
0
1
1
0
1
1
0
1
1
Is the system web-based?
0
1
2
0
1
2
0
1
2
Can the system perform emissions
calculations?
1
2
2
0
2
2
0
2
2
Is there ERT support?
0
1
1
0
1
1
0
1
1
Is there a GIS capability?
0
1
2
0
1
2
0
1
2
Is there multi-day burn support?
Is there support for Importing from or
exporting to other systems?
Is there ad-hoc query support?
Is there an ability to assign different user
permissions?
1
1
1
0
1
1
0
1
1
0
1
1
0
1
1
0
1
1
0
1
1
0
1
1
0
1
1
0
1
1
1
1
1
1
1
1
Is there Annual Emission Goal support?
0
1
1
0
1
1
0
1
1
28
l Mo
dific
Afte
atio
ns
r Pr
efe
rred
Mo
dific
atio
ns
sen
tia
l Mo
dific
Afte
atio
ns
r Pr
efe
rred
Mo
dific
atio
ns
As Is
Afte
r Es
New Mexico
Afte
r Es
As Is
sen
tia
l Mo
dific
atio
ns
ed
Mo
dific
atio
ns
Afte
r Pr
efe
rr
sen
tia
Afte
r Es
As Is
Table 4 - FTS Post Modification
Analysis
MT/ID
USDA
FTS System Characteristics and
Requirements
Ease of use of web interface
1
1
2
0
1
2
-1
-1
2
Permission
0
1
1
1
1
1
1
1
1
Users
-1
-1
1
1
1
1
1
1
1
Automatic Scheduled Jobs
0
0
1
1
1
1
1
1
1
Robust Queries
-1
0
1
1
1
1
1
1
1
System Storage Capacities
-1
0
1
1
1
1
1
1
1
Database Record Limits
0
0
1
1
1
1
1
1
1
1
1
1
-1
-1
-1
-1
-1
-1
1
0
0
1
0
0
1
0
0
0
-1
0
0
-1
0
0
-1
0
0
0
0
0
0
0
0
0
0
System Characteristics
Ease of Use of System
Hardware and software requirements
Software
Web/GIS Server
Database Server
29
dific
atio
ns
Afte
r Pr
efe
rred
ial M
o
Afte
r Es
sen
t
MT/ID
Mo
dific
atio
n
s
atio
ns
AsIs
dific
Afte
r Pr
efe
rred
ial M
o
sen
t
Afte
r Es
AsIs
New Mexico
Mo
dific
atio
n
s
atio
ns
Mo
dific
s
atio
n
dific
Afte
r Pr
efe
rred
ial M
o
sen
t
Afte
r Es
AsIs
Table 4 - FTS Post Modification
Analysis
USDA
Total Points:
2
14
23
5
16
19
5
15
20
System Points:
0
3
10
4
5
6
4
4
7
Elements Points:
2
11
13
1
11
13
1
11
13
580
720
740
600
720
600
Estimated Cost (not incl. maintenance:
$ 60,000
$ 72,000
$ 78,000
$ 60,000
Total Estimated Costs for Essential and
Preferred Modifications
$130,000 - $140,000
$140,000 - $170,000
$138,000 - $150,000
Total Estimated Costs Including Optional
Modifications:
$135,000 - $160,000
$150,000 - $190,000
$145,000 - $170,000
Estimated Hours:
$80,000 $ 60,000
$110,000
30
Table 4 - FTS Post Modification
Analysis
Assessment/Notes/Comments
Total Points:
System Points:
Elements Points:
NM scores highest with Essential and Preferred modifications. If all Optional
Modifications are executed, scores for FTS are assumed to be equal to
scores for "Preferred Modifications." All FTS would have enhanced emission
calculation capabilities.
With Preferred modifications ($60k), NM FTS achieves near maximum
system points. MT/ID and USDA have more system functionality "out-of-thebox" but more difficult (and expensive) to tailor to WRAP's system
specifications. Some system improvements being worked on by MT/ID and
USDA hosts.
With Essential modifications, all systems have required WRAP elements.
With Preferred modifications, a couple of elements get enhanced
functionality.
Estimated Hours:
Estimated Cost (not incl. maintenance:
Total Estimated Costs for Essential and
Preferred Modifications
Total Estimated Costs Including Optional
Modifications:
The effort to implementing Essenstial, Preferred, and Optional modifications
is expected to be essentially the same for all FTS. Some FTS development
is underway for MT/ID and USDA (timing of completion is uncertain and
results of development are untested). Successful development could reduce
resources necessary to modify MT/ID and USDA.
31
Recommendations
• What existing FTS would work best “as-is”
for the WRAP’s FTS?
– MT/ID FTS
• The MT/ID FTS is a currently functioning system
that supports burn managers in the states of Montana
and Idaho.
• The system uses an SQL Server database that can
meet the needs of the WRAP region, and the user
interface is fully functional.
32
Recommendations
• What existing FTS would require the least amount of
modification to work well as the WRAP FTS?
– NM FTS
– By upgrading the Access database to SQL Server, the New Mexico
FTS becomes a system capable of meeting current and future
WRAP needs. The Project Team has estimated that 120 labor
hours would be required to do this upgrade.
– NM FTS already supports limited emissions estimation (PM10),
and it generates maps of burn locations. These features are not
supported in the existing versions of the MT/ID and USDA
systems, and would require approximately 140 labor hours to fully
implement in the NM FTS.
33
Recommendations
• What combination of existing FTS, technical
modifications, and exceptional features from other FTS
would comprise a WRAP FTS with the most complete set
of features and capabilities?
– Modified version of the MT/ID FTS (assuming the current
manager proceeds with the planned interactive GIS upgrade).
– The MT/ID FTS has the advantage over using the New Mexico
FTS because it already uses an SQL Server database.
– The Project Team preferred the MT/ID FTS over the USDA FTS
because the preferred interactive GIS system is already being
designed for the MT/ID FTS, and the USDA FTS is not yet in
production mode.
34
Recommendations
• Rather than starting from an existing FTS, is there a better
way for the WRAP to proceed with building the WRAP
FTS?
– The *easy* answer is NO. Starting with one of the three FTS
evaluated in this report could be a cost effective and efficient way
of building the WRAP FTS.
– Each of the FTS already incorporates many of the essential
features, and two of the systems are currently being modified to
include the preferred GIS feature.
– The labor (time and money) that has been dedicated to build the
essential elements and basic functionality of these FTS could be
considered a down-payment on building the WRAP’s FTS.
35
Recommendations
• Rather than starting from an existing FTS, is there a better
way for the WRAP to proceed with building the WRAP
FTS?
– But…there are always other ways to build an equal or better
mousetrap. Rely on NM/FEJF specifications on a super-industrial
system and use programming to make it look slick &
contemporary.
•
•
•
•
•
Make an existing “Commodity” FTS (not so stand-alone, proprietary)
Upgrade NM to be *industrial strength* database
Host on existing e-commerce site (e.g., Yahoo!)
Multi-users accommodated on a Web interface
Export events to Google Earth for review and regional coordination
– To be dicussed during the FTS Task Team break out session.
36
Next Steps
• Finalize Draft Report
• Post for review by task team.
• Incorporate comments and post Final
Report.
• FTS Task Team prepares a plan to move
forward with building and implementing the
WRAP FTS.
37