Pioneering easy-to-use forestry data with Forest Explorer

1. Introduction

Forest science and forestry rely on the use of large-scale datasets that cover lengthy periods of time [21]. This is because trees are long-lived organisms that require continuous monitoring to obtain sound and accurate information. Similarly, large-scale monitoring systems are used to capture the complexity and structure of forests in their full extend. Permanent and extensive data recording systems, particularly land cover maps and forest inventories [31], are needed to implement sound sustainable forest management [3,24,25] to ensure a constant flow of ecosystem services such as habitat conservation and raw materials (timber, resin, cork…).

Due to long-term scale of forestry actions, the private sector has no incentives to conduct this type of data collection and curation. As a result, the public sector is the main responsible for monitoring forests and providing this information to society. Such information is consumed for different purposes by diverse end users, including forest stakeholders (governments at different levels, environmental NGOs and other lobby groups), operational foresters, data and environmental journalists, interested citizens, and start-up promoters.

However, exploiting forest inventories and land cover maps is a non-trivial task that requires both domain expertise and technical skills. Forestry datasets are typically isolated, described with disparate data schemas, and using unfamiliar (sometimes even proprietary) formats. Given these limitations, Linked Open Data and Semantic Web technologies can help to facilitate the integration and accessibility of forestry data. Towards this goal, the EU project Cross-Forest1

The Cross-Forest dataset is available as Linked Data through the SPARQL endpoint at https://forestexplorer.gsic.uva.es/sparql/. This dataset is a complex resource that integrates spatial features corresponding to plots, trees, and land cover patches. Target users from the forestry domain need to explore and analyze this dataset in order to fulfill their goals. This is especially challenging as this user group is not fluent in Semantic Web languages. While there are some Linked Data browsers for lay users [8,9,14], most of them have limited support for geospatial data. Moreover, visualization tools of geospatial Linked Data are very scarce and typically require knowledge of SPARQL, e.g. Sextant [18].

In this paper we present Forest Explorer, a web tool for easily accessing the contents of the Cross-Forest dataset. Forest Explorer is designed for non-Semantic Web experts, so the user interface is based on an interactive map that completely hides the manipulation of RDF data and exchange of SPARQL queries behind the scenes. The rest of the paper is organized as follows: Section 2 reviews exploration tools of geospatial Linked Data, as well as existing approaches for visualizing forestry data. Section 3 presents the functional requirements of Forest Explorer. Section 4 describes the design and implementation of the tool. In Section 5 we give evidence of the impact of Forest Explorer, including the results of a user study. The paper ends with a discussion and future work lines in Section 6.

Since the earlier years of the Semantic Web, the challenge of exploring RDF data was evident [13]. Preliminary projects in this area were targeted to either Semantic Web experts or technology enthusiasts willing to put in the time to learn. More recent works [9] have stressed the importance of supporting both lay users and domain experts, e.g forest managers. Such users may not have any knowledge of SPARQL, OWL, or RDF and require appropriate tools to work with Linked Open Data.

There are some Linked Data browsers, visual query builders, and exploration tools that do not require expert knowledge of Semantic Web technologies [8,9,14]. A recent example is RDF Surveyor [33], a lightweight exploration tool targeted to lay users that is part of our previous work. Unfortunately, most of the exploration tools available have limited support for geospatial Linked Data if any, e.g. the visualization of an entity in RDF Surveyor includes a geo widget with a marker if a point location annotated with the Basic Geo Vocabulary2

Some systems have been designed to support the visualization of geospatial Linked Data. Again, many proposals are targeted to Semantic Web experts: GeoYASGUI [1] is a SPARQL editor that natively supports GeoSPARQL and provides a result set visualizer; Sgvizler [28] is a JavaScript library that can produce different charts – including maps – with the results of SPARQL queries; and Sextant [18] is an advanced visualization tool that can combine spatial data from several endpoints and represent the temporal dimension, although it still requires knowledge of SPARQL in order to use it. There are seldom visualizers of geospatial Linked Data for non-Semantic Web experts: LinkedGeoData browser [29] is a dedicated visualization tool for OpenStreetMap; and Map4RDF [10] is a browsing tool of geospatial RDF datasets that uses a faceted interface to control the information to display.

In the forestry domain, we can find several initiatives at national or regional level focused on the delivery of raw data, but not using Linked Data and Semantic Web technologies. A remarkable example at pan-European level is the EFISCEN database portal [27] that offers forestry datasets from 32 countries, but using disparate schemata and data formats. National data portals are common, although the typical case is downloadable raw data in proprietary format (e.g. Spanish forest inventory3

Visualization of forestry data is commonly achieved through a Geographical Information System (GIS). For example, Global Forest Watch5

Other forestry tools focus on the analysis of data. This is the case of BASIFOR7

The Spanish forest inventory [2] is a continuous dataset that is updated every 10 years. A plot is an homogeneous and small area of the territory that constitutes the sampling unit. Forest technicians survey plots to gather tree data (location, species, diameter, and height). The current version of this inventory accrues 1.4M trees, 91.9K plots, and 4.3M positions. The Spanish land cover map8

The Cross-Forest dataset integrates the latest versions of the Spanish forest inventory and land cover map in Linked Data format, thus fulfilling one of the main goals of the Cross-Forest project. Provinces, patches, plots and trees are modeled as spatial features with a geometry and a set of measures extracted from the corresponding source. The details of the main features of each dataset are shown in Table 1. Their positions are represented using a simple ontology that indicates the Coordinate Reference System and the coordinates of the position. This ontology makes safe reuse [7] of relevant geographical ontologies, including GeoSPARQL [20], the W3C Basic Geo Vocabulary [5], and the ISA Programme Location Core Vocabulary [19].

The original datasets includes features with absolute positions using UTM coordinates, but some features, namely trees, are only annotated with relative positions, using plot centers as reference. When making the conversion into RDF we have enriched the original data with the inclusion of WGS84 positions for every feature, including trees. UTM coordinates and relative positions are still available in the Linked Open Data version of the datasets, so there is no impact for users of the original data sources. We used Proj4js9

The transformation of the land cover map into RDF includes the creation of a new layer of patches in a lower resolution in order to make efficient the drawing of polygons on top of a Web map (see Best Practice 4 in [30]). The taxonomical structure of trees and bushes (including class, genus, family, and species) is linked to relevant datasets in forestry and biology fields: the NCBI taxonomy [12] and the CrossNature dataset.11

We identified a target group interested in the resulting integrated dataset: domain experts such as forest managers and operational foresters that have to invest a lot of time with manual integrations or using forest analysis tools like BASIFOR [4] due to strong coupling to schemata, legacy formats, or limited tool scope. For instance, [23] reports a significant effort integrating the data of three provinces of the Spanish forest inventory (this dataset is sliced in 50 files, one per province) – note that this is a simple integration case as the database schema is the same for the three provinces and no other data sources were required. Moreover, analyzing forestry data from different countries is a time-consuming and difficult task, requiring schema harmonization and data conversions. Another target group corresponds to lay users such as data journalists or citizens interested in forestry. These two groups are not knowledgeable about Semantic Web technologies, so they need a tool that shows the data while hiding the complexities of its representation. As a result of a collaborative design effort among two forestry experts and two Semantic Web practitioners (the authors of this paper), we identified the following requirements:

In this section we present the tool devised to easily access the contents of the Cross-Forest dataset. The proposed tool is Forest Explorer and satisfies the requirements described in Section 3. The following subsections dive deep into the design and implementation of Forest Explorer.

4.1. Logical architecture

The logical architecture of Forest Explorer is depicted in Fig. 1. The Map generator is in charge of displaying the view for the end user. This component employs a base map obtained from the Map server and listens to the requests made from the different Feature managers for showing markers, polygons, popups, or tooltips on top of the map. More specifically, the Province manager gathers province geometries and forest inventory data aggregated by province and prepares a suitable display request to the Map generator. Patch, Plot, and Tree managers work in a similar way, obtaining first the information about the corresponding features (see Table 1) located in the geographical bounds of the current map view, and then sending display requests to the Map generator.

OPEN IN VIEWER

Fig. 1.

Logical architecture of Forest Explorer.

In order to comply with requirement R4, the different Feature managers are activated depending on the zoom level. In case of large areas, the user can choose between province or patch views (R5). In the former case, the Province manager takes control and requests the presentation of inventory data aggregated by provinces. In the latter case, the Patch manager is activated and requests the lowest resolution layer available of the land cover map. With intermediate zoom levels, the Patch and Plot managers are both enabled to present the plots on top of a land cover map of the visible area. With high zoom levels, the Patch and Tree managers are activated – the highest resolution layer available of the land cover map is employed in this case, while the Tree manager requests the presentation of tree markers to the Map generator based on the inventory data for the target area. Note that this design is compliant with Best Practice 4 in [30], recommending to provide multiple resolution versions of features at different zoom levels.

The Data manager handles all the data requests from the Feature managers. This component is able to communicate via SPARQL and is configured to use the Cross-Forest and DBpedia endpoints. As described in Section 3, the Cross-Forest dataset contains a Linked Open Data version of the Spanish forest inventory and land cover map. DBpedia is employed as a source of tree species information, providing images and multilingual descriptions (R6). Upon receipt of a request, the Data manager first checks if the result is already available in the Data cache. In case of a miss, the Data manager sends one or more SPARQL queries to the endpoints. Section 4.2 gives further details of the functioning of the Data manager.

4.2. Data gathering

As depicted in Section 4.1, the Data manager is in charge of all data gathering operations in Forest Explorer. The design of this component is challenging due to a number of reasons: (1) requests look quite varied, referring to different types of features (provinces, patches, plots, and trees) and all their associated data; (2) the size of the Cross-Forest dataset is not small – 4.3GB corresponding to 73.7M triples; and (3) requests can be very numerous since any change in the interactive map will trigger data requests by one or more Feature managers.

Fortunately, the different request types can be abstracted to the identification of features localized in a specific area and then obtaining their corresponding feature data. The Data manager uses SPARQL template queries for retrieving the features localized in the map view. Since plots and trees have points as geometries, a suitable query basically has to check which points are included in a bounding box. Listing 1 shows the template used for plots in which {{latnorth}}, {{latsouth}}, {{lngwest}}, {{lngeast}} are placeholders for the map view bounds.

OPEN IN VIEWER

Listing 1.

SPARQL query template for retrieving plots in the map view

As patches and provinces have polygons as geometries, queries have to be adapted to find the polygons intersecting with the map view. The template used for patches is included in Listing 2. Note that we use the bounding box of the polygon (included for all polygons in the dataset) to simplify the detection of patches in the map view. In order to comply with requirement R4, the template is parametrized to select a specific {{layer}} and to define a minimum threshold for the area of polygons, i.e. {{minarea}}. The Data manager chooses the most appropriate layer based on the zoom level of the map view, while it sets the minimum area to 10 pixels in the user device.13

¹³

The assumption here is that patches of less than 10 pixels are barely visible so it is better to not waste time and computation resources with them. The area of a pixel changes with the zoom level, so a patch discarded for being too small can be later displayed in case of zooming in.

OPEN IN VIEWER

Listing 2.

SPARQL query template for retrieving patches in the map view

Once the Data manager obtains the set of features in the area of interest, it retrieves the corresponding data in a next step. Listing 3 shows the query template used for this purpose; it is extremely generic and easily adaptable to each feature type. For example, obtaining the height of a collection of trees just requires setting their IRIs and the height property IRI defined in the Cross-Forest ontology. As a result, gathering feature data is just a matter of selecting the set of properties to extract for each feature type (see Table 1). Class membership is required in some cases – for example to obtain tree species – so we have included another generic template for retrieving the classes of a set of individuals.

OPEN IN VIEWER

Listing 3.

SPARQL query template for obtaining the values of a property for a set of individuals

OPEN IN VIEWER

Fig. 2.

The Data manager limits query exchanges with the endpoint by keeping track of the map regions with localized features. The map is initially unknown to the Data manager (a), so a feature location request for region R 0 (b) requires querying the endpoint – the Data manager stores the results in the Cache and updates its tracked area to R 0 . In (c), a request about region R 1 is decomposed into subregions R 1 ′ and R 1 ″  – the features in R 1 ′ are obtained from the Cache and the endpoint is queried to retrieve the features in R 1 ″ . The tracked area now includes R 0 ∪ R 1 . As region R 2 is contained in the tracked area, the feature location request in (d) is answered with the Cache.

The Data manager stores all retrieved data in a Cache so as to reduce exchanges with the endpoint. This is quite effective with feature data, since the template query in Listing 3 can be easily parametrized to avoid requests of feature data already available in the Cache. With respect to feature locations, a similar approach consists on caching the results for every map view bounds request, i.e. queries built with Listing 1 for plots, Listing 2 for patches, and so on. However, this solution is too naive as the cache will only get a hit in case of a request with exactly the same map boundaries as a previous one. Instead, the Data manager keeps track of the map regions with localized features and exploits this information to restrict queries to unknown areas. Figure 2 illustrates the idea:

At the beginning the Data manager has no information of any part of the map.

Upon receiving a feature location request for region R 0 , it asks the endpoint about the features in such area – the Data manager stores the results in the Cache and updates its tracked area to the bounding box of R 0 .

A request about region R 1 is decomposed into subregions R 1 ′ and R 1 ″  – R 1 ′ is the intersection of R 1 and the tracked area, so the included features can be obtained from the Cache. Since R 1 ″ is unknown to the Data manager, it has to query the endpoint to retrieve the features in R 1 ″ . Then, the Data manager updates its tracked area to R 0 ∪ R 1 .

A request about region R 2 does not require further queries to the endpoint, as R 2 is contained in the tracked area.

4.3. User interface

In order to comply with requirement R3, the user interface of Forest Explorer exposes an interactive map as its main component. Figure 3 shows some snapshots that illustrate the design of the user interface. Since the tool has to work with a diversity of devices (R1), the map is set in fullscreen mode to easily adapt to different screen sizes. Similar to other map applications, panning and zooming are naturally supported for both point-and-click and touch interfaces. In this regard, zoom buttons are included in the lower-right corner; the extra button with a person icon is used to navigate to the user location – this latter functionality is especially useful when employing Forest Explorer with a mobile device in a field trip.

OPEN IN VIEWER

Fig. 3.

Snapshots of the user interface of Forest Explorer. (a) View of the Spanish provinces in a large area (see the map scale in the lower-right corner) with the form in the upper-left part expanded and showing two species filters, Pinus sylvestris in indigo color and Pinus pinaster in brown; inventory tree data for the province of Soria is displayed in a tooltip. (b) View of the patches in a large area of Spain with the form in the upper-left part collapsed; patches are plotted in different colors depending on their use (farms in orange, water in blue, artificial in grey, and forests in green); forest patches containing a filtered species use the color filter (indigo and brown in this running example); a pop-up shows the data of a forest patch in the province of Soria. (c) View of a small forest area (see the map scale in the lower-right corner) in the province of Soria; plots are displayed as circles on top of the patches; plots and patches employ the same color code as before; a tooltip shows inventory data for a plot. (d) View of a tiny small forest area corresponding to the center of a plot in Soria; tree markers are shown in their actual positions using taxa-dependent icons and corresponding filter colors; a tooltip shows the species, height, and diameter of a specific tree.

As the user navigates with the map, a Feature manager takes control by obtaining feature information from the Data manager and then sending display requests to the Map generator (see Section 4.1). For example, the Province manager controls the view of Fig. 3(a); the Patch manager is activated in Fig. 3(b); the Patch and the Plot managers collaborate to build the view in Fig. 3(c); and the Tree manager is active in Fig. 3(d).

Beyond map navigation, the user interface needs to include controls to allow the user to adjust the information to display (R5). For this purpose, Forest Explorer includes a form in the upper-left part – see Fig. 3(a). This form can take a significant part of the screen in mobile devices, so it can be collapsed by pushing the ‘-’ button – the collapsed form is shown in Fig. 3(b)(c)(d).

A key characteristic of the dataset is the tree species of land cover map and forestry inventory. Thus, the form includes a ‘Filter species’ button that can be pushed to easily browse the taxonomy of tree species (obtained from the Cross-Forest ontology) and then select one or more filters. The form in Fig. 3(a) includes two species filters, Pinus sylvestris in indigo color and Pinus pinaster in brown. Each filter includes buttons for removal (‘x’ icon), color change (‘tint’ icon), and more info (‘info’ icon) – the latter one displays a popup with additional information about a tree species such as an image and a localized description obtained from DBpedia. Species filters have a significant impact in the map view: the color code of species filters is applied to the different features, while species data is also displayed in the different tooltips and popovers – see the snapshots in Fig. 3.

In addition, the form includes a textbox for searching places (obtained from the GeoNames dataset14

¹⁴

http://www.geonames.org/

) that sets the view of the map to the location of the selected place. Unsurprisingly, the ‘Scientific names’ switch allows the user to choose between scientific and vulgar names of tree species. Other controls are dependent on the zoom level: the ‘Show provinces’ switch is displayed with low zoom levels so as to choose between the province – Fig. 3(a) – and patch – Fig. 3(b) – visualizations. With intermediate zoom levels, the user can hide or show the plots in the map – this applies to Fig. 3(c), although the form is collapsed in this snapshot. Color saturation for plots can also be adjusted with a range input. Finally, it is possible to highlight patches by land use, e.g. to find plantation forests, dehesas, thickets, and so on.

We submitted a preliminary prototype of Forest Explorer to Desafío Aporta 2019,27

In January 2020 we used our social networks to announce the release of Forest Explorer. Specifically, we sent 8 tweets in Twitter that received over 6,500 impressions, more than 100 likes, and about 30 retweets. We also prepared three short posts in Facebook and one more in Twitter, receiving over 1,000 and 375 impressions, respectively.

Beyond media coverage and social networks, we used Google Analytics to assess the uptake of Forest Explorer. Tracked data was obtained from the live site in October 2020. About usage, more than 3,200 users have accessed the tool and have carried out over 5,500 sessions with an average session time of 4 minutes and 11 seconds. 85% of the traffic comes from Spain and the preferred language was Spanish in 82% of the sessions – this is not surprising, as the dataset only covers Spanish forests. Google Analytics gives also information about the employed devices: 43% were Windows computers, 38% Android mobiles or tablets, 12% iOS devices, 6% Mac computers, and 1% Linux computers.

Forest Explorer is designed to work with the Cross-Forest dataset, thus benefitting from the use of Semantic Web technologies for data integration. Indeed, this advantage was identified in the user study (see Table 4), although participants still demanded additional sources to be included – it looks data integration is much needed in the forestry domain. In this regard, we are currently working on the conversion of the Portuguese forest inventory and land cover map into Linked Open Data. Once included in the Cross-Forest dataset, they will be automatically browsable through Forest Explorer. Despite the schemata of the original Portuguese and Spanish sources are different, the overarching ontology homogenizes the terminology, so no further changes will be required in Forest Explorer.

Moving on to the technical design of Forest Explorer, the Data manager is the component in charge of gathering data from the Cross-Forest and DBpedia endpoints (see Fig. 1). The solution devised relies on the use of SPARQL query templates to facilitate the extensibility of Forest Explorer. As an example, the template query in Listing 3 is employed for gathering every type of feature data and also for obtaining images and tree species descriptions from DBpedia. Similarly, the Data manager uses a query template for obtaining the taxonomy of subclasses of a target class; this is employed with species and soil uses. Furthermore, Section 4.2 already describes the query templates used for retrieving plots and patches, as well as the Cache proposed for reducing query exchanges with the Cross-Forest endpoint. Such query templates can be abstracted away to retrieve arbitrary features in order to extend the applicability of Forest Explorer to other contexts.

Geospatial queries in Forest Explorer are handled with the SPARQL templates in Listings 1–2. They are simple interval queries that run quite fast and provide the necessary expressiveness for the retrieval of features in a bounding box. Alternatively, GeoSPARQL functions such as sfWithin could be employed for this purpose – this approach was discarded because the Cross-Forest triplestore provides custom geospatial functions, but GeoSPARQL functions are not supported. We acknowledge that GeoSPARQL is quite powerful and convenient for conducting geospatial operations, and for this reason the Cross-Forest dataset provides geometries expressed in Well Known Text. We envision the use of GeoSPARQL for new forest scenarios in the near future.

The different Feature managers in Forest Explorer are bound to the corresponding feature types, i.e. province, patch, plot, and tree. They can be easily modified so as to prepare new labels for tooltips, to request different markers to be rendered by the Map generator, etc. Moreover, new Feature managers can be added to the system; the recommended way is (1) to use an existing Feature manager as a base and (2) to update the Data manager for gathering feature data – existing query templates should be sufficient in most cases.

To wrap up, Forest Explorer is a novel exploration tool of forestry Linked Open Data designed for non-Semantic Web experts. Users can interact with a map to navigate to the area of interest and to control the information to display. To limit data exchanges with the SPARQL endpoint, Forest explorer uses a cache and smart geographic querying. So far, we have attracted the attention of the forestry community, not very familiar with Semantic Web technologies. Our future work includes the integration of new data sources from other countries in the Cross-Forest dataset, beginning with Portugal. Other geolocated data can be integrated such as cadastral parcel information, digital terrain models, land use maps, remote sensing layers and hazard occurrence or vulnerability (forest fires, pests and diseases, or blown down damages). We also plan to introduce data analysis capabilities to support forest management and planning scenarios. In this way, Forest Explorer could provide similar functionalities as BASIFOR, but with strong visualizations and taking advantage of Linked Open Data for forestry data integration.