Latest features of the ecosystem management decision support system, version 8.0

The Ecosystem Management Decision Support (EMDS) system is a spatially enabled system for environmental analysis and strategic and tactical planning. EMDS combines various sophisticated analytical tools within a GIS environment. Originally released by the Pacific Northwest Research Station, USDA in 1997, EMDS has been maintained and actively extended since then. Building on its core functionality of logic processing and decision modeling and availability as an ArcMap component, recent advances include more advanced geodatabase processing, integration with open-source GIS platforms, incorporation of two new analytical engines, support for scripting tools, implementation of a graphical workflow environment, advanced tactical planning, portfolio management, and a cloud-based collaboration manager. Because EMDS is a generic solution framework, it can be applied to an extremely broad array of problems at virtually any and all spatial scales. This paper presents an overview of the EMDS technology and describes some of the projects in which it has been used.

1 Introduction

The Ecosystem Management Decision Support (EMDS) system is a state-of-the-art modeling framework for spatial decision support of environmental analysis and planning at multiple geographic scales (Reynolds et al., 2014). The system integrates state-of-the-art geographic information system (GIS) as well as logic-based reasoning and a variety of decision modeling technologies to provide explicit, practical decision support for strategic and tactical planning as well as adaptive management. Because EMDS is a generic solution framework, it can be applied to an extremely broad array of problems at virtually any and all spatial scales. See, for example, EMDS on Wikipedia (2023) for some idea of the breadth of decision support solutions provided by EMDS up to recent times.

2 A brief history

Development of the system was initiated by the senior author in 1994, and versions 1 to 3 were developed under contract with the Environmental Systems Research Institute¹ (ESRI, Redlands, CA) between 1995 and 2002. The Redlands Institute at the University of Redlands (Redlands, CA) assumed stewardship of EMDS between 2005 and 2014 under a memorandum of understanding between the University and U.S. Department of Agriculture Forest Service (US Forest Service). In this timeframe, minor advances in EMDS were made incrementally through a series of updates in version 4, and the EMDS Consortium was organized as a development partnership between the US Forest Service, the University of Redlands, and two software companies that contributed the core analytical technologies behind EMDS versions 1 to 3. With the closure of the Redlands Institute in 2014, stewardship of the system reverted to the US Forest Service, and a new development contract was issued to Mountain View Business Group to continue development. This paper first summarizes system advances up through version 5, and then addresses a significant number of major enhancements to EMDS since version 6. We provide a concise summary of the evolution of EMDS through the current version 8 in terms of system enhancements introduced at each major release (Table 1). Processing benchmarks for basic steps in a version 8.7 project are provided (Supplementary Material).

TABLE 1

TABLE 1. Major releases of the Ecosystem Management Decision Support system and their associated feature enhancements by year and version.

3 Overview of EMDS system architecture

EMDS implements a four-tiered architecture (Figure 1). With EMDS 8, we have finalized our transition to a four-tier architecture, where the first tier is the individual clients, and the other three layers support a common architecture that can be deployed on a single desktop, a web server, or into a cloud environment. The desktop client will interface the EMDS services architecture through a dedicated EMDS Desktop Services API using named pipes to communicate between the client and server. For all web clients, we will be using REST calls and web sockets to communicate to the EMDS Server Services API. In both cases, they will then access the EMDS Management API Services, which is the public-facing API to access the services in the rest of the architecture. This will receive and parse all requests and then forward them to the appropriate engine or service to complete the request. From the Management and Services API level, for all management activities will be routed to the EMDS Administration engine, while all processing and analysis will be routed to the appropriate processing engines. The physical database is abstracted to allow for PostgreSQL, SQL Server, SQLite, and Oracle databases to be selected as appropriate for the implementation. The desktop implementation currently defaults to SQLite, and the web and mobile clients defaults to PostgreSQL. Changing implementation of the database amounts to simply changing the secure connection string, and adding engines to this platform is as simple as adding the container definition, registering it with the management service, and specifying the API request calls the engine will utilize.

FIGURE 1

FIGURE 1. Architectural diagram of the Ecosystem Management Decision Support system. User interfaces are customized for Microsoft Windows, MacOS, and Azure and Amazon Web Services as well as for ArcGIS, and QGIS. However, all variants of the interface share a common back-end architecture.

4 Major applications of EMDS

Since 2000, EMDS has been an important tool for the US Forest Service (USFS) and its partners, providing a unique form of spatial decision support for environmental analysis and planning that is not replicated by any other decision support technology. The system has been employed in several major USFS applications, most prominently for national forest fuels management for USFS and the Department of Interior agencies, and more recently as the platform for the Terrestrial Condition Assessment (Cleland et al., 2017). Major EMDS applications in the past 20 years have included.

• Roads analysis for wildlife habitat, Tahoe National Forest (Girvetz and Shilling, 2003).

• Aquatic/Riparian Effectiveness Monitoring Program, US Forest Service Region 6 (Gallo et al., 2005).

• Wildland fuels, US Forest Service Washington Office and Regions, and US Department of the Interior (Reynolds et al., 2009).

• Soil impacts associated with logging and wildfire, Okanogan-Wenatchee National Forest (Reynolds et al., 2011).

• Integrated restoration and protection, Okanogan-Wenatchee National Forest (Hessburg et al., 2013).

• Integrated resource restoration and protection strategy (IRPS), US Forest Service Region 1 (Bourgeron et al., 2014).

• National Terrestrial Condition Assessment, US Forest Service Washington Office (Cleland et al., 2017).

• Resilience of forest ecosystems in the Lake Tahoe Basin in the 21st century (Abelson et al., 2022).

• Managing critical loads associated with atmospheric sulfur deposition in the southern Appalachians, US EPA, with direct benefits to US Forest Service Region 8 (Reynolds et al., 2023).

Among the above examples, the Terrestrial Condition Assessment (TCA) is perhaps the most significant EMDS application in the past 5 years, so here we provide some further background on TCA. TCA, whose development began in 2012, has been used to logically evaluate the state of forest and range ecosystem integrity on National Forest System (NFS) lands of the USDA Forest Service since 2018. TCA is currently maintained through the Forest Management, Range Management, and Vegetation Ecology Staff of the USDA Forest Service Washington Office. An interdisciplinary team of NFS and R&D staff maintains the TCA model and data for NFS in collaboration with the Geospatial Technology and Applications Center (GTAC) of the agency. Landscape units evaluated in TCA are either landtype associations (LTAs) from the agency’s National Hierarchical Framework of Ecological Units (Cleland et al., 2017) when available in a Region, or generalizations of LandFire biophysical settings (LandFire, 2023) when LTAs are not available. Primary national data sources include observed insect and pathogen-induced mortality, key critical loads for soil and the atmosphere, long term seasonal departures in temperature and precipitation, road densities, uncharacteristic wildfires, historical fire regime departure, wildfire potential, insect and pathogen risk, and vegetation departure from natural range of variability. Beginning in 2020, the TCA team began providing annual reports to the Strategic Planning, Budget, and Accountability Staff of the Forest Service Washington Office, and subsequently to the U.S. Congress, on agency performance with respect to improving or maintaining forest and range ecosystem integrity. To evaluate performance in a given year, the TCA model is first run by GTAC to generate a baseline assessment of conditions, then the data inputs to TCA are updated by GTAC with management activities that National Forests and Regions report to the Forest Service Activity Tracking System (FACTS) database application for the current year, and the TCA model is rerun. The annual reports summarize the difference between outcomes modeled with the two datasets as percent of landscape units maintained or improved.

5 Foundational technologies at version 6

5.1 Logic processing

The logic modeling component in EMDS, NetWeaver Developer from Rules of Thumb, Inc. (New Smyrna Beach, FL), evaluates data against a logic model that provides a formal specification for interpreting data and synthesizing information. The model can be thought of as a type of meta database. The logic engine allows partial evaluations of ecosystem states and processes based on available information, making it ideal for use in the context of landscape evaluation, in which data are often incomplete. The logic processor readily supports design of logic specifications for the types of large, complex, and abstract problems typically posed by contemporary environmental management. For the latter complex problem types, logic models are commonly used as pre-processors to distill down high dimensional or highly nonlinear information for improved use in decision models (see next section). With the high level of public interest in natural resource management, black box solutions are a political liability. However, the logic processor displays the evaluated state of a logic model in a highly intuitive interface, which is sufficiently intuitive that the system can be used as a powerful communication tool, effectively explaining results to broad audiences.

5.2 Multi-criteria decision analysis

The multi-criteria decision analysis (MCDA) component, Criterium DecisionPlus from InfoHarvest, Inc. (Seattle, WA), assists users with developing strategic and tactical priorities for management activities in landscape elements of the assessment area. In simpler applications, strategic decision models may be used in EMDS standalone, but for larger, more complex or abstract, problems, MCDA models more often operate on results of a landscape evaluation performed by the logic processor as discussed in the previous subsection. Whereas the logic processor addresses questions about the current state of the assessment area, the MCDA component addresses questions about which management units are the highest priority for management actions (strategic planning) or which activities are the highest priority, given the specific context of a management unit.

For the more complex applications that require a combination of assessment and planning, maintaining the distinction between the two phases is important because the management units in poorest condition are not necessarily also the best candidates for management activities such as restoration, for example,. In the strategic context, the MCDA component rates management units not only with respect to their condition, but also with respect to logistical factors important to resource managers, such as the feasibility, efficacy, or social acceptability of management choices. In Sections 8.1 and 8.2, we discuss the latest tactical features.

5.3 Core extensions

With version 6, the system was extended to use SQL Server as the default database engine, with additional support for SQL Server LocalDB, file geodatabases, and Oracle as alternatives. All the geoprocessing code and execution was refactored to take advantage of the stabilized geoprocessing engine exposed by ArcGIS 10.3. For each of the engines, the processing aspects were separated from the UI, to allow for better performance speed gains. Python scripting was exposed as well as running ArcGIS toolbox commands to allow for better integration and extension of ArcGIS and its environment.

5.4 Workflows

The architecture of EMDS also was extensively re-engineered at version 5.0 to support the concept of workflows, by which any of the EMDS analytical components described above and subsequently can be invoked in any sequence(s) (or series of sequences) needed to support spatial analysis and planning. EMDS supported Microsoft Windows Workflow for creating, running, and monitoring scientific workflows and Workflow.NET, with later plans to support the importing and exporting workflows from Kepler and Taverna.

6 New features in EMDS 8.0

6.1 New open-source GIS platforms

Prior to version 6, EMDS was only available as a component of ESRI’s ArcMap desktop application. However, starting with version 8, EMDS runs as a component of the open-source GIS systems, QGIS, and DotSpatial. Versions for QGIS run on Microsoft Windows platforms (Windows 7 and later), whereas DotSpatial is a project that was originally based upon the same codebase as MapWindow that runs in Windows as well as the Linux and Mac operating systems.

6.2 Geodatabase enhancements

With EMDS 8, we added support for multiple GIS environments including web services for EMDS. This meant we needed to re-architect the geodatabase backend. The goal for the new backend was to run the server and database across multiple platforms, collect more detailed provenance information, and handle rasters as first-class citizens within EMDS. SQLite with SpatiaLite is the new backend data repository, allowing the database engine to run on Windows, Linux, or MacOS. This adaptation led us to be able to support databases above 1 GB in size and allowed a 70% increase in speed in project creation as well as approximately a 24% increase in the processing of most geoprocessing tools.

Raster data supports file geodatabases, geotiffs, and NetCDFv5 data formats, with a link to that file type stored in the appropriate project’s metadata tables. EMDS on ArcGIS Desktop limits the raster dataset to under 8,000 × 8,000 cells, because ESRI’s geoprocessing tools inside ArcMap have difficulty dealing with larger raster cell files. In contrast, ArcGIS Pro, QGIS and DotSpatial all use 64-bit libraries that enable EMD to work with raster files any size, as long as it fits the available system memory.

Longer database names are now allowed as well as longer table names, increasing the EMDS 6 level of 30 characters to 64 characters long in ESRI environments, and up to 256 characters in the open source/QGIS environment. Within ESRI environments, field names are limited to 32 characters, while with non-ESRI environments, we are able to have field names up to 160 characters long. Project metadata information is stored within the main SQLite database and allows for synchronizing information between ArcGIS’s map document format and QGIS’s map format.

6.3 New analytical tools

NetWeaver and Criterium DecisionPlus have been the mainstays of EMDS for support of strategic analysis since 2002 (version 3). Two new additions to the set of EMDS analysis tools, beginning at version 7, are GeNIe and VisiRule, which add support for tactical planning.²

6.3.1 Bayesian networks with GeNIe

EMDS now implements support for graphical probabilistic models, such as Bayesian networks, dynamic Bayesian networks, influence diagrams, and structural equation models, built with the GeNIe application for probability-based reasoning from BayesFusion, LLC (Pittsburgh, PA). GeNIe allows for learning models from data, constructing them from expert knowledge, or a combination of the two. Its unique feature is that it allows for a hybrid framework, in which models contain both discrete and continuous variables, equations, and continuous probability distributions. Bayes networks and influence diagrams have been particularly popular among wildlife biologists for decision making related to wildlife habitat suitability and population viability (Marcot, 2017).

6.3.2 Decision trees with VisiRule

EMDS also now includes support for VisiRule charts, Flex expert system rules and Prolog inferencing from Logic Programming Associates (LPA), Ltd. (United Kingdom). These capabilities are particularly useful to model and resolve tactical planning decisions. VisiRule can help identify the optimal management actions in specific management units, given the state of the unit, and managers’ and scientists’ understanding of the effectiveness of potential management actions in specific contexts. In addition, VisiRule can import and exploit classification trees from popular machine learning packages such as KNIME and RapidMiner. Flex/KSL provides a powerful rules-based language and Prolog inferencing, with its built-in support for recursion and backtracking, and brings various powerful capabilities such as list processing and structure traversal.

7 Interoperability of the EMDS analytical engines

We present a hypothetical example demonstrating the interoperability of the four analytical engines and scripting tools to evaluate ecosystem integrity and recommend strategic and tactical management actions in response. It was necessary to present a hypothetical case because there are currently no existing applications that fully demonstrate the interoperability of all the components. The following is an example of a workflow sequence that illustrates how the four analytical engines can collaborate to support a larger, more complex decision support project for ecosystem restoration (Figure 2).

a. Bayesian networks, created by the user through the GeNIe interface and processed by its analytical engine, are used to assess population viability of a few to several keystone species.

b. The Bayesian outputs are integrated into the biodiversity component of a NetWeaver logic model that evaluates the broader question of ecosystem integrity.

c. NetWeaver outputs (and additional external logistical considerations) are passed to a strategic CDP model that prioritizes landscape elements for restoration activities.

d. Finally, VisiRule could be invoked to recommend optimal tactical management actions in high priority landscape elements.

FIGURE 2

FIGURE 2. A hypothetical workflow sequence that invokes the four EMDS analytical engines to support decisions on ecosystem restoration opportunities. The scripting tools provide for summarization and transformation of model outputs to expedite sharing of information among the engines.

In this example, the initial Bayesian outputs flow through steps a to d, influencing the logic evaluation, and strategic and tactical decisions for ecosystem restoration. The interoperability illustrated is facilitated in EMDS because each of the four analytical engines write to the same output table, so new information at each step accumulates for use in subsequent steps.

8 New tools for geoprocessing, statistics, and reporting

To further extend interoperability of its analytical tools in the workflow environment (Section 8.4), EMDS now also implements Java script, R, and Python languages as tools for spatial data transformation, statistical analysis, and reporting.

8.1 Support for local (feature oriented) planning

From EMDS v3 to v7, when a CDP model was applied as a task to be performed in an EMDS workflow, it treated all landscape features in the target layer as spatial alternatives, and quantitatively ranked them against each other (see the section Multi-criteria Decision Analysis above). We have referred to these as strategic models in earlier applications. However, another new application of MCDA in spatial decision support introduced in version 8 can now apply an MCDA model separately to each landscape feature (e.g., a local, or feature-oriented, MCDA model). If there are a finite set of options that are applicable to each feature in the target layer, such a local MCDA model can determine which of those options is the most suitable alternative.

In EMDS v8, we distinguish two variants of the local MCDA model, one of which represents a strategic perspective, while the other represents a tactical one. Here, we use the terms, strategic and tactical in the classical sense of these terms to refer to broad goals or objectives versus more specific actions, respectively. At a tactical level, if a previous MCDA model was applied to prioritize on which features work should be done (e.g., high priority areas for fire resilience work), a local MCDA model can be applied subsequently to identify, for those high priority areas, the most suitable treatment alternatives from a short list of options such as thinning, prescribed fire, cultural burning, managed wildfire, etc. This definition of tactical is consistent with the way in which we have previously discussed strategic versus tactical in a spatial decision support context (Reynolds et al., 2014). Alternatively, though, in the classical sense of strategic planning, a local MCDA approach can be applied to determine the most suitable management strategy from a set of options (e.g., support for productive, protective, conservation-oriented, social, or multifunctional strategies for managing lands for ecosystem services) for individual resource management areas.

In EMDS 8, the local MCDA Model for tactical decision support is launched using the “Tactical Actions” task. The Tactical Actions wizard steps the user through the process of assigning models to the data. The first step is leveraging a NetWeaver model to generate ratings for an appropriate list of options that will act as the input to the CDP MCDA model. The alternatives are action types (e.g., thinning, prescribed burns, etc.) and the NetWeaver model estimates the change in values of a set of indicators were each action type to be implemented on that feature. In the next step, the Tactical Action Wizard loads a CDP model whose alternatives are the action types, and whose lowest criteria are those indicators, and the ratings are fed in from the NetWeaver model. Weights capture how important the different indicators are in evaluating the overall state of the study area, and they are the same for every feature. EMDS then executes that CDP model on each feature and stores the top scoring Action Type so that map layers can be generated, showing which action types will generate the greatest change on each feature (Figure 3).

FIGURE 3

FIGURE 3. Example of a suitable CDP model for the Tactical Actions analysis.

Alternatively, the Local MCDA model for strategic decision support is launched by the “Classical MCDA Analysis” action under Action Tasks. Here the Net Weaver model estimates the evidence that different types of processes relevant to a strategic management approach occur on each feature. The CDP MCDA model for this case must have the alternatives applicable per landscape feature make up the primary decision criteria (nodes) in the model layer immediately below the Goal. The lowest criteria are the processes relevant to each strategic option. The weights indicate how well suited each strategy is in supporting the individual processes. The ratings values for a given feature are supplied by the NetWeaver model. When the local MCDA model is executed, ratings are loaded into the CDP model for each feature from attribute columns in the geodatabase, and contribution values of each alternative node provide an estimate of the suitability of that strategic alternative compared to the others for that feature. The custom utility built for this purpose in EMDS then extracts and stores the suitability score for all alternatives for each feature in the target layer. Results layers for the highest scoring alternative for each feature, the next highest score, etc., can be generated, as well as information about the weight that the highest scoring option is most sensitive to on each feature. A recent application of this new functionality is presented in a forthcoming publication, which, for each forest landscape unit identifies the most suitable management strategy for provision of ecosystem services.

8.2 Portfolio generation

A new capability added in 2021 to EMDS Desktop v8 is the ability to generate a portfolio of actions (projects). For many organizations, a set of projects will be approved together for financing, possibly by bond issues or annual programmatic funding allocations. With finite resources, managers and scientists often design and receive proposals for more actions than can be funded. A portfolio contains a subset of all possible proposed projects that meet a resource budget.

To run the Portfolio Generation tool, the user must provide a cost and benefit score for each individual project. The cost could be in US$ or other resources that implementing a project requires (e.g., people). Project costs and benefit estimates can be provided as attributes in a table of projects, but more often are generated using NetWeaver or Python models that estimate cost and benefit (and optionally a Priority score) based on attributes of the project. The user then specifies a budget limit that the summed costs of the projects in the portfolio cannot exceed and a strategy by which to add projects to the portfolio. For example, one strategy to decide which projects should be added to the portfolio might be to first add the one with the highest benefit-to-cost ratio, then the one with the next highest ratio is added, etc., always checking that the sum of costs does not exceed the budget. When the addition of any further project would exceed the budget, the portfolio assembly is complete. An alternative strategy could be one in which the order in which projects is added to the portfolio is based on a prioritization score model the user or a third party has developed.

The tool uses the Prolog engine from LPA (Section 6.3.2) to execute the strategy for a set of projects on the map. The project map layer can be point (e.g., fish passage barrier removal, line (e.g., riparian buffer projects) or polygons (e.g., areas for prescribed burns and mechanical thinning).

The EMDS Portfolio tool generates data layers showing which projects are included in the portfolio and which are not, and it generates charts showing cumulative benefits and cumulative cost for the generated portfolio (Figure 4). These charts and other information can be used to compare portfolios generated using different strategies and to identify how small increases in budgets could deliver large gains in benefit.

FIGURE 4

FIGURE 4. Portfolio analysis for Fish Passage Removal projects shows the 18 projects that were included in a $2 m budget (darker green bars) and the total amount of benefit they should in theory generate (purple line).

8.3 Using the EMDS workflow engine to generate multi-year portfolios

Portfolios are critical to moving from an abstract analysis of the benefits of individual projects to designing a fundable program of projects based on their collective benefits and costs. For many real-world applications (such as fish passage barrier removal, fire risk reduction, etc.), the sequencing in time and spatial relationships of projects enhance or diminish their benefits and impacts.

The workflow capability discussed above can be combined with the Portfolio Generation tool to generate multi-year portfolios in which one set of projects is added to the portfolio for implementation in Year 1 compliant with Year 1’s budget, then a new set added for Year 2 and its budget, and so on for a set number of years. The benefit and cost functions can take into account in what year the projects are implemented and how much cumulative benefit and cost they generate. This combination of Workflow and Portfolio Generation capabilities was used to develop a Portfolio Laboratory for the Tulalip Tribes to evaluate the effectiveness of different prioritization strategies for fish passage barrier removal projects in King County, WA (United States). Different prioritization strategies lead to portfolios of sequenced barrier removal projects in which larger areas of high-quality habitat become accessible to salmonoids sooner under some portfolios than others, even though annual budgets are the same for all the portfolios.

8.4 Workflows and EMDS

Before delving into the workflow goals and their implementation in EMDS, we need to define a few terms. The workflow processor and its associated systems will be referred to as the workflow environment. The smallest unit of work within a workflow environment is the activity. An activity may do something as simple as evaluate a condition to something as complex as a REST call to a geoprocessing task on an ArcGIS server. A series of one or more activities to perform a specific task or goal is called a workflow. A workflow can contain one or more activities and it can also contain a combination of activities and other workflows.

The workflow environment within EMDS has evolved to become the central processing mechanism which provides capabilities for a wide variety of users and use cases. With geoprocessing tools, such as ModelBuilder already within ArcMap, there is a question as to why another workflow environment is needed. Workflows built with ModelBuilder are Python scripts that focus only on automating repetitive geoprocessing tasks. Building workflows in this environment usually ignores other tasks such as calling external libraries or services to perform tasks, thus limiting it to a small subset of problems.

There is a tendency to look at workflows as a simple way to automate tasks. This formulation looks at workflows as a series of Input -> Process -> Output activities. This simple computing model leads to thinking of workflows as only being useful for tasks like geoprocessing and statistical analysis. The workflow engine and its environment, when limited to these boundaries, is truly only an automation tool.

With EMDS, however, our goals and intention for the workflow environment provides a richer set of services for end users across a wide range of levels. Our goal is to be open and support not only systems, services, and workflows that we develop, but to leverage the capabilities of other processing environments and workflow engines. First, our target audience for usage of EMDS and the workflow system consists of analysts and scientists. However, managers and the general public can review and experiment with different logic models on analysis and scenarios generated by the analysts and scientists as well as others.

To support such a range of users and levels of technical expertise, we needed the workflow environment to be able to.

• Visualize workflows in a GUI authoring tool

• Recognize that our system cannot handle all issues, and that the goal is to leverage workflow systems, external processing services, and other web services

• Schedule tasks and support runtime needs of tasks

• Handle long-running tasks, including hybrid human-machine workflows

• Provide access control for activities, data, and users

• Expose provenance information to allow for activity and information transparency, and for the generation of scenarios, and

• Dynamically generate workflows

A key to a successful implementation is an environment to compose, run, and view the results of workflows that is easy to use and understand but is also extensible. Microsoft Research worked with the University of Washington to create a scientific workbench called Trident (Barga et al., 2008). Their goal was to allow programmers and scientists to generate workflows, run them on a single machine or on a high-performance computing cluster, and be able to share the workflows and results easily with other users. This system was built with WPF and Windows Workflow in 2009. Microsoft made this an open-source project, so other scientific groups could generate and run the system, while allowing for others to extend and build on their work. This environment allowed for viewing workflows, running of workflow instances, and viewing the provenance data that were generated by each run of a workflow. It includes a workflow registry that allows multiple clients to work concurrently on the workflows and their results. This workflow registry has been ported and extended for use within EMDS.

For EMDS 8, we have taken the front-end UI and have extended it to allow for better documentation of workflows as they are being created, and we have generated additional provenance data for running workflow instances, while capturing the provenance of the workflow creation and editing tasks. A simplified UI was created to enable the building of workflows within EMDS, which guides users in creating a sequential workflow to perform a wide variety of tasks and capabilities.

Support for communicating with external systems and for human-machine workflows requires several subsystems. Security is an important consideration for any production system, and EMDS 8 has started to include aspects of a security system as a starting point, which will be refined and extended over time. Access control and security becomes an issue when an activity initiated by a user needs to process secure data sources and have users of different clearance levels. In EMDS 8, tables of user roles have been implemented to allow for specifying access to an EMDS project.

Provenance information captured by EMDS allows for a record of what happens at each step of system execution. Minimal provenance data is generated because each activity is required to register with the EMDS workflow environment. From this information, data and process transparency can be achieved. EMDS 8 currently implements this level of provenance tracking.

The final extension of the workflow environment is for dynamic generation of workflows based upon knowledge captured in ontologies. By querying the ontologies, EMDS will generate a workflow or a choice of workflow contemplated from user requests. Via this ontology query, the EMDS workflow environment will determine the tools, engines, and other workflows to use to resolve a request. From the selected tools, the system will determine the necessary parameters/variables to perform each step of an activity. By querying the dataset and evaluating the current map document, EMDS will attempt to determine the datasets to use, and any requirements to access/utilize them. The requester will then be given additional prompts to fill in necessary additional information to initiate the workflow and during the processing by the system.

8.5 Collaboration manager running on Azure

Collaboration Manager is the first prototype for EMDS on the web. The goal of this prototype is to take EMDS 8 desktop and expose EMDS project information on a central web site. This means to allow for the viewing of an EMDS project, its assessments and analysis with their corresponding maps. There are three levels of users with the system, Viewers, Team Members and Creators. Groups can be defined and assigned by a Creator of a specific EMDS project during the upload process. Viewers have the right to see a project and its associated maps. Team Members can add comments at the project, assessment, task or map level. Creators can specify the security permissions of the system and generate a separate web site for general viewing of a project. Team Members and Creators can both generate a PDF report on a project and all its components levels, the task level and its children, or just a specific task or map.

8.6 New help system features

EMDS has had a comprehensive online help system since the earliest versions. We began expanding on help system features with tutorials in Version 5 and completed the help system with more tutorials and online demonstrations in Version 8. For the near future, in EMDS Version 8, integration with Microsoft Try. Net will allow for interactive tutorials in which the user can try different EMDS tasks and see their results, all inside a web browser.

8.6.1 Tutorials

EMDS now provides detailed, step-by-step online tutorials on use of the EMDS interface as well as tutorials on building models for NetWeaver, Criterium DecisionPlus, VisiRule and GeNIe. Although the tutorials are not nearly as comprehensive as the software user guides for the various modeling systems, they are intended to provide new EMDS users with a fast-track for getting started with modeling in EMDS.

8.6.2 Demonstrations on YouTube

To complement the tutorials for EMDS and its modeling tools, demonstrations of each are also presented on the EMDS YouTube channel at https://www.youtube.com/@ecosystemmanagementdecisio2443.

8.7 Future development

During the EMDS 8 development timeframe, we focused on creating a multi-platform services version of the EMDS framework. The goal was to create services that could be the foundation for either desktop or web editions of EMDS. Our primary client developed during this phase was an enhanced EMDS client running in ArcMap 10.8. The team then created initial beta versions of desktop clients that worked on ArcGIS Pro, QGIS, and DotSpatial. QGIS and DotSpatial are the desktop clients that are our primary focus going forward. ArcGIS Pro is going to be the replacement of ArcMap in near future, and we will ensure that EMDS desktop runs well on these ESRI platforms. Our next phase of EMDS development is focused on several key areas.

• Collaborative EMDS on the Web–EMDS Online–Being able to create and run EMDS projects on the web and within teams

• Transitioning the Workflow Engine to WexFlow - Transitioning from Desktop Workflow Engine to a web-based multi-platform Engine

• Reporting and Chart Enhancements

• Release of Open Source Editions of EMDS–EMDS for QGIS, EMDS for DotSpatial

• Release of EMDS Desktop of ArcGIS Pro–Migrating EMDS from ArcMap to ArcGIS Pro

8.7.1 EMDS online

EMDS Online will be an important evolution of the product, bringing the power EMDS and web GIS together to create an online collaborative, geodesign workbench. This program allows the user to create a map based on multiple data sources online or upload existing EMDS desktop projects, being able to do analysis on them using EMDS workflows and being able to collaborate with others via customizable views based upon user and team privileges. The initial version will be able to be hosted on Windows Server, Microsoft Azure and AWS, and can run in any modern browser.

8.7.2 Wexflow transition

EMDS workflow capabilities were initially built on Windows Workflow Foundation from Microsoft. Shortly after EMDS 6 was released, Microsoft discontinued its support and development of the product and we were forced to look at other potential workflow products. Our plans were to use WexFlow, but there was an issue with the stability of the product that was not addressed until after the initial EMDS 8 release. EMDS has its own custom-built workflow engine that enabled it to function as a useable engine for a desktop product.

However, for a web-based system, this is insufficient. For workflows that include interactions such as prompts or approval, these tasks can transform the processing of a workflow from a simple continuous task to a long-running task. By long running task, we mean both the case for a long running process that may take time to finish as well as the case of a workflow that may need to pause for several hours to days between the individual activities. The system in this case needs to handle pausing a workflow, offloading it so that other processes can occur, until the request from the human operator is satisfied. Wexflow will allow the user to define the workflow prompts, either via email or text messages, with reminders and timeouts for an activity. Future development will include the ability of the system to allow for specifying invalidation of an entire workflow if an activity or its service and data are time sensitive.

8.7.3 Reporting and chart enhancements

EMDS 8 added the ability to create both charts and reports via a series of wizards, and to be able to save these as templates for future use. EMDS will extend this ability by having a Report Manager, with which users will be able to share templates either created by the EMDS team or created by the user and their team. A template verifier will then ensure that its definition can be reused, and report any potential issues to the template author. A versioning system will be implemented to allow for tracking of changes of reports, chart, and the templates.

8.7.4 Release of open-source editions of EMDS

During the EMDS 8 development period, the EMDS Consortium discussed expanding our official client list within which EMDS operates. With the cost of ESRI software and licensing, we decided to invest our time in creating an EMDS version for the QGIS client. Our stated goal is that anything you could do within EMDS for ArcMap, you would be able to do with EMDS for QGIS and have a similar user experience in both. We developed an initial QGIS client which meets these goals, and we plan to finish the development of this client so that it can be distributed and installed on QGIS on any platform. For DotSpatial, we are developing a custom interface to optimize the EMDS experience and allow it to better support both spatial and non-spatial analysis work. A prototype has been developed, and the plan is to have a final release of both products by the fall of 2023.

8.7.5 Release of EMDS for ArcGIS pro

With ESRI having reiterated its intention to drop ArcMap from its product line sometime in the near future, development of EMDS for ArcGIS Pro began during the EMDS 8 development time period. We had an initial client running on ArcGIS Pro 2.8, but we found it had severe limitations with large raster files and we halted development at that time. Towards the end of the EMDS 8 development cycle, ESRI release a 3.0 edition of ArcGIS Pro, and this resolved the issues with raster files. Development of EMDS on the new version of ArcGIS Pro is expected to be completed by the end of summer 2023.

9 Conclusion

In the present work, we have provided an update on the various additions to or improvements in EMDS features that are available in the latest Version 8. Of course, there are a variety of other contemporary spatial decision support systems (SDSS) for environmental analysis and planning such as NED (Twery et al., 2005) and Heureka (Lamas et al., 2023), and readers may therefore wonder about the comparative advantages of one SDSS technology over another. All other contemporary SDSS of which we are aware still fit the classic notion of a decision support system that is designed to address very specific problems with well-defined goals, objectives, algorithms, and data requirements (Holsapple, 2003). In contrast, EMDS is a decision support framework for building SDSS applications (Reynolds et at. 2014), in which all the elements of the solution are user defined. As a result, direct comparisons of system performance between EMDS applications and alternative SDSS applications is problematic at best. We can, however, offer a few comments on the relative advantages of framework solutions. First and foremost, the framework approach supports application to a broad array of decision support problems and applications developed for a specific (e.g., geographic) context are often readily adaptable to other contexts. In other words, this can expedite the transfer of institutional problem-solving knowledge across contexts. An important aspect of the EMDS framework that supports application of the technology to a broad array of problems, though, is its core design for the interoperability of the four analytical engines as presented in our hypothetical example (Figure 2). It is also perhaps worth noting here that these four analytical engines are components of full-fledged commercial decision support technologies (See Section 10.1). Second, the framework approach implemented in EMDS is not a closed system with respect to either data or models. With respect to data, for example, Hessburg et al. (2013) and Abelson et al. (2022) both used NetWeaver logic frameworks in particular to incorporate modeling outputs from various simulators and other modeling systems to provide support for integrated resource restoration management and resilience assessment, respectively. With respect to models, the workflow editor incorporated into EMDS Version 8 supports explicitly invoking third-party models whose results are then directly incorporated into an EMDS application, analogous to the data-based approach. Third, all SDSS applications composed of multiple analytical components need to be designed for data sharing among the components to support effective interoperability. EMDS applications are not different from other SDSS applications in the latter respect, but the system’s workflow and script-processing features, together with its unified output geodatabase, support a highly efficient approach to managing component interoperability for application developers.

We want to acknowledge that the flexibilities and advantages of a framework-based approach as implemented in EMDS also comes with some tradeoffs compared to more traditional SDSS. In particular, developing EMDS applications with its framework requires time, effort, and modeling expertise to design the models for the engines used in a particular application solution, and the modelers and other developers responsible for application development need to engage with subject-matter experts to design the models required for the application. In other words, some assembly is required. Many EMDS applications have been developed over the past 25+ years (EMDS on Wikipedia, 2023), and they vary from small and simple to very large and complex, with development times ranging from a few days to several weeks, depending on application requirements. However, it is also important to draw a distinction between the time required for application development and the time required to train the ultimate end users to use it effectively, with training time typically varying from one to a few hours, again depending on complexity of the application. Finally, readers may wish to review the eight case studies in Reynolds et al. (2014) to get additional insight into the experiences of EMDS application developers and end users.

10 Additional information

EMDS website. http://emds.mountain-viewgroup.com/

Wikipedia. http://en.wikipedia.org/wiki/Ecosystem_Management_Decision_Support

EMDS licensing. The core EMDS system is an open access system, meaning that the code is freely available to interested application developers. In addition, all the software engines for the EMDS analytical components (including Java script, R and Python) are distributed runtime free as part of the EMDS desktop system. The model development tools (NetWeaver Developer, Criterium DecisionPlus, VisiRule and GeNIe) are proprietary commercial products of their respective companies. However, the US Forest Service currently has site licenses for NetWeaver Developer, Criterium DecisionPlus, VisiRule and GeNIe, subject to availability of funding. These licenses are commonly shared with agency collaborators. Licensing arrangements for the soon-to-be-released EMDS web service and its commercial analytical engines are under development.

Data availability statement

The original contributions presented in the study are included in the article/Supplementary Material, further inquiries can be directed to the corresponding author.

Author contributions

All authors contributed to the article and approved the submitted version.

Funding

Most funding for EMDS development has come from the US Department of Agriculture, Forest Service since 1994, but with some early additional contributions from the United States Environmental Protection Agency and the United States Army Corps of Engineers.

Acknowledgments

The authors thank the US Forest Service Washington Office, Office of Vegetation Ecology and Rangeland Management, for its support of EMDS system development since 2015.

Conflict of interest

Author SP was employed by Mountain View Business Group. Author PM was employed by InfoHarvest Inc. Author MD was employed by Bialystok, Poland and BayesFusion, LLC. Author CS was employed by Logic Programming Associates Ltd. Author BM was employed by Rules of Thumb Inc.

The remaining author declares that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Supplementary material

The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/fenvs.2023.1231818/full#supplementary-material

Footnotes

¹The use of trade or firm names in this publication is for reader information and does not imply endorsement by the U.S. Department of Agriculture of any product or service.

²In the context of spatial decision support, strategic planning is used to decide which landscape elements are the highest priority for management actions, whereas tactical planning is used to decide which of several potential management activities are the highest priority for application in specific landscape units.

References

Abelson, E. S., Reynolds, K. M., White, A. M., Long, J. W., Maxwell, C., and Manley, P. N. (2022). Evaluating pathways to social and ecological landscape resilience. Ecol. Soc. 27, art8. doi:10.5751/ES-13243-270408

CrossRef Full Text | Google Scholar

Barga, R., Jackson, J., Araujo, N., Guo, D., Gautam, N., and Simmhan, Y. 2008. The trident scientific workflow workbench. Proceedings of the IEEE Fourth International Conference on eScience, Indianapolis, IN, USA, December, 2008, pp. 317–318. doi:10.1109/eScience.2008.126

CrossRef Full Text | Google Scholar

Bourgeron, B., Humphries, H., Fisher, C., Bollenbacher, B., and Reynolds, K. (2014). “The integrated restoration and protection strategy of USDA Forest Service Region 1: a road map to improved planning,” in Making transparent environmental management decisions: applications of the ecosystem management decision support system. (Berlin, Germany: Springer).

CrossRef Full Text | Google Scholar

Cleland, D., Reynolds, K., Vaughan, R., Schrader, B., Li, H., and Laing, L. (2017). Terrestrial condition assessment for national forests of the USDA Forest Service in the continental US. Sustainability 9, 2144–2163. doi:10.3390/su9112144

CrossRef Full Text | Google Scholar

Gallo, K., Lanigan, S. H., Eldred, P., Gordon, S. N., and Moyer, C. (2005). Northwest Forest Plan—the first 10 years (1994–2003): preliminary assessment of the condition of watersheds Gen. Tech. Rep. PNW-GTR-647. Portland, OR, USA: U.S. Department of Agriculture, Forest Service.

Google Scholar

Girvetz, E., and Shilling, F. (2003). Decision support for road system analysis and modification on the Tahoe national forest. Environ. Manag. 32, 218–233. doi:10.1007/s00267-003-2970-1

PubMed Abstract | CrossRef Full Text | Google Scholar

Hessburg, P. F., Reynolds, K. M., Salter, R. B., Dickinson, J. D., Gaines, W. L., and Harrod, R. J. (2013). Landscape evaluation for restoration planning on the okanogan-wenatchee national forest, USA. Sustainability 5, 805–840. doi:10.3390/su5030805

CrossRef Full Text | Google Scholar

Holsapple, C. W. (2003). “Decision support systems,” in Encyclopedia of information systems. Editor H. Bidgoli (New York, NY, USA: Academic Press), 551–565.

CrossRef Full Text | Google Scholar

K. M. Reynolds, P. F. Hessburg, and P. S. Bourgeron (Editors) (2014). Making transparent environmental management decisions: applications of the ecosystem management decision support system (Berlin, Germany: Springer).

Google Scholar

Krsnik, G., Reynolds, K. M., Aquilué, N., Mola-Yudego, B., Pecurul, M., Garcia-Gonzalo, J., et al. (2023). Assessing the dynamics of forest ecosystem services to define forest use suitability. Front. For. Glob. Change.

Google Scholar

Lämås, T., SängstuvallÖhman, L. K., Lundström, J., Årevall, J., Holmström, H., Nilsson, L., et al. (2023). The multi-faceted Swedish Heureka forest decision support system: context, functionality, design, and 10 years experiences of its use. Front. For. Glob. Change 6. doi:10.3389/ffgc.2023.1163105

CrossRef Full Text | Google Scholar

LandFire, (2023). The LandFire program. https://www.landfire.gov/(last accessed on September 21, 2023).

Google Scholar

Marcot, B. G. (2017). Common quandaries and their practical solutions in Bayesian network modeling. Ecol. Model. 358, 1–9. doi:10.1016/j.ecolmodel.2017.05.011

CrossRef Full Text | Google Scholar

Reynolds, K. M., Hessburg, P. F., Keane, R. E., and Menakis, J. P. (2009). National fuel-treatment budgeting in US federal agencies: capturing opportunities for transparent decision-making. For. Ecol. Manag. 258, 2373–2381. doi:10.1016/j.foreco.2009.08.011

CrossRef Full Text | Google Scholar

Reynolds, K. M., Hessburg, P. F., Miller, R. E., and Meurisse, R. T. (2011). Gen. Tech. Rep. PNW-GTR-840. Portland, OR, USA: USDA Forest Service.Predicting risk of soil degradation associated with wildfire and ground-based logging

Google Scholar

Reynolds, K. M., Hessburg, P. F., Povak, N. A., Salter, R. B., Sullivan, T. J., McDonnell, T. C., et al. (2023). Methods, Tools, and Technologies Assessing impacts of sulfur deposition on aquatic ecosystems: a decision support system for the Southern Appalachians. Ecosphere. doi:10.1002/ecs2.4507

CrossRef Full Text | Google Scholar

Twery, M. J., Knopp, P. D., Thomasma, S. A., Rauscher, H. M., Nute, D. E., Potter, W. D., et al. (2005). NED-2: a decision support system for integrated forest ecosystem management. Comput. Electron. Agric. 49, 24–43. doi:10.1016/j.compag.2005.03.001

CrossRef Full Text | Google Scholar

Wikipedia, (2023). EMDS on Wikipedia 2023. EMDS page. http://en.wikipedia.org/wiki/Ecosystem_Management_Decision_Support (last accessed on September 21, 2023).

Google Scholar