Creation of special areas

[timlinux]

Trends.Earth shall allow users to digitize new vector features to delineate areas of special interest. The following type of vector layer shall be supported, with its own predefined schema (according with previous e-mail exchanges with Brian O’Connor from UNCCD):

1. False positives/false negatives; The False negatives/false positives layer shall have the following additional features: • The SDG 15.3.1-related algorithms shall be modified in order to allow submitting the contents of this layer and perform a re-analysis of the original result based on the user- supplied information about false positives or negatives. The work of adapting the algorithms themselves is not in scope of this proposal. However, Kartoza shall perform the necessary refactoring to the code that calls the algorithms in order to ensure they are able to receive this extra layer as an input; • Attribute form for digitized features shall provide a dynamic representation of the percentages of the respective SDG15.3.1 and sub-indicators’ values, as shown below. The workflow for creation of the false positives / false negatives: 1) A button in the user interface will allow the user to create a new polygon layer. 2) The schema for the layer should follow the attributes as per the screenshot below. 3) When polygons are added to the tool using manual digitising (using the built in QGIS editing tool), there shall be a ‘source’ column populated to indicate this (Source – Manual Digitising) 4) The forms for the tool will be defined in the template and if needed with python code and will be customisable by Trends.Earth in future if needed. The form system shall be based on QGIS’ drag and drop form designer.

5) At the end of the process, there shall be another button in the user interface that will upload the layer to an API end point which will thereafter be managed and analysed by Trends.Earth process. This dataset shall be saved in the Trends.Earth “datasets” folder (through which it will then be accessible to other Trends.Earth tools). The tool used to digitize won’t have any direct interaction with the Trends.Earth API except for if necessary for the chart based version. We assume that there will be no processing in the broader land degradation workflow locally that the Kartoza team needs to deal with. Calculating the chart data (see below) shall be done locally as needed. For example removing alien vegetation may be flagged as degradation but it is actually a land improvement since aliens are being removed, so you should be able to indicate with the flagging tool that the degradation is a false negative.

Although polygons are the preferred geometry the user can select points to locate the centre of a special area but they must buffer it out to create an extent for the recalculation of the SDG layers to work. So a buffering tool should be offered in addition to points and the creation of buffers around a point must be enforced. The buffering tool shall accept the same attributes as the polygon tool above but the user interaction when capturing the buffered points shall be:

• A map tool that can add circles by point clicking on the map to define the center of the circle and defining the area in km2 or by radius (km) of the circle to be created.
• When a circle is added in this manner, there shall be an source attribute populated in the attribute table that will indicate that the circle was captured using the buffer tool. (Source – Buffer Tool) Contrary to the annotation above relating to the Indicator Values field above, we will not be able to inline a chart in the form. Thus we propose to dynamically calculate these values and provide them as JSON as part of the export. Each row shall also have a hidden UUID column. There shall be button in the form that will, on user press, update the area and Indicator Values columns that the user can then use to inform their choices in the related fields of the form. The code architecture shall be constructed in such a way that it will be easy to incorporate new schemas (e.g. digitising areas of potential interest for restoration) in the future. The document shall adhere to the following schema:

https://github.com/ConservationInternational/trends.earth-schemas/blob/develop/te_schemas/error_recode.py

The schema is currently under review, the client shall indicate when the schema is ready for implementation in this tool.

In addition to addition of charts (as shown in the image above), we will also support the import of a user provided vector layer into the false positive/negative layer. We want to be able to import a generic vector layer as a false positive/negative, this means checking geometry type (possibly converting into single part) and a field mapping GUI to match the imported fields with the false positive/negative fields, field types conversion could also be involved.

IMPLEMENTATION PLAN

Kartoza will add a third tabbed section to the plugin dock for listing known special areas layers. This section shall also contain some user interface controls to allow creating new layers, with a selector for the user to choose between the available layer types. Digitization of the vector features shall leverage the existing QGIS layer digitization tools. Additionally, the dialogues used for executing the indicator algorithms shall also be updated in order to allow the user to select which vector layer to use when performing a re-analysis.

[timlinux]

Please break this epic task into a series of smaller tickets and assign what you think is achievable into the milestone Creation of dataset defining special areas (polygons)

[alexbruy]

Initial work is here #553.

[timlinux]

Pending the resolution of #589, this issue can be closed

[timlinux]

Also pending #585 - @alexbruy could you take a look at that or transfer this to @gkahiu if you are not able to spend time on this?

[gkahiu]

Hi @timlinux I think this should was the one related to @alexbruy's PR.