Reserve Selection Algorithms

There are many potential pathways for linking GIS with spatial decision support systems for this kind of application. One could process entirely through a commercial GIS, which have some location/allocation tools built in. Other applications may only involve an SDSS with no need for GIS functions except those already provided. Another pathway is where the GIS contains ready-made datasets and passes them to the SDSS for processing. Most common, perhaps, is where the GIS acts a bridge, passing spatial data to the SDSS which does the allocation, and then passes the results back to the GIS for display and further evaluation. There are also many degrees of linkage between the GIS and SDSS, from completely separate with data shared only by exporting and importing in ASCII format, to fully integrated where one system transparently calls the other. In our case, the task was to develop a research tool for exploring alternative reserve systems, and not initially to package an operational linked system. Therefore, our approaches have primarily followed the bridging pathway.

The initial version of the MCLP model to select reserves had a very loose integration of the GIS database with the optimization modeling environment. The procedure required exporting GIS data, electronically transferring them to another local network where the model resided, transferring the model report and reformatting it into GIS-compatible form for display and further analysis. Programming the model directly into the GIS environment was one approach we undertook to improve this integration of spatial optimization tools with mapping and database tools. All functions are accessed through a menu-driven interface (Figure 23), which gives users choices in the number of reserves to be selected, weighting for species, and algorithm for selecting sites. The main advantage is that users of public domain data, such as the GAP databases) can conduct their own explorations of possible reserve systems without having to acquire and master packages and reformat model output data.

Similarly, when the BMAS model was originally developed, the emphasis was on programming a new model rather than integration with the GIS. The heuristic itself continued to evolve. Also the number of alternatives being considered was not so great that a polished interface was required. When the planning project for The Nature Conservancy began, however, the model had developed enough that it was worth improving the interface to the GIS database for both generating input data to the model (which had a large number of parameters to be selected by the analyst) and converting the model report into displayable spatial data. The user interface (Figure 24) allows the user to select definitions of existing protection, the scope of the planning problem, biodiversity elements to be represented, representation targets, and weights on suitability factors. These parameters are written to a text file as documentation of the parameters used for each alternative run. A Perl script was also written to compile all the GIS summary data about each potential site selected. These data are normally in many different database and text files and hard for planners to access quickly without knowing where all data are stored. The program rapidly compiles these diverse bits of data into a single formatted report, which describes the conservation values the site contains.

Figure 24. Graphical interface for selecting BMAS modeling parameters for GIS pre-processing.

IBM-ERP Project Home Page

Biogeography Lab Home Page