Scripting: Automate tasks and Ensure Information Quality instead of spending our time doing what a machine.
If the repetitive tasks do not need special perception, creative intelligence or social intelligence then are feasible tasks of automation and not appropriate to creative beings with a critical reflexive attitude.
The Project “New rules for the Topology Framework in gvSIG Desktop” was carried out within the Google Summer of Code 2019 program with OSGeo (Open Source Geospatial Foundation) and the gvSIG Association, this is an example of how scripting can help to automate tasks and save time, allowing the user to focus on the logic to solve.
With the automation of topological rules errors are prevented, especially when working with large volumes of information, since it is very feasible to have errors of both precision and accuracy. For example: overlays, positional accuracy, mismatched geometries and inconsistent data.
Topology rules ensure that data sets comply with the conditions specified in each rule. Achieving this is an essential process to ensure the integrity and quality of spatial data.
At the beginning of the project there were few rules implemented, most of them pending development, we sought to implement a new set of topology rules for the validation and correction of vector data sets, improving and expanding the characteristics of previously existing tools. These tools allow browsing, searching and correcting validation errors as established in each rule.
The developed rules are:
This rule is useful when the points when the points must be aligned. Points in one layer must be coincident with points in another layer, if are not coincident a report of points error is created, this report is composed by the points from the first layer that are not covered by points from the second layer. For example: It is useful when in a power grid the meters must match with the service points.
In this rule the points in the input layer must be covered by the ends of lines in the coverage layer, so points errors are created on the points that are not covered by the ends of lines. For example, this rule is useful when is needed that street intersections must be covered by the endpoints of street centerlines.
In this rule the points in the input layer must be covered by the lines in the another layer, so points errors are created on the points that are not covered by lines. For example, this rule is useful when is needed a set of points that are coincident with lines like as when there are falls along with a set of lines, such as highway signs along highways.
In this rule the input layer is the points and the coverage layer the polygons. The points must fall within the area, not on the boundary. So points errors are created on the points that are not inside the polygon. This is useful when the points are related to polygons, such as wells and address points and parcels.
In this rule, it is required that each polygon of the input layer contains at least one point from the coverage layer of points. Points must be within the polygon, not on the boundary. If the polygon does not contain a point so we have an error and these are displayed in the error report, this it is a report of error polygons.
This is useful when every polygon should have at least one associated point, such as when parcels must have an address point or for example when each park must contain at least one waste container or if school district boundaries must contain at least one school.
Next, it is described the work done for the preparation of the rules and the main concepts through which the algorithm passes to reach the required solution.
The work consisted of defining the rules to be carried out, assembling the algorithm that validates and provides a solution, documenting the entire process and carrying out the implementation integrating the rules with the topology framework. For the rules where the input layer is of points the possibility of giving a tolerance to the contour of the points is considered, this tolerance defines the radius to create a buffer that will be used to make the space operations.
Part of the logic of the algorithm of each rule includes analyzing the dimensions of the geometry of the input layer (D2, D2M or 3D), it is also required to analyze whether it is simple or multipart geometry, for example, point or multipoint.
When the geometry type is not of the standard type, but inherits from a standard type getType() does not evaluate correctly, therefore it is necessary to use isTypeOf(…).
This analysis is not necessary for the coverage layer, because it is evaluated by the function that is already implemented by default, such as “intersects” or “contains”.
After this, when the default function is executed, it is necessary to analyze whether there is a spatial index or not, based on the result the error report is made.
In the error report, it is possible review the entities that do not comply with the rule and to correct the errors was implemented the delete action.
This Project provides a topological tool that evaluates the spatial relationship between the different types of geometries automatically and generates an error report to make the pertinents corrections. Allowing to navigate, search and correct validation and integrity errors.
Repetitive tasks are automated, errors are reduced and the user is allowed to focus on the solution he wants to provide.
In conclusion, simplicity is achieved in data analysis and the use of time is optimized.
The documentation is available in Spanish, Italian and English.
Final report, guide of installation and use of the tool, links to each rule, to the different repositories with the code and documentation: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/8.-Final-Report
Repository with all project documentation: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki
The work made by Hector Tundidor about this tematic will be publish shortly.
Article written by: Mauro Carlevaro