TerraAmazon is a GIS tool designed to be a multi-user editor of geographic vectorial data.
It was developed to improve the corporate production of geographic data in order to provide an accurate measurement of deforestation, forest degradation, land use and land cover change and similar applications.
The spatial operations between vector data allow transitions analysis among other applications.
The system has a built-in structure to allow experienced users to audit the data produced. It also provides reports so Project Managers can follow and analyze the evolution of the work.
The data is stored in a TerraLib model database (www.terralib.org) and is worked within a client-server environment.
The concepts of TerraAmazon data model treated in this User´s Guide are briefly described here. The internal structure of tables is the subject of TerraAmazon Data Model.
Access Control, Users and User Groups
TerraAmazon has two user levels: Administrator and Operator. The Administrator User has full access to all the menus, while the Operator User has not. Through the definition of users, each with a cryptographic password, and user groups it is possible to control the access to different system functionalities.
Users can only be created in databases that have the conceptual model. Without it, only DBMS users have access to the database.
DBMS users open connections as Administrator Users, unless configured otherwise in the DBMS. For that reason, it is strongly advised to keep DBMS users & passwords under protection in corporate environments. This type of user is not a TerraAmazon user.
Vector layer with a different type of representation: cell. TerraAmazon requires the existence of a cell layer for project configuration and for most of the spatial operations available. There are several reasons for that:
1. Reduction of data complexity: vector data can be extremely complex since TerraAmazon allows projects to have geographic working areas of continental size. By using a cell layer, the data is cut into tiles, greatly reducing the complexity of polygons.
The left side of the following figure shows an area 175km wide in the Amazon region (Lat. -3:20 Long. -58:45) in which there are complex polygons covering large areas. The right side shows the same area cut into square tiles 28km wide by a cell layer. Even though this increases the number of polygons, their complexity is greatly reduced, resulting in a significant gain in performance.
When a cell is locked by a user for a vectorial edition, and the first polygon classification is executed, TerraAmazon stores all contents of that cell in the local computer. The changes made are stored in the database each time classification is executed.
This guarantees that only one user at a time works within the boundaries of each cell. Once that user unlocks the cell, then any other user can lock it and work on it as well. This also reduces the frequency of access to the server during work.
The entire
amount of data within the boundaries of the selected cells are first
stored in local memory at the moment of the first classification,
which occurs when the user clicks on one of the two classification
tools,
or
.
This means that if the user has 20 selected cells, the first
classification will store in local memory the contents of the 20
cells, even if they are not all being visualized in the display area.
In order to prevent that, the Administrator User must define for each
project a limit of cells to be simultaneously selected by each user.
3. Spatial operation optimization: most of the spatial operations available in TerraAmazon require that the input data is first submitted to an intersection with the cell layer. This contributes to optimizing the operation time since TerraAmazon only compares data carrying the same cell identification.
Class
Classes are the attributes that will be applied to polygons through the classification process. They can be a land cover, land use, soil typology, vegetation, climate, etc.
Classification Process
Group of procedures needed to create polygons and apply them attributes through the use of the classification tools specifically within the edition through projects.
Database
A TerraAmazon database encloses the whole set of data, either raster or vector data.
The database used by TerraAmazon has the model for storing geographical data proposed by TerraLib, inheriting its conceptual model. In TerraAmazon, the act of creating the conceptual model refers to a simple administrator procedure that results in the creation of an internal structure of tables, enabling every multi-user and project configuration (Refer to Erro: Origem da referência não encontrada, page Erro: Origem da referência não encontrada, for details on user structure change due to the conceptual model). Such procedure also involves the creation of a cell layer.
The conceptual model is not automatically created because TerraAmazon must be able to connect to databases built by other TerraFamily applications, such as TerraView, without causing them changes. For that reason, TerraAmazon requires that the conceptual model is intentionally created when needed.
In TerraAmazon the creation of the conceptual model is required only if there is the intention of performing advanced vectorial editions in the database.
If a database is created exclusively for storage and visualization, then the conceptual model is not necessary. This type of database is useful to store final products or remote sensed images to be accessed through another database for multi-user vectorial edition. Using this type of database is part of an advanced working method that has advantages when applied to corporate environments. It increases database security and decreases the total time needed for database backup.
The following figure shows a scheme of this method of working with independent TerraAmazon databases and the need of the conceptual model in each one.
Database 1 is a database storing only remote sensed images and is not meant for any sort of vectorial edition. This type of database does not need the conceptual model. The lack of the internal structure of tables built by the conceptual model is good in this case, reducing the size of the database and the time needed for backup.
Database 2 is the working database. It needs the full project configuration for multi-user advanced vectorial editions. This type of database requires the existence of the conceptual model.
Database 3 is a database created exclusively for storing the final products. This is good for organizing the data and for increasing data security. This type of database does not need the conceptual model. The lack of the internal structure of tables reduces the size of the database and the time needed for backup.
Edition Layer (or Input Layer)
Layer used as a draft in the classification process. A theme pointing to an input layer must be active to enable the edition mode. Once the user has opened the edition mode, every geometry created in it is instantly stored in the draft layer. It is necessary to trigger the classification process through one of the classification tools in order to store the classified output data in the output layer. Any vector layer containing polygons representation can be used as an input layer to the classification process until it is associated to rules or intentionally blocked by an Administrator user for data security matters.
Edition Mode
The Edition Mode
enables vectorial editions. It is enabled by clicking on the icon
having an Edition Layer active. The Main Interface changes to display
the Drawing and Classification Tools.
If there is an
active project, then the Classification tools become functional and
the classification process is executed when triggered by one of the
following tools:
or
.
The result of the classification process is stored in the Output
Layer.
If there is no active project, then only the Edition Layer can be edited and its attributes must be applied to each polygon by typing the values in the attribute pop-up interface, activated by the menu Attribute → Show Attribute Window. In this case, the classification tools are not functional and nothing happens if triggered.
Interest Area (or Area of Interest)
A spatial delimitation of a geographic area. When assigned to a project, vectorial edition can be performed only within such area.
Layer
Vector or raster data. Every vector or raster data stored in the database is presented to the user as a layer in the Layers Tree (see the main interface on page Erro: Origem da referência não encontrada).
Vector data can have three types of representation: polygons, lines or points. Inside the database, each vector layer has two tables: geometries and attributes tables. The geometries table stores the geometric information of each polygon while the attributes table stores the attributes associated to each polygon stored on the geometries table. Both tables have one column in common which is the link between them.
However, TerraAmazon SFS version has a different structure of tables for vector data: complying with the Simple Feature Specification model, geometries and attributes are stored in the same table.
Advanced: on the TerraAmazon SFS version, the table, containing geometries and attributes, has the same name as the layer. As for the other versions, the attributes table has the same name as the layer, but the name of the geometry table is composed by polygons + <layer_id>, where layer_id is found in the table te_layer or in the field Infolayer Identifier of the layer´s properties accessed by the right-click on the layer. For example, a layer with “layer_id = 3” will have a geometry table named “polygons3”.
As for raster layers, the amount of tables for each layer depends on some conditions, varying from 2 to 4 tables. Refer to TerraLib documentation for further details on tables at www.terralib.org. Raster data are stored the same way on both SFS and non-SFS versions.
Layers are visible to all users.
Output Layer
Destination layer for the resulting output of the classification process. Different classes can have different output layers. Output layers cannot be used to access the edition mode.
A phase is a stage of the vectorial edition in a project´s execution. Through the concept of phase, TerraAmazon can keep logs of the time spent in each stage, enhancing project management. A typical set of phases is to have a data production phase and a data verification phase.
Phases are related to users through user groups: every user belonging to a user group related to a certain phase can perform vectorial editions in that phase.
The following figure is an example of phase association with user groups and users.
User A is allowed to perform vectorial editions only in Data Production phase (Phase 1) since he belongs exclusively to Group 1 which is only associated to phase 1.
User B is allowed to perform vectorial editions in all phases since he belongs to both user groups.
User C is allowed to perform vectorial editions in Data Verification phase (Phase 2) and Data Correction phase (Phase 3).
As an example of this method of working with phases, a project could be executed with the following stages: User A producing the data while User C would verify the results; User B could either help User A with data production or help User C with the verification. If at some point there is the need of correcting data without stopping User A, then Users B and C could do that.
Project
In TerraAmazon, a project is a package that identifies:
the set of rules that will be active in the classification process
the classes involved
the output layers
the interest area layer and the geometries in use
the dates available for interpretation
Besides the vectorial edition through projects, no other procedure in TerraAmazon requires the existence of a project.
The following figure shows the package identified by a project.
Each project can have more than one output layer for the classification process (in this example there are two: L1 and L2).
For each output layer, a set of rules and a set of classes must be configured.
The rule can be associated to more than one output layer. In the example above, the rules R2 is associated with both output layers available. For the definition of Rule, refer to page 8.
Classes can only be associated to one output layer each. When a polygon is classified with that class, the resulting polygon will be stored in the output layer with which the class is associated. For example, if the class C1 is selected in the project presented in the figure above, the resulting geometry will be stored in the output layer L1. If, however, C4 is selected, then the output layer will be L2.
Notice that the class C5 is not used in this project. The layer L3 is not used either. Also, in the Area of Interest layer, only the first two geometries are used. This is possible because a project is composed of independent structures stored in the database. They can be associated to one or more projects.
A rule defines a spatial operation to be applied to input geometries during the classification process. The spatial operations available for rules are intersection, difference, union, identity, and areas suppression.
Scenario
A scenario is composed by an interest area and an observation date assigned to it. As an example, if a certain satellite grid is used as an interest area, then the observation date of the image to be used must be assigned to the area of interest. This is not an automatic process: it is necessary that an Administrator User assigns the correct date to the Interest Area.
A Scenario does not attach an image to an Interest Area, but an observation date.
