5. Must not have gaps

Rule details.

• Rule name: TopologyRuleMustNotHaveGapsPolygon

• Repository: https://github.com/Maureque/TopologyRuleMustNotHaveGapsPolygon

• Description: Polygons must not have a void between them. This rule is useful when it is needed that polygons must have no gaps between them so all the polygons should make a continuous surface.

  For example, when polygons can not include null areas and must form a continuous structure.

• Release: https://github.com/Maureque/TopologyRuleMustNotHaveGapsPolygon/releases/tag/1.0.0-0

• Development process: To minimize risks and optimize the development process, is followed by the following methodology:

  • Approach the problem.
  • Analyze data and classes.
  • Algorithm design to solve the problem.

  • The rule requires that the polygons not have a null area between them. For this rule, there is one input layer of polygons, to which the topological rule applies.

    If the polygons have some null area line errors are created which make a polygon error.

    This rule was a great challenge because here it was necessary to make a workaround to access the number of lines in the report, since we still have no way to generate a layer of output errors through the topology framework. So, the solution was to go through the components of the graphical interface of gvSIG until reaching the jtable and then a layer is created directly in view and the geometry is loaded into it.

    In this rule, the solution that is reached will depend on the criteria used by the user based on the tolerance that he determines, according to the defined tolerance will be the result obtained. Here the tolerance has to be greater than the distance between the polygons for it to detect the gap.

    Furthermore, two functions had been developed to be implemented to obtain a satisfactory solution, since to, detect the gaps when applying the "difference" method did not give good results, this gave rise to the "checkGaps" and "findGaps" functions. Within the latter function, after applying "difference", a specific clean was developed for this rule. Despite all the progress made, more time still needs to be spent testing the rules.

    To guarantee the quality of the rule, this process was created to eliminate the inconsistencies that may cause the result to be not the desired one. Therefore, it is identified invalid, imprecise or incomplete data. This process has several stages: defining and determining the types of errors, finding them, identifying them, and correcting them.

    To perform the clean, it was necessary to calculate the centroid of the polygon. Then we move through each edge and for each one the distance from that edge to the centroid is calculated. From the list of distances that is obtained, the average distance is calculated and to eliminate the error values it is considered 2σ(sigma) is taken for the standard deviation since it was the one that best adjusted.

    For the rule to apply and obtain errors, the buffers must overlap, for this, the user must adjust the tolerance. This must be greater than the distance between the polygons otherwise the buffers will not overlap and the gaps are not detected.

    In conclusion, if the polygons have some null area the error report returns the polygons that are limited with the null space, to which the actions can be applied, Delete polygon action, and Mark polygon action.

  • Input data:

    • Polygon layer.

  • Output data:

    • Polygons errors report.

  • Error correction:

    • Delete polygon action. This action deletes the polygons errors, these are the polygons that are limited with the null space. The polygons to delete can be selected individually. View example.
    • Mark polygon action. This action marks the lines errors, these errors are the limit of the polygons that border the empty space. So this action makes a new layer with the polygons errors. Mark the portion of the entities that do not comply with the rule, the polygons to mark can be selected individually. View example.
  • Optimize algorithm.
  • Codify.
  • Test, debug, and refactor.
  • Document throughout the whole process. This activity has continuity from the beginning of the development process until the end of it.

Examples.

Operation of the integrated rule to the topology framework.

Dataset:

Result using the difference method:

Result of the previous step using the difference method and doing a custom made clean method :

Result using the difference method:

Result of the previous step using the difference method and doing custom made clean method :

Continuing with the execution of the rule.