New rules for the Topology Framework in gvSIG Desktop ( GSoC 2020 )

Project
Project carried out within the program Google Summer of Code 2020.

Title: New rules for the Topology Framework in gvSIG Desktop.

Student: Mauro Carlevaro.

Mentors: Carlos Colombana, Óscar Martínez.

Repository: https://github.com/Maureque/GSoC2020-topology-osgeo-gvsig

Página Wiki habla Hispana.

Pagina Wiki in Italiano.

Wiki page in English.

Brief Description
Automate tasks and Ensure Information Quality instead of spending our time doing what a machine.

A topology toolbox has been added to gvSIG Desktop. This tool provides a group of integrity rules that check the validation of the geometries relationship in the data. A new topology data model can be created for each project. This toolbox provides a set of tools to navigate, find, and fix validation errors different from each topology rule. There is a set of topology rules implemented, most of them at GSoC 2019. This project will analyze, implement, and optimize a new set of rules that will be incorporated into this framework. These tools can be created in Java or in Jython through the Scripting composer tool.

State of the Project Before GSoC.
Initially, only a few topology rules have been implemented, most of them are still pending to be developed. In GSoC 2019 several rules were added which give an important base set to the framework. These rules verify and validate the relationship between geometries and data.

In the present the rules already developed are:
 * Must not overlap (Must not overlap polygon).
 * Contains null
 * Contains point
 * Must be coincident with
 * Must be covered by endpoint of
 * Points must be covered by line
 * Must be properly inside polygons
 * Must be disjoint
 * Must not have dangles
 * Must be larger than cluster tolerance

Link to the project carried out in Google Summer of Code 2019

Google Summer of Code 2019 - Página Wiki habla Hispana.

Google Summer of Code 2019 - Pagina Wiki in Italiano.

Google Summer of Code 2019 - Wiki page in English.

Link to the repository 2019.

The addition that the project brings to the software.
A new set of topology rules for vector datasets validation and fixing, that will improve, expand the existing one, and expand the actions implemented by the rules.

Rules to develop in the 2020 edition: The project documentation since the 2019 edition is being developed in English, Spanish and Italian, in order to achieve more interaction with the community and make it easier that more people use the tools, developed and from these continue growing.
 * Must be covered by boundary of.
 * Must not overlap with (Must not overlap line).
 * Must not have gaps.
 * Must be inside (line).
 * Must not intersect (line).
 * Must not intersect with (line).

How the topology framework works.
The following video shows the interface and how the topology framework works: VIDEO

Video published in blog gvSIG, link: https://blog.gvsig.org/2019/02/12/towards-gvsig-2-5-topology/

Deploy Manual and Getting Started.
The steps of how to perform the installation process are detailed in the document: Topology Rules for gvSIG Desktop: Development guide

There is also useful information on how to start, prerequisites, installation and tutorials in New rules for the Topology Framework in gvSIG Desktop

Deliverables
A new set of topology rules for vector datasets validation/fixing, that will improve and expand the existing one:
 * Must be covered by boundary of.
 * Must not overlap with (Must not overlap line).
 * Must not have gaps.
 * Must be inside (line).
 * Must not intersect (line).
 * Must not intersect with (line).

Pre-Bonding Period (March 16th - May 03rd)

 * Set up a working environment, choose tools to be used in the project, and set up the repository.
 * Familiarize more deeply with the community.
 * Review and learn as much as possible about Python, Jython, and Java.
 * Test the topology plugin and study the code of some rules that are already made.
 * Define all actions to develop for each rule.
 * Optimize the timeline and study if it is possible to include more to develop.

Community Bonding Period (May 04th - May 31st)

 * Familiarize more deeply with the code, with the mentors of the project and with the documentation.
 * Study more deeply the Topology Framework API.
 * Study the algorithm for a correct implementation according to the established rules and actions.
 * Set up the development environment.
 * Interact with mentors, introduce myself to the community, and actively get involved in the discussion.
 * Set up the wiki and repository page to keep track of weekly progress.
 * Introduce myself and the project on OSGeo's SOC mailing list.
 * Improve in the creation of scripts.
 * Report of what was done in the Community Bonding Period.

First Evaluation Period (June 01st - June 28th)
√ Topological rule: Must be covered by boundary of. √ Analyze, design and develop required Classes. √ Analyze, design and develop interactions with data sources. √ Weekly report.
 * Week 1 (June 01st - June 07th)

√ Test and debug the developed code. √ Test and document the existing code more thoroughly. √ Weekly report.
 * Week 2 (June 08th - June 14th)

√ Improvements in the rule of the week 1: Topological rule: Must be covered by boundary of. I detail some of the most important changes: √ Actions developed: Delete Point Action Mark Point Action √ Added the possibility to pass the error characteristic (feature2). √ Improved for the use of the expression constructor. √ Topological rule: Must not overlap with (Must not overlap line). √ Actions developed: Delete Line Action Mark Line Action √ Analyze, design and develop required Classes. √ Analyze, design and develop interactions with data sources. √ Weekly report.
 * Week 3 (June 15th - June 21st)
 * Week 4 (June 22nd - June 28th)

√ Improvement of the developed code for the rule Must not overlap with. √ Test and debug the developed code. √ Test and document the existing code more thoroughly. √ Weekly report.

June 29th (beginning)- July 03rd (deadline).

 * √ Submit Evaluations.

Second Evaluation Period (June 29th - July 31st)
√ Topological rule: Must not have gaps. √ Analyze, design and develop required Classes. √ Analyze, design and develop interactions with data sources. √ Weekly report.
 * Week 5 (June 29th - July 05th)

√ Test and debug the developed code. √ Test and document the existing code more thoroughly. √ Weekly report.
 * Week 6 (July 06th - July 12nd)

√ Topological rule: Must be inside (line). √ Analyze, design and develop required Classes. √ Analyze, design and develop interactions with data sources. √ Weekly report.
 * Week 7 (July 13rd - July 19th)

√ Developed action Mark Line Action. This action makes a new layer with red lines marks which corresponds to the lines selected in the error report. The action marks the errors in a clear visual way, then the user must choose what to do with them. √ Test and debug the developed code. √ Test and document the existing code more thoroughly. √ Improvements in the rule of the week 5: “Must not have gaps”. √ Weekly report.
 * Week 8 (July 20th - July 26th)

July 27th (beginning)- July 31st (deadline).

 * √ Submit Evaluations.

Third Evaluation Period (August 01st - August 31st)
√ Topological rule: Must not intersect (line). √ Finish documenting everything done with the rule Must Not Have Gaps. √ Analyze, design and develop required Classes. √ Analyze, design and develop interactions with data sources. √ Weekly report.
 * Week 9 (July 27th - August 02nd)

√ Finish the implementation of the "Mark Line Action" of the rule Must not intersect (line). √ Implementation of a new mark action: "Mark Point Action" and document it. √ Test and debug the developed code. √ Test and document the existing code more thoroughly. √ Weekly report.
 * Week 10 (August 03rd - August 09th)

√ Topological rule: Must not intersect with (line). √ Analyze, design and develop required Classes. √ Analyze, design and develop interactions with data sources. √ Weekly report.
 * Week 11 (August 10th - August 16th)

√ Finish the implementation of the "Mark Line Action" and the "Mark Point Action" of the rule Must not intersect with (line). √ Test and debug the developed code. √ Test and document the existing code more thoroughly. √ Weekly report.
 * Week 12 (August 17th - August 23rd)

√ Final optimizations. √ Release of each rule. √ Final Report √ Submit the developed code and documentation. √ Submit Final work product and evaluations.
 * Final Project Week - August 24th (beginning)- August 31st (deadline).

Weekly Reports
Section for listing the links to the weekly reports.
 * COMMUNITY BONDING PERIOD (May 27th - June 23rd).
 * Report Week 1 (June 01st - June 07th).
 * Report Week 2 (June 08th - June 14th).
 * Report Week 3 (June 15th - June 21st).
 * Report Week 4 (June 22nd - June 28th).
 * Report Week 5 (June 29th - July 05th).
 * Report Week 6 (July 06th - July 12nd).
 * Report Week 7 (July 13rd - July 19th).
 * Report Week 8 (July 20th - July 26th).
 * Report Week 9 (July 27th - August 02nd).
 * Report Week 10 (August 03rd - August 09th).
 * Report Week 11 (August 10th - August 16th).
 * Report Week 12 (August 17th - August 23rd).
 * Final report (August 24th - August 31st).

Releases

 * Must be covered by boundary of.
 * Must not overlap with (Must not overlap line).
 * Must not have gaps.
 * Must be inside (line).
 * Must not intersect (line).
 * Must not intersect with (line).

Testing Plan
The objective of the Testing Plan is to find errors from the early stages of development. To achieve this, the development is tested in each sprint, therefore, it will be carried out throughout the development of the project. At the end of each sprint, a test version of the project is available.

Tests will be carried out with different types of amounts, features and entities in the layers. Black box. The study is carried out from the point of view of the inputs and outputs. The internal structure, design and implementation of the item being tested are not known to the tester.

White box. The purpose is to check the execution flows in each unit. The tester chooses different input values to examine the possible execution flows and make sure that the correct output values are returned. It is a method of software testing that tests internal structures.

The tests provide valuable information to define the quality of the product in each sprint and check which ones must be fixed.

Student Information
I am interested in automating procedures and business intelligence so that people can handle tasks that add value to them, instead of doing repetitive tasks, I think that this helps in improving the quality of life. I believe that to achieve the best results it is essential to integrate work teams with people of great human value, for me, it is important to always continue learning, be happy working and contribute so that others are too. I am passionate about traveling and knowing different cultures.

School and Degree:
 * Technological University (UTEC, Fray Bentos, Uruguay), Student of Bachelor of IT (2019-2022).
 * University of Engineering (ORT, Montevideo, Uruguay), Programmer Analyst (2014-2018).
 * University of Engineering (UdelaR, Montevideo, Uruguay), Cartographic Technician (2013-2016).

Computing experience
I have been working as a web developer and implementing geographic information systems. The technologies that I work with daily are Java, Python, MySQL, PostgreSQL/PostGIS, Apache Tomcat and GeoServer.

GIS experience as a user
I have experience using gvSIG and QGIS. Thematic cartography course (Uruguay edition), dictated by The National Geographic Institute and the National Geographic Information Center of Spain. 40 hours of duration. Participation in the webinar “gvSIG applied to wildlife and protected natural spaces", on October 14, 2014, made by MundoGEO and Asociación gvSIG, with 60 minutes duration.

GIS programming

 * Colombana, Carlos. 5th gvSIG Uruguay Conference. The material of the lecture and workshop "Scripting: Exprimiendo / Extendiendo gvSIG", 2018. [online]. Available: http://www.gvsig.com/es/eventos/jornadas-uruguay/2018/comunicaciones/-/asset_publisher/zAf8UO2Aurwr/content/taller-2-scripting-exprimiendo-extendiendo-gvsig?
 * Scripting in gvSIG. I learned about scripting studying the material of the “Introduction to Scripting in gvSIG 2.1” (2014 ed.) MOOC, this course was offered by the gvSIG Association. This course was useful for me as started point to continue practicing. Available: https://blog.gvsig.org/2014/10/30/curso-introduccion-a-scripting-en-gvsig-2-1-en-espanol-gratuito/

Google Summer of Code 2020 - Test.

 * Create a script that explores all the features in a polygon layer and return a summary of all of the areas together.


 * Add functionality to the previous script: create a new layer with the polygons that are bigger than a given value.


 * Add functionality to the previous script: Implement this script in the geoprocessing framework.