This section shows the outputs of the compiled accounts, in this implementation results are summarized either in tables, or map. The first are downloadable as spreadsheets, the latter can be download as raster files (Geotiffs) or image (PNG). This section also emphasizes how results from other frameworks can be obtained from the app, and compared against People-EA main outputs. Finally, the last part of chapter introduces the process for integration of new models and data


Results of the accounts

The outputs of an observation are tables and/or maps. Whenever a table is compiled, the underlying spatial explicit information is also shown in a map, so in such a case both information are available.

The user knows in advance the expected outcome from the icon associated to a particular observation, this symbol indicates the main output is a table, this other a map.


Tabular outputs

The main output of an account is a table, and once this is computed, the k.Explorer moves automatically from the Data view, to the Documentation section, showing the Table section (for more information on the different sections check this chapter of the guide)

The table can be copied or downloaded (click on the symbols at the right bottom of the table to export it)

Maps

To explore the geospatial explicit information in the maps used to summarize the results in the table, go back to the View Data section:

Expand the View Tree to visualize all inputs, intermediate and final output, as shown in the image below

When the 3 dots are displayed horizontally, it means that the options in the menu are hidden 

By clicking on the 3 dots they get disposed vertically  and a drop-down menu lists the options available.

Select the map that you want to visualize

When the knowledge bar turn yellow and the elephant's ball spins, the system is computing the information queried.
In this case, is loading the map

This can be visualized in the explorer or downloaded as a raster file (.tiff format) for further analyisis in a GIS system.



One can download a map by clicking on the arrow pointing down (↓) that appears when hovering over the observation ( an observation is any of the element observed in the workflow and listed in this menu)

This was the main output, but any input and intermediate output of a workflow can be observed by ticking their boxes.

As an example, the results for NDVI are shown below.

Notice how observations that change over time in the context selected, have the symbol of a clock next to them, and at the bottom of the menu, you'll see a timeline, in a light blue color.
In this example, as there are just two temporal observations, there is just one separator (small tick in yellow), dividing the 2 temporal observations (2015 and 2016). 

Selecting a different temporal observation, the map changes and the system displays the result for that year

2015

2016

Download all the outputs generated in a session

All outputs in the session can also be download by scrolling down at the bottom of the panel, under the section Key outputs.

There all maps and tables of the main outputs in the current session can be downloaded by selecting these buttons.


This feature is currently not working, as it generates corrupted files. We are working to fix this issue


Compute results other frameworks (SEEA-EA, SDG, CBD) be computed?

One advantage of the modular and interoperable modelling approach used in ARIES, is the possibility to easily compare methodologies or update a workflow with more recent or better data.

Results from other frameworks are already available in the application.

ARIES for SEEA accounting tables

This section contains the results of the ARIES for SEEA application.

Each account contains a drop-down menu (three horizontal dots), from which the user can select accounts to compile:


There is a dedicated guide to the use of the ARIES for SEEA application.

      • Extent Accounts

        These accounts measure the extent of the IUCN Global Ecosystem Typology ecosystem types, or land cover, present in the context of your analysis, in km2.
        The different types of accounts provide varying levels of detail in summarizing ecosystem/land cover extent and its change over the selected time period.



      • Condition Accounts

        These accounts measure ecosystem condition. Currently, only forest ecosystem condition accounts are supported, but condition accounts for other ecosystem types will be added soon (beginning with those for grasslands).
          


        The conditions metrics available for inclusion in the account appear in a drop-down menu when the user clicks on the triangle next to "Forest condition metrics".



        Three types of ecosystem condition accounts are available:

        1. Condition Variable Account: report the value of each condition metric in their originally observed values (non-transformed);
        2. Condition Indicator Account: rescale ecosystem condition variables to values between 0 and 1. Rescaling is calculated as the difference between the observed condition variable value and the optimal condition reference.
            By normalizing multiple condition variables, different indicators can be more directly compared;
        3. Condition Index Account: combines all indicators together using a weighted mean. Currently, all indicators take the same weight, summing to 1 (e.g., 0.25 when four condition metrics are selected). In future releases of ARIES for SEEA, users will be able to assign custom weights to the indicators to better reflect their local importance when accounting for ecosystem condition.




      • Ecosystem services account (physical terms)

        These accounts measure the biophysical quantities of services provided by ecosystems and used by economic units. Use tables are not explicitly supplied with the model outputs, but use is described in the automatically generated reports for the selected accounts. In the current version, four ecosystem services are available. A fifth one, Nature-based tourism, is in its final stages of development and will be made available in a future ARIES for SEEA release.

          

      • Ecosystem services account (monetary terms)

        These accounts measure the monetary value of the selected ecosystem services, applying SEEA EA-compliant valuation method(s). Use tables are not explicitly supplied with the model outputs, but use is described in the automatically generated reports for the selected accounts. In the current version, three ecosystem services are available. A fifth one, Nature-based tourism, is in its final stages of development and will be made available in a future ARIES for SEEA release.


      • Spatial and temporal aggregation

        The user can select how the results of the accounts are aggregated in accounting tables.
        Currently, only the first option is available. In future ARIES for SEEA releases, the user will be able to generate accounting tables as follows:


        1. "Primary only": a single table summarizing results for the entire context identified by the user;
        2. Administrative subregions: multiple tables grouped by subnational jurisdictional entities (i.e., administrative level 1 - State, Province, or District);
        3. Protected areas: multiple tables grouped for protected areas found in the analysis context;
        4. River basins: multiple tables grouped results by watersheds found within the analysis context.

      • Temporal accounting

        When a multiple-year analysis is selected, the user can decide to output tables:
        1. For the first and last years of the time series only, or
        2. For all years within the time period selected.
Add indicators from other outputs in the left panel of the application

In the upper left corner of the application, there is a section dedicated to SEEA-relevant indicators.


This section includes selected indicators from the Sustainable Development Goals (SDGs) and the Convention on Biology Diversity (CBD) Post-2020 Biodiversity Indicators, which have been added to the application.

Once it is opened, a drop-down menu shows the list of available indicators. 


Those selected by the user are added in the ARIES for SEEA panel as if they were an additional standard SEEA EA account


Integrate local information in ARIES

ARIES enables a high degree of modularity and interoperability between independently developed data and models.
Since models and data are combined as individual components in a workflow that generates a result, each component can be substituted to estimate the results if it yields to more accurate result for context analysed.

Monolithic

  1. The output is the result of single unified block of operations



  2. Each model is self-contained and independent from others



  3. Typically lacks flexibility.


Modular

  1.  The output is the result of the most effective integration of granular components

  2.  Model, data, algorithm and processes are all independent block

  3.  The AI integrate the best available information in the system to best answer the question asked

  4.  Flexibility is at the core of this approach, and whenever better inputs/ information to answer a question becomes available, is automatically integrated in the workflow to provide an improved answer

If a user has any local knowledge that would like to introduce in the system, this being a more appropriate dataset, a value in parameters used in a model, or a an entire new model, those can be integrated in ARIES.

ARIES is an integrated semantic modelling platform, in which any new data and models introduced in the system must be consistently defined, so that they work in harmony with the rest of the information already available.

Semantic modelling is a non-trivial task. This operation is usually done by our team once the data or model has undergone an internal revision. This may take more or less time, depending on the type of information to add into the modeling platform. 

On the other hand, once integrated in the system, users can benefit from that additional information that will be prioritized automatically when the workflow requires it, as they do with any other inputs used in the accounts already compiled.
This means that a component, introduced as input for a particular purpose, could be used also by other models that require the same information, and thus improve other estimates.

This is the advantage of working in an environment that build models that are both modular and interoperable.


If the Early Adopters have local knowledge that want to be considered in the computation, or would like to test how their local information change a particular outcome, this can be done.

The adjustment of specific parameters (e.g. weight differently the indicator in the condition index), or the substitution of a particular dataset for another should be possible, if the changes are consistent with the models that use that information, which is not always straightforward.
For example, the integration of new maps to identify the soil organic carbon in a specific context, would also require to recompute the reference level, since the reference data used to define the condition for that aspect of the forest condition has changed.

What is feasible within the context of this project should be assessed case by case, not all inputs require the same amount of work, and it's crucial that data and models are integrated correctly.
What are the requirements for resources (data and/or models) to be integrated?

Resources (data and models) need to be made accessible online. Users will make the resources available on a federated server of choice:

  1. this can be local and maintained by the user, i.e. a local machine set up to serve the data, 
  2.  or an existing remote service, such as VITO, or ESA.

If necessary, users must provide the resource metadata to interpret the content of the resources uploaded (e.g. description of raster categories or attributes and field of vector files for a map, as well as code and documentation of a model) 

The preferred way to serve the data would be to install and use their own federated node for this purpose.

In regards to data privacy, the service can be hosted locally with complete privacy (1) or be one provided by VITO, ESA or ARIES (2), with full user control of the visibility of the resources provided. By user choice, the submission will associate the data with the user name or group, so that the new resources may be used as the new default for all models run by the same user, or added to a scenario to be selected explicitly.

In this context, a group is a selected list of users belonging to an institution, or involved in a particular project, which may have access to information that others won't, such as the data and models made available for the Early Adopters within this project.

What would be an example of the integration of local knowledge?

During our first webinar, the colleagues from the Netherlands mentioned that they'd rather use their Ecosystem Types to categorize the results of the accounts.

 If their map is integrated in the system, when observing an account within the Dutch boundaries, ARIES would prioritize the Ecosystem Type information provided by the Dutch NSO, and break-down results according to this information.

On the rest of Europe instead, the results would still be categorized by the European Forest Type as described in chapter 3.