AAIR Project No PL 94-2392
- introduce users to the concepts of abiotic risk assessment
and the quantification of risk through use of the models
- show users examples where models have been used for risk
assessment in order to help users to understand what the
models can do. They should be introduced to the
input data (area of interest for which damage will be
assessed), the output from the models, and the way in
which this can be used as decision support for managing
forests agains risk (silvicultural strategies).
This demonstration should be clear, interactive and a show-piece which gives an idea of the importance and value of our work and encourages the user to move further down the tree to access the tools (models and methods) and ideas that we have developed and get some feel for the issues.
In the interests of elegance and in order not to confuse the user it seems appropriate that this demonstration should use only one suite of models (ie one tree/site/climate model, or model group) for each damage type. It is best to incorporate contributions from all groups, and to try not to burden any single group with all the work. For example we could select a dataset for a site and calculate the risk of each damage type by changing the climatic conditions to different parts of Europe (semi-artificial data). We might take a Portuguese data set, for which CNIG have already calculated a fuel hazard map, and use this for fire, then imagine this dataset is in the UK and do damage risk calculations using Heli's model and the NRS wind climate model, then imagine it is in Sweden and use Erik's combined damage model. Alternatively it may be much easier to calculate the risk of each kind of damage for different sites. For example we use the NRS barry-tree-damage and windflow/UK wind climate models for a place in the UK, for wind; the CNIG-unmixing(-windflow-fire spread?) method for fuel hazard mapping in Portugal for fire; and something similar for snow. This may make the demonstration longer because each site would require a different introduction, but would probably be less effort if we become short of time.
After the user has been through the demo, they will then (hopefully) want to know more about the models on offer and how they might apply them to their area to support their management of damage. To lead them to a particular model or suite of models, and give them further insights into model use. In order to avoid overwhelming them with all the models at one time, the following "tree" access structure is proposed to facilitate access to individual models. I think this approach would seem most logical to the user.
LEVEL 1 (TOP)
Firstly they are asked what damage type they think they are interested in.
WIND SNOW FIRE
Having selected one of these damage types we present them with the option of viewing a list of silvicultural advice which we would recommend for reducing the risk of this particular sort of damage. At this point we tell them that this advice should be applied to high risk areas which can be identified and the risk quantified using our models.
BEST CURRENT SILVICULTURAL ADVICE
LEVEL 2 Whether or not they select this option, we ask them if they are interested in RISK (vulnerability - output from damage models) or HAZARD (probability - the possibility of damage occurring given knowledge, from climate models, of the likelihood of these critical factors occurring).
RISK or HAZARD
LEVEL 3
RISK
If they select risk then they are presented with the probability generating
groups of component models (e.g. NRS's treesnap-windflow-wind-climate model
suite, or Erik's all-in-one-probability generating model). It may be necessary
at this point to ask where the user is, as this will determine whether climate
models are available for calculating risk, and if not they are informed that
they require their own climate model in conjunction with the damage models in
order to calculate risk.
HAZARD
If they choose hazard then they are presented with the damage models
appropriate to the damage type (SNOW WIND or FIRE) which they have previously
selected. (this would be CNIG's method, Barry's model or Heli's model).
N.B. A model may appear more than once in the different damage types (ie Heli, Barry and Erik's models will appear under wind and snow options). Also I have included Erik's model in the "HAZARD" category of models, but I think it should probably only be in the "RISK" section??
MODEL/MODEL GROUP
LEVEL 4 At this point we want to present a clear, comprehensive summary of what is required for the user to run the model, what the scope of the model is, what the input data is and what sorts of scales/accuracies/tolerances are recommended as input data. At this point the user may have a choice of more than one model, and so it might be useful to have a summary to help them choose the appropriate model - this might be through location, through tree species, through soil type or something like this (these questions could be asked with the location question at the RISK/HAZARD choice stage).
INPUT DATA: Somehow we want to present the input data (so that they can decide whether they have the appropriate information) and give an idea of the scope/limitations of the model. I feel it would also be appropriate to put some of our error experimental work in here too to indicate the consequences of putting in poor data - but to do this from an "experience" point of view. So, for example, thinking about the windflow model. David is planning to send NRS different sampling resolutions of the Cwm Berwyn test site data. Thus there might be a "recommended tolerances" button beside this INPUT data which takes the user to output maps to see how different the results might be if an inappropriate scale is applied to a particular model. At the same time we want to indicate whether a model is sensitive to an input parameter, and exactly what "sensitive" means - ie that data must be supplied which is within a 10% error band. More demonstrations on the "recommended tolerances" might encourage the user to consider the tolerances of the models in a different context. For example, in a low relief terrain (e.g. parts of Cwm Berwyn) low resolution data might still give sensible results, but in a high relief area like Cowall, the consequences of using the same low resolution data would be much more detrimental and in those circumstances it would be important to use higher resolution information.
There might also be a button beside the input data for access to the metadata forms, to give users an idea of what datasets exist which are appropriate to the models (e.g. Swedish or Finnish or UK or Portuguese forest inventories).
SCOPE/LIMITATIONS: The scope and limitations of the model (e.g. that Erik's model is only proven for Sweden and for Scot's pine) and use outwith these limits could not be guaranteed (or even, has been proven to give invalid results).
OUTPUT DATA: The output of the models should also be defined (and (perhaps) some of the test results should be displayed to give an idea that the results are helpful but not necessarily "the answer"? although the tolerances of the input data may demonstrate this idea well enough anyway).
OTHER INFORMATION: Finally the contact addresses and procedures for those who would like to pursue risk assessment and use the models should then be prominantly displayed. A feedback form should also be available so that users can suggest how the pages can be improved (and we get an idea of who, and how many people, are accessing them).
Once the details of this interface have been agreed with changes according to views expressed at the Umea meeting, I think we should decide (in Umea) on a plan of action for the next 6 months.
The aim would be to have a skeletal prototype running by the March Meeting in 1997. The pages and buttons and routes can be set up with minimal information. Thus the structure can be available so that people can slot in their models when they are ready to go into the interface. At the March Meeting we can have an interface workshop to decide how to change the structure if necessary, and how to word the introductions and the various links, how to display the different aspects etc. However I think I do need a minimum of information to properly construct the pages and demonstrate them. Thus I probably need SOMETHING for each of the levels, and a timetable for people to produce these things for me. Again, it should be organised so that the load is spread as evenly as possible so as not to disrupt people's research timetables. If we could agree the timetable and these deadlines in Umea I think that would be best. It is harder to implement these things afterwards when we are spread around Europe!
Also, I see the "Brussels Demonstrator" now evolving into the Web Interface Demonstrator. There is a real difficulty with people fitting the demonstrator into their timetable, so extending it (as I previously suggested) would perhaps not work. Therefore we need to redefine the exchanges, but not increase them. Obviously more exchanges may be necessary to include the climate models, but some of this will be limited if we decide to only use, for example, Heli's model on Finnish data. Unfortunately the difficulties of data suitability in different countries will not then be explored in a practical sense, but some comment can be made from the few interactions that might occur (or be tried).
| Administration | Data | FTP site (MLURI) |
| Description | Objective | Participants | Photo Gallery | WWW Resources | PROJECT home page |
Last modified: Mon Oct 14 16:00:22 BST 1996