A Tool for Better Land Management

: The ability of keeping a record of geospatial information, knowing how it changed over time, is crucial for landscape analysis and territorial government. Land management is still a problem. Many governmental databases are incomplete, and there is a lack of reliable information. Good land management implies having a tool that can keep track of all the information available about a certain property and its changes over time. In this paper, we propose a land management tool where managers access all the information on a certain parcel of land—its boundaries, the land registration, a map which veriﬁes the landcover, and the historic of updates of territorial limits. With the proposed tool, it is possible to edit the information of any property, whether it is active or not—that is, to also edit properties that no longer exist today, but that the user wants to add information to, for legal or other reasons. Keeping track of data properties’ revision history is groundbreaking due to the fact it is not well developed in existing tools. We will look at Brazil as a use case, where land management is a critical problem.


Introduction
The information technology facilitates the development of land use systems based on the simulation of dynamic land use interactive processes [1]. There is also an increasing use of geoinformatics in the design of geoinformation systems and decision support systems for realizing sustainable land management at different scales and for specific user groups (land registry specialist, land analyst, and field inspector). A digital geoinformation infrastructure and policy framework is emerging for this purpose at global, regional, national, and local levels, as stated by Beek [2].
Consequently, land management is essential for governments and companies for keeping control of updated historical information [3]. The control of all transactions in which a property may be involved, regularization of irregular settlements and the titling of its occupants are some relevant examples. The problem is that many governmental databases are incomplete and do not contain reliable information. In addition, many of the databases do not follow the evolution of properties over time, keeping track of the data revision history and that does not allow the edition of historical spatial data.
As an example of this poor management, we used the use case of Brazil, where this problem is grave. The landowners spend a lot of time and money on registering and licensing as required by law. Normally a pile of papers and a large stack of information are required for each property. Consequently, landowners and municipal managers need a better way to make the system work to effectively manage the land. very dynamic in nature, and on the other hand requires a continuous maintenance process, the role of information technology is of strategic importance [21].
In this work, we propose a tool that allows the edition of properties' spatial data history, which it is not well developed in existing tools. What is meant by property data history is how the property has evolved over the years, since it was created and preserved all the modifications. Therefore, we can have always in the database the details of all properties in any period, so that users can consult and/or update this information.
We present a new characteristic for property history-that is, the possibility of the edition of the spatial data history, something that is not provided in the tools for better land management. The data history edition is an important feature that enables governmental databases with all the historical information about a certain property. In some cases, we have properties with incorrect data, such as the property registration year. However, it is not be possible to alter such important information, because today's databases do not allow the user edit properties' history. For example, we have a property that existed in the year 2012 and, in that year, it suffered an invasion that was not reported. If we want to report that invasion today it is not possible, because current tools do not allow the user to manage historical data. Nevertheless, this control of properties history is groundbreaking since it improves the precision and reliability of the database.
Therefore, this work aims to build an application that offers the possibility to consolidate and integrate a property database with environmental and cartographic data, using a Geographic Information System (GIS) platform [22]. We use QGIS, which is a free and open source cross-platform desktop geographic information system that supports viewing, editing, and analysis of geospatial data [6]. The objective of this work is to optimize real estate management and facilitate access to integrated data for the execution of inspection, invasion, complaints, and management of legal processes involving properties. In this way, the main objective is to solve the problems of land management, which is an evolving area and needs monitoring using digital technology. The system was developed in the MVC architectural pattern using Python with the leaflet framework and QGIS. To the best of our knowledge, there is no other methodology which allows the edition of historical geospatial information.
The remainder of this paper is organized as follows. In Section 2, we discuss related work on land management. Section 3 describes the methodology used in this work, such as the data model, the proposal for land history management problem, and an explanation about the Web application. Section 4 reports the results of the land history and some examples from the Web application and Section 5 discusses these results. Finally, Section 6 presents the conclusions and some ideas for future work.

Related Work
Practical tools which can help local users and multi-disciplinary teams work together on the land management problem at the local to regional levels have emerged only very recently. In this section, we present a summary of papers that focus on the land management problem and how to solve this problem.
Hans Hurni [23] review existing approaches for planning integrated land management vis à vis the requirements set forth by the concept of sustainable land management as it emerged from the UNCED process since the Rio conference in 1992, and propose appropriate conceptual and methodological tools in response to these requirements. The author advocates that assessment tools will require transdisciplinary methods that involve natural, social, and political sciences as well as local knowledge systems. Additionally, according to Pieri [24], there is a need to move from concepts and prescriptive approaches to an integrated approach to the physical planning and the social and institutional dimensions of land management. A specific approach has been developed for this purpose, which is called "sustainable development appraisal" (SDA). However, SDA is only a methodological tool for the participatory assessment of sustainability from local to regional planning levels [25].
The authors Laskos, Cazella, and May Rebollar [26] denote that Brazilian rural spaces play an important role in the management of environmental and social issues. Brazil has a property registration system, but it is out of date and most of the information provided is not verified. This system also leads to various frauds associated with tax payments, changes in ownership, etc. They suggest the construction of a solid database to support management institutions and notaries so that it is possible to carry out studies overtime on these same properties. Additionally, Thomson and Simpson's research [27] aims to investigate the role of historical farm management decisions in controlling the utilization of grazing resources by domestic livestock under variable environmental conditions, and the impact that these decisions have upon early farm viability and land degradation, using environmental simulation modelling. The focus for these investigations is Iceland, as an example of a place where the contemporary landscape has been extensively modified by grazing in the past. However, these works only use simulation tools.
Victorino, Amorim, and Shimabukuro [28] present the development of a WebSIG using PostgreSQL in combination with PostGIS. This application allows the land registry to obtain information of interest like consult the information about the owner, among other features. This paper also presents the relationship entity diagram, to facilitate the understanding of the application's behavior. This application aims to maintain a reliable and updated register helping in decision-making, planning, and municipal management. Although this work aims to present the main aspects involved in the development of a system that helps information sharing between the territorial land registry and property registry systems in small-and medium-sized municipalities, it does not deal with spatial historical data.
The authors in [29] discuss the importance of updating cadastral data, without losing the historical data of the cadastral databases for town planning activity. They also present an experiment, showing examples of using the database and the gvSIG tool, where through map visualization it is possible to analyze the differences from the past to the present, but it does not allow changing any information of the past data, as proposed in this work. The authors emphasize the lack of methods, viable in terms of costs and benefit, mainly those that make possible the maintenance of data history that has hindered significantly the planning activity, considering the importance of historical studies for understanding certain facts that may point to future occurrences, which our work intends to solve.
Francisco and Imai [30] mention the fact that there are still few works that discuss the representation of information space, particularly regarding the changes that occurred in the urban area. For this, they present an approach for the representation of the time-space of the land registry data used by City Halls. This approach consists of maintaining the modifications, by overlapping and adding to the object through versioning (storing the previous version) and this new version of the object is a new instance that contains the inherited properties. Nevertheless, the proposal does not implement interfaces that facilitate the use of applications for maintaining the geographic database, in order to facilitate its use by users in daily operations.
Toledo and Bertotti [31] present the development of a land management system (SIGEF) to improve the land structure in Brazil. For this operation, the data entry is made from a spreadsheet, which was duly prepared to carry out all the formatting rules required by SIGEF. This spreadsheet is sent to SIGEF, where the server checks for errors. If the process is approved, the certification of the property is immediate. The property map and the descriptive memory are created from the system itself, automatically. The certification is subject to validation by the Real Estate Registry Office, thus ending the process of certification of rural properties. The proposed system was at an early stage, still with no practical results.
Freitas and Lima [32] demonstrate the importance of GIS tools in the process of preparing descriptive plans of the plots for the purpose of land tenure regularization in a community classified as ZEIS (Space Areas of Social Interest) in Fortaleza, Brazil. The use of this tool allows obtaining a better precision in the location of the parcels in the territory of the city, the mapping of accumulated information, permitting a greater level of understanding the information contained in the database. The main contribution of this work was the introduction of spatial data in the database that contains the cadastral socioeconomic information in order to support the ZEIS planning process.
In [33], the authors present the case of Paraiba state, more specifically the municipality of Monteiro, which does not have a reliable rural registry, which occurs many times in Brazil. For this project, they use the ArcGIS tool and present the SHAPE attributes of Titled Lots. The filling of these lots was based on technical materials that they obtained. Then they used an ESRI JavaScript API, so the data could be viewed online without the need for specific software for visualization. This tool allows for a faster dissemination of information, managing technical materials more effectively, and developing a thematic map showing data properties before the certification process.
Based on complete use of mature spatial information technologies and on land use and management, Liang et al. [5] developed the Dingzhuang town information system of land resources management based on spatial data. It provides land use and management with real-time information and performs functions like property search map, map search function, visual inquiry of land information and dynamic spatial graphic data. The basic functions of this system include land use planning, basic farmland management, the management of land for construction use, land survey, land registration and so on. Besides, it realizes the basic land management of each patch in the village and town level, as well as property search map and map search function.
Mondal et al. [21] present a study that develops a case study of land information system using cadastral techniques of Tirat and Chalbalpur rural region of Raniganj in Barddhaman district of India, which contains cadastral information. The final goal was to generate digital maps which will facilitate land management and planning and in particular land registration and the issuance of land titles in order to promote security of land tenure and reduce land disputes, such is the use case of Brazil, used in our work.
Recently, Mishra et al. [34] published a study based on remote sensing (RS) and geographic information system (GIS) techniques, to monitor the changes in land use and land cover patterns of Rani Khola watershed of Sikkim Himalaya for the periods 1988-1996, 1996-2008 and 2008-2017. The result of this study reveals that the major land use in the watershed is forestry. Due to massive afforestation program, declaration of Sikkim as organic state (2005), stringent law enforcement in forestry sector and sustainable agroforestry systems the area under dense forest has increased by 16.4% between 1988 and 2017. This study utilizes the RS and GIS approach which is one of the most prominent technology at present for spatio-temporal analysis. That is possible through other conventional mapping techniques. The analysis and findings of the study have important policy implications for the sustainable land-use/cover practices in the Sikkim Himalaya.
Many of the aforementioned papers present an approach to poor land management, through the use of GIS, to assist and improve the way in which information will be used and stored. However, a few propose solutions for maintaining the property data history. Our work has these two objectives combined, proposing a new approach to properties spatial data history manipulation using QGIS with a Web application.

Methodology and Tools
This section describes the methodology and the tools used for the creation of the Web application, the database, and the proposal to deal with property data history. The creation of this Web application was done using Python and Flask, a small web framework written in Python and based on the WSGI Werkzeug library and the Jinja2 library. Flask has the flexibility of the Python programming language and provides a simple model for web development). In order to view the properties on the Web, Leaflet [35] was used, that is a JavaScript library specialized in visualizing geographic data on the Web.
The database used for the application was PostgreSQL since the QGIS already has an extension for this database. We also describe how the property history method works, and the lack of existing proposals on the market to deal with this problem.
In Figure 1 we can see the architecture of the tool. The Web application follows a normal Model-View-Controller (MVC) structure. In the model, we can see some of the most important classes of the Web application: Property, Beneficiary, etc. The model communicates with PostgreSQL to access the data and each task done by the user is saved in the database. The PostgreSQL database also communicates with QGIS, where we can see the representation of the data in a more informal way. All the actions that the user performs in QGIS are also saved in the database. The communication between the Web application and QGIS is via the database, because when a property is created in QGIS and we want to visualize in the web application, first we have to save it in the database and then access the web application that extracts the property data from the database.
Information 2020, 11, x FOR PEER REVIEW 6 of 17 communicates with QGIS, where we can see the representation of the data in a more informal way. All the actions that the user performs in QGIS are also saved in the database. The communication between the Web application and QGIS is via the database, because when a property is created in QGIS and we want to visualize in the web application, first we have to save it in the database and then access the web application that extracts the property data from the database.

Property History in Software Tools
One of the problems that this work intends to solve is the edition of properties' historical data. The history of a property over time consists of knowing how it has evolved over the years since creation and maintaining the respective details of the modifications. In addition to being able to maintain the historical data of the properties, it should also be possible to edit this history, that is, it should be viable to edit a property that no longer exists today, but that the user wants to add some information for example property registry date.
QGIS is a free and open source Geographic Information System (GIS) application that was used to achieve the proposal for the property history problem. We use QGIS because is one of the best tools for dealing with geographic data, as described in [36]. One of our goals was to find one solution for the property history problem using a tool as good as the commercial ones in the market (e.g., ArcGIS [37]) but without acquisition costs. ArcGIS is a GIS for working with maps and geographic information maintained by the Environmental Systems Research Institute (ESRI). It is used for creating and using maps, compiling geographic data, analyzing mapped information, sharing and discovering geographic information, using maps and geographic information in a range of applications, and managing geographic information in a database. Other platforms were tested, such as gvSIG [38] and Google Earth Pro [39] but they do not have the core functionalities of dividing and joining properties.
QGIS was the best tool since it offers the divide and join functionalities under a simple and intuitive design. However, this platform did not have the ability to deal directly with the property historical data. Then, to solve this problem, we propose a method using the existing functionalities. QGIS had already the functionalities to divide and join properties, but when we edit a property QGIS does not save the previous version, it is always portraying the same version. Therefore, by using the copy function given by QGIS we have a solution for saving historical property data.
The method for property history edition consists of the following: we have a property in the

Property History in Software Tools
One of the problems that this work intends to solve is the edition of properties' historical data. The history of a property over time consists of knowing how it has evolved over the years since creation and maintaining the respective details of the modifications. In addition to being able to maintain the historical data of the properties, it should also be possible to edit this history, that is, it should be viable to edit a property that no longer exists today, but that the user wants to add some information for example property registry date.
QGIS is a free and open source Geographic Information System (GIS) application that was used to achieve the proposal for the property history problem. We use QGIS because is one of the best tools for dealing with geographic data, as described in [36]. One of our goals was to find one solution for the property history problem using a tool as good as the commercial ones in the market (e.g., ArcGIS [37]) but without acquisition costs. ArcGIS is a GIS for working with maps and geographic information maintained by the Environmental Systems Research Institute (ESRI). It is used for creating and using maps, compiling geographic data, analyzing mapped information, sharing and discovering geographic information, using maps and geographic information in a range of applications, and managing geographic information in a database. Other platforms were tested, such as gvSIG [38] and Google Earth Pro [39] but they do not have the core functionalities of dividing and joining properties.
QGIS was the best tool since it offers the divide and join functionalities under a simple and intuitive design. However, this platform did not have the ability to deal directly with the property historical data. Then, to solve this problem, we propose a method using the existing functionalities. QGIS had already the functionalities to divide and join properties, but when we edit a property QGIS does not save the previous version, it is always portraying the same version. Therefore, by using the copy function given by QGIS we have a solution for saving historical property data.
The method for property history edition consists of the following: we have a property in the database that we are going to edit, but we want to keep all the information of this property. In the QGIS tool, we select the property and create a copy, which will be automatically added to the database. In order to keep the history, we will make our changes to the copy which, after being edited, will be the Information 2020, 11, 0554 7 of 17 most recent version of the property. If we want to make a division, we use a functionality offered by QGIS that allows making cuts in the property. These cuts will give rise to new properties that have their data equal to the property that originated them. If we want to make a join, we must select properties that have intersecting parts (vertices or edges). The join is made through a functionality offered by QGIS. The same happens with the division, the parameters must then be edited. By following these steps, it is possible to maintain the property historical data over time without losing information.
Through this method, we can maintain the history of a property over time. For distinguishing these properties, the parent-child attributes, such as the creation date, will be used, or an attribute that indicates which one is the parent property of the respective selected property.
Nevertheless, the property history problem persists in the Web application. The divide and join functionalities must be executed within QGIS since these two functions deal with editing the design of the property. But all other actions involving the property must be kept in the database keeping the history of the property. When we have a property and we want to associate a complaint (or other action such as an invasion, beneficiary, impacted, inspection or litigation or make another transaction, such as a purchase, sale, transfer, expropriation, purchase of installment, easement, regularization) about that referred property, we have to follow the same idea described previously. We create a copy of the property and this copy will have the same data as the previous property, but with the complaint associated with this copy. In the Web application, users do not need to make a copy, because this action will be done automatically by the application. With that, the user will know when the property had the complaint and when it did not. The reasoning is the same as the division and join of properties. We will always have the property history, whatever the change made in the property.
This problem was partially solved by ArcGIS, another platform comparable to QGIS, and the most used in this area. ArcGIS presents a solution called Archive [40] where it is possible to store properties in a table as they change over time. The problem with this solution is that it does not allow older properties to be edited. That is, if in the future we want to associate a document with a property that no longer exists, it is not possible to do so. Actually, ArcGIS is the only tool that manages the objective of the real estate history, despite not being completely efficient. The proposed solution allows us to do what ArcGIS does, but with the possibility to edit older versions of the properties to achieve a consistent database.
The proposed tool is more complete than that of ArcGIS due to the fact that we can edit older properties and associate any type of information with them and not just the most recent properties, those that currently exist. Thus, it is possible to create a complete and reliable database.

Web Database
In this section, we describe the database that is used in the Web application. Figure 2 illustrates the entity-relationship model (or ER model). For readability reasons, this figure only shows the names of tables but not its contents.
The most important tables for the operation of the application are the following:  Table, where each record represents a document. • Litigation: This table stores each possible record of litigation or pre-litigation; the type of record is identified by a LitigationDegree field. A litigation can be generated from a complaint (Complaint Table), an inspection (Inspection Table) or an invasion (Invasion Table).  Table) and the type of record will be given by the LitigationDegree field. For each invasion, the registration of Invaders must take place and will be stored in the Invader Table. The occurrences are also recorded in the InvasionOccurrence Table. • Complaint: This table stores each possible claim for a property. Each claim may have a litigation or pre-litigation one (Litigation Table), the type of record will be given by the LitigationDegree field and each complaint is in the Complaint Table. Through this method, we can maintain the history of a property over time. For distinguishing these properties, the parent-child attributes, such as the creation date, will be used, or an attribute that indicates which one is the parent property of the respective selected property.
Nevertheless, the property history problem persists in the Web application. The divide and join functionalities must be executed within QGIS since these two functions deal with editing the design of the property. But all other actions involving the property must be kept in the database keeping the history of the property. When we have a property and we want to associate a complaint (or other action such as an invasion, beneficiary, impacted, inspection or litigation or make another transaction, such as a purchase, sale, transfer, expropriation, purchase of installment, easement, regularization) about that referred property, we have to follow the same idea described previously. We create a copy of the property and this copy will have the same data as the previous property, but with the complaint associated with this copy. In the Web application, users do not need to make a copy, because this action will be done automatically by the application. With that, the user will know when the property had the complaint and when it did not. The reasoning is the same as the division and join of properties. We will always have the property history, whatever the change made in the property.
This problem was partially solved by ArcGIS, another platform comparable to QGIS, and the most used in this area. ArcGIS presents a solution called Archive [40] where it is possible to store properties in a table as they change over time. The problem with this solution is that it does not allow older properties to be edited. That is, if in the future we want to associate a document with a property that no longer exists, it is not possible to do so. Actually, ArcGIS is the only tool that manages the objective of the real estate history, despite not being completely efficient. The proposed solution allows us to do what ArcGIS does, but with the possibility to edit older versions of the properties to achieve a consistent database.
The proposed tool is more complete than that of ArcGIS due to the fact that we can edit older properties and associate any type of information with them and not just the most recent properties, those that currently exist. Thus, it is possible to create a complete and reliable database.

Web Database
In this section, we describe the database that is used in the Web application. Figure 2 illustrates the entity-relationship model (or ER model). For readability reasons, this figure only shows the names of tables but not its contents.

Web Application
This section describes how the Web application operates and the communication with QGIS through the PostgreSQL database. The Web application was developed in Python + Flask and Leaflet for viewing properties on the Web. In the application, it is where we optimize real estate management, enabling access to integrated data for the execution of inspection, invasion, complaints, and management of legal processes involving real estate. Thus, it is possible to associate the documents with the properties, maintaining a useful land management, with all data stored in the database. The properties are created in QGIS, which are automatically saved in the database. When we access the application, it is possible to perform various operations, since the completion of the property registration or associate documents to properties (e.g., inspection documents, complaints, invasions and others).
The Web application has the following functionalities: • Access the properties in the database and visualize them in the Web; • Complete the registration of a property; • View the property history, for example, which are the child properties and the parent property; • Create a Beneficiary, an Impacted, a Destination, a Litigation, a Complaint, an Invasion, a Transaction (expropriation, transfer, purchase, sale, purchase of remaining installment, easement, and regularization) and an Inspection; • Associate documents to a property; • Associate documents to a Beneficiary, an Impacted, a Destination, a Litigation, a Complaint, an Invasion, a Transaction, and an Inspection; • When we create an Invasion, it is also possible to create the Invaders and the Goods involved in the process.
All these actions are performed inside the Web application, which creates a history, i.e., a version of each modification that is applied to a property. The application allows the user to select any property that exists in the database, where this property can be an old version or the most recent version.
When we select and perform an action, for example create a beneficiary, to create the history, we need to create a new version of the property and not update the current version. For this, we create a copy of the property and add it to the database. This duplicated version of a property has a different ID and the origin parameter has the name of the copied property, in order to know who is the father's property. After creating the duplicate, a copy of all property information is added to the duplicate.
The duplication method occurs in the Web application, that creates the duplicate and add it to the database. After adding the duplicate to the database, all the information related to the property (Beneficiary, Impacted, Destination, Litigation, Documents, ThirtyCM, Complaint, Transaction, Invasion, Inspection) is included.

Experimental Results
This section shows some of the functionalities of the Web application, including examples of land history. Figure 3 shows an example of the history of a property presented in the database. In Figure 3 the original property was FozDeArouce (id = 1). Later, this property experienced a division giving rise of two properties: Imovel1 and Imovel2. One of these properties, Imovel2, after some time also suffered a division resulting in two other properties: Imovel3 and Imovel4. Imovel4 go through a division resulting on two other properties: Imovel5 and Imovel6. After, Imovel5 and Imovel6 were merged to form Imovel7, which is also merged with Imovel3 to form Imovel8. Then, Imovel8 is merged with Imovel2 giving rise to Imovel9, that after is divided originating Imovel10 and Imovel11. Finally, Imovel10 suffered another division that gives origin to Imovel12 and Imovel13.

Analysis of the History of Properties
Through the processes of division and union, there exist always an edition of the properties created from the mentioned actions. The reason is because the properties that are created always copy the data of the origin property. Other information must be entered, which distinguishes between the parent property from the child property. This copy is mandatory because the QGIS functionalities used for division and union do not allow to reverse these operations.

Experimental Results
This section shows some of the functionalities of the Web application, including examples of land history.

Analysis of the Web Application
In this section, we present some examples of the operations that can be done through the Web application.

Property
In Figure 4 it is possible to see what is presented in the Web application when selecting a property.
Information 2020, 11, x FOR PEER REVIEW 10 of 17 In Figure 3 the original property was FozDeArouce (id = 1). Later, this property experienced a division giving rise of two properties: Imovel1 and Imovel2. One of these properties, Imovel2, after some time also suffered a division resulting in two other properties: Imovel3 and Imovel4. Imovel4 go through a division resulting on two other properties: Imovel5 and Imovel6. After, Imovel5 and Imovel6 were merged to form Imovel7, which is also merged with Imovel3 to form Imovel8. Then, Imovel8 is merged with Imovel2 giving rise to Imovel9, that after is divided originating Imovel10 and Imovel11. Finally, Imovel10 suffered another division that gives origin to Imovel12 and Imovel13.
Through the processes of division and union, there exist always an edition of the properties created from the mentioned actions. The reason is because the properties that are created always copy the data of the origin property. Other information must be entered, which distinguishes between the parent property from the child property. This copy is mandatory because the QGIS functionalities used for division and union do not allow to reverse these operations.

Analysis of the Web Application
In this section, we present some examples of the operations that can be done through the Web application.

Property
In Figure 4 it is possible to see what is presented in the Web application when selecting a property. As we can see in Figure 4, the Web application presents a table with the parameters related to property different buttons and a map with the visualization of the property. The buttons have the following functionalities: Complete Registration that allows us to complete the registration of the property; Property History to see the property history in more detail; Delete button that removes the property; Complete Visualization allows us to see all the information related with the property. The Beneficiary, Impacted, Destination, Litigation, Documents, and Thirty CM buttons redirect the user As we can see in Figure 4, the Web application presents a table with the parameters related to property different buttons and a map with the visualization of the property. The buttons have the following functionalities: Complete Registration that allows us to complete the registration of the property; Property History to see the property history in more detail; Delete button that removes the property; Complete Visualization allows us to see all the information related with the property. The Beneficiary, Impacted, Destination, Litigation, Documents, and Thirty CM buttons redirect the user to the respective pages where it is possible to view a table of each one.   and Child shows what properties it has originated (child property (s)). A map with the selected property is also presented and when we click on the view button it is possible to view the respective property on the same map. In this example, the property in purple is the property called Imovel1. The properties of the same family will have the same Code. If we select a property, in this case  shows what properties it has originated (child property (s)). A map with the selected property is also presented and when we click on the view button it is possible to view the respective property on the same map. In this example, the property in purple is the property called Imovel1. The properties of the same family will have the same Code. If we select a property, in this case "FozDeArouce", we will look at the Origin to see whether the name of the parent is written on it. In this case it did not have a name, so this means this property is the original one. In order to see if this property has originated some children, we look at the properties with the same Code and see if the Origin name in those properties is the same of "FozDeArouce" and, if it is, then we have its children.

Beneficiary
In Figure 6, it is possible to see the process of creating a beneficiary, as well as viewing the respective table of beneficiaries of a given property. Here, we see how the property history is preserved in the Web application. In Figure 6, it is possible to see the process of creating a beneficiary, as well as viewing the respective table of beneficiaries of a given property. Here, we see how the property history is preserved in the Web application. The preservation of the property history remains in the Web application. In this example, we selected the property "Serpins", with the objective to create a new beneficiary for this property, so we select the Beneficiary button in Figure 6. This action redirects the user to a new page where we can see that property "Serpins" already as one beneficiary as shown in Figure 7. For adding a new beneficiary, we must fill a form as shown in Figure 8 and click in the "Add Beneficiary" button. We need to create the history for every action that is done to this property (ID = 497), having each version of this property stored in the database. When we edit a property, the history must be preserved, so we can have a "picture" of the property at any time. All the actions done in the Web application will continue the pursuit of creating a history for all properties stored in the database. The preservation of the property history remains in the Web application. In this example, we selected the property "Serpins", with the objective to create a new beneficiary for this property, so we select the Beneficiary button in Figure 6. This action redirects the user to a new page where we can see that property "Serpins" already as one beneficiary as shown in Figure 7. For adding a new beneficiary, we must fill a form as shown in Figure 8 and click in the "Add Beneficiary" button.
We need to create the history for every action that is done to this property (ID = 497), having each version of this property stored in the database. When we edit a property, the history must be preserved, so we can have a "picture" of the property at any time. All the actions done in the Web application will continue the pursuit of creating a history for all properties stored in the database.
Therefore, after we create the new Beneficiary, it is not added to the table Beneficiary of the property "Serpins" with the ID = 497. To create a history, we duplicate the property (ID = 497) with all the information this property and add the new beneficiary to the duplicate. Figure 9 shows the duplicate created with the same name "Serpins" but with a new ID = 498. In Figure 10, we can see that the duplicate has a new Beneficiary. When we duplicate the property to create a new one with newly added information, everything that the property has, like beneficiaries, destinations and other are copied to the duplicate and the new information is added. Thus, in this example, the property with the ID = 497 has one beneficiary, and when we created a new beneficiary, the Web application created a duplicate of the property 497 and add the new beneficiary in the duplicate. In the database, we have the version of the property (ID = 497) with one beneficiary and the other version (ID = 498) with two beneficiaries. The preservation of the property history remains in the Web application. In this example, we selected the property "Serpins", with the objective to create a new beneficiary for this property, so we select the Beneficiary button in Figure 6. This action redirects the user to a new page where we can see that property "Serpins" already as one beneficiary as shown in Figure 7. For adding a new beneficiary, we must fill a form as shown in Figure 8 and click in the "Add Beneficiary" button. We need to create the history for every action that is done to this property (ID = 497), having each version of this property stored in the database. When we edit a property, the history must be preserved, so we can have a "picture" of the property at any time. All the actions done in the Web application will continue the pursuit of creating a history for all properties stored in the database. Therefore, after we create the new Beneficiary, it is not added to the table Beneficiary of the property "Serpins" with the ID = 497. To create a history, we duplicate the property (ID = 497) with all the information this property and add the new beneficiary to the duplicate. Figure 9 shows the duplicate created with the same name "Serpins" but with a new ID = 498. In Figure 10, we can see that the duplicate has a new Beneficiary. When we duplicate the property to create a new one with newly added information, everything that the property has, like beneficiaries, destinations and other are copied to the duplicate and the new information is added. Thus, in this example, the property with the ID = 497 has one beneficiary, and when we created a new beneficiary, the Web application created a duplicate of the property 497 and add the new beneficiary in the duplicate. In the database, we have the version of the property (ID = 497) with one beneficiary and the other version (ID = 498) with two beneficiaries.  Therefore, after we create the new Beneficiary, it is not added to the table Beneficiary of the property "Serpins" with the ID = 497. To create a history, we duplicate the property (ID = 497) with all the information this property and add the new beneficiary to the duplicate. Figure 9 shows the duplicate created with the same name "Serpins" but with a new ID = 498. In Figure 10, we can see that the duplicate has a new Beneficiary. When we duplicate the property to create a new one with newly added information, everything that the property has, like beneficiaries, destinations and other are copied to the duplicate and the new information is added. Thus, in this example, the property with the ID = 497 has one beneficiary, and when we created a new beneficiary, the Web application created a duplicate of the property 497 and add the new beneficiary in the duplicate. In the database, we have the version of the property (ID = 497) with one beneficiary and the other version (ID = 498) with two beneficiaries.

Discussion
When the properties are created in QGIS, they are automatically saved in the database that is linked to the Web application, which allows us to include more information in the properties.
The examples of the Web application show some of the aspects that the Web part contains, where site pages' follow the same basic principles. A table is visible ever it is possible to present the content to the user (Land Registry Specialist). If the user needs to add new content, he or she must fill in a form, and it is also possible to delete a property content. All data filled in the respective forms must be filled in by Land Registry Specialist to assure the veracity of the database.
The Web application allows actions such as associating inspections, complaints, intrusions, among others, to be associated with the respective properties, whether these are recent or properties that have already existed, but that no longer exist today. Although they do not exist, it is possible to associate information to them that may help in legal processes or just in market studies.
The proposal to the property history also deeply depends on the user's performance. In the example discussed in Section 3.2, union and division actions require the user to fill in many of the fields of the new created properties. In a division, the user must enter the same data found in the originated properties, and indicate the origin property that suffered division. This proposal requires the user to do all these steps correctly to maintain a history that corresponds to reality.
When there is an addition, the process is similar to a division, and all the history is preserved if the user will enter the correct data. These actions must be accomplished with the user responsibility of the user, retaining the desired quality of the database, but needs a minimum knowledge in the topic.
In order to preserve the property history solution in QGIS, the Web application must also create a history for all these actions. Every information that is included in a property, will create an automatic copy of the old property, and this new information is added to the copy property.
These properties modifications can be done in the Web application and in QGIS. Thus, we can edit all properties in the database, and the modifications are added to the property history. All actions create a history version of a property in the database.
The three components (Database, QGIS, and Web application) are interconnected materializing a support tool for land management. With QGIS, we create and edit properties, following the right steps to maintain the history of these properties, which are automatically saved in the database. After using QGIS, we can complete the information associated with the properties by going to the Web application and adding information to the properties, which supports the history. Everything the user does within the site will create a history, and the user will know the evolution of the property over time. These three interconnected components comprise a tool for better land management.

Conclusions and Future Work
In this work, we propose an approach that solves the property history problem keeping the historical data in the database. The proposed tool consists of three components: (i) the Web application, (ii) the database, and (iii) QGIS. These three modules form the solution to the property history problem. The database stores all the information created in the tool and QGIS allows the

Discussion
When the properties are created in QGIS, they are automatically saved in the database that is linked to the Web application, which allows us to include more information in the properties.
The examples of the Web application show some of the aspects that the Web part contains, where site pages' follow the same basic principles. A table is visible ever it is possible to present the content to the user (Land Registry Specialist). If the user needs to add new content, he or she must fill in a form, and it is also possible to delete a property content. All data filled in the respective forms must be filled in by Land Registry Specialist to assure the veracity of the database.
The Web application allows actions such as associating inspections, complaints, intrusions, among others, to be associated with the respective properties, whether these are recent or properties that have already existed, but that no longer exist today. Although they do not exist, it is possible to associate information to them that may help in legal processes or just in market studies.
The proposal to the property history also deeply depends on the user's performance. In the example discussed in Section 3.2, union and division actions require the user to fill in many of the fields of the new created properties. In a division, the user must enter the same data found in the originated properties, and indicate the origin property that suffered division. This proposal requires the user to do all these steps correctly to maintain a history that corresponds to reality.
When there is an addition, the process is similar to a division, and all the history is preserved if the user will enter the correct data. These actions must be accomplished with the user responsibility of the user, retaining the desired quality of the database, but needs a minimum knowledge in the topic.
In order to preserve the property history solution in QGIS, the Web application must also create a history for all these actions. Every information that is included in a property, will create an automatic copy of the old property, and this new information is added to the copy property.
These properties modifications can be done in the Web application and in QGIS. Thus, we can edit all properties in the database, and the modifications are added to the property history. All actions create a history version of a property in the database.
The three components (Database, QGIS, and Web application) are interconnected materializing a support tool for land management. With QGIS, we create and edit properties, following the right steps to maintain the history of these properties, which are automatically saved in the database. After using QGIS, we can complete the information associated with the properties by going to the Web application and adding information to the properties, which supports the history. Everything the user does within the site will create a history, and the user will know the evolution of the property over time. These three interconnected components comprise a tool for better land management.

Conclusions and Future Work
In this work, we propose an approach that solves the property history problem keeping the historical data in the database. The proposed tool consists of three components: (i) the Web application, (ii) the database, and (iii) QGIS. These three modules form the solution to the property history problem. The database stores all the information created in the tool and QGIS allows the editing of properties, maintaining their history. In the Web application, it is possible to add information to the properties created in QGIS, while maintaining a history of all the actions made in the application for a specific property. The main contribution of this work is that, besides preserving the history of properties, it is possible to edit this history-that is, to edit properties that no longer exist today, but that the user wants to add information to, for legal reasons or other. This edition of properties history is innovative due to the fact it is not developed in other projects.
As future work, we intend to improve the Web application, such as the aesthetics of the Web application, making all Web pages responsive, adding security to the Web application, and improving the forms. In addition, we want to explore the QGIS tool in detail to make the tool even easier.