repair: inaccurate coordinates (tiny inconsistency/invalidity)

[bertsky]

From discussion on OCR-D/core#418:

Additionally, IMO the coordinate checks should be made a little less strict (and thus more compatible with Aletheia) to avoid crying wolf.

Things I see frequently:

1. very small (up to 1 pixel) violations of non-containment in parent element
   • Shapely does not have almost_within, but one could try containment within the dilated version:

     if not (child_poly.within(node_poly) or
             child_poly.within(node_poly.buffer(0.5)))

2. tiny (direct neighbour) self-intersections because of back-and-forth (probably caused by internal rounding)
   • This must be repaired on the spot, otherwise Shapely will not operate on these polygons. Possibly:

     if not node_poly.is_valid:
         if node_poly.simplify(0.8).is_valid:
             node_poly = node_poly.simplify(0.8)

But it could be more prudent to keep a strict validator, and outsource these repairs into a dedicated Aletheia postprocessor (e.g. ocrd-segment-repair with a new correct-coords=true).

Originally posted by @bertsky in OCR-D/core#418 (comment)

[bertsky]

Status update: since OCR-D/core@6bf98d0 we do have a slightly more tolerant validator, but this is not much help, because

• invalid shapes can still cause exceptions in follow-up processors
• invalidities/inconsistencies which are larger than the 2px tolerance may still be explainable/repairable systematically
• especially if it does turn out PAGE coordinate semantics are "pixel center" instead of "pixel below right", we need an automatic translation between the two paradigms (the former as file interface, the latter as runtime interface for all polygon/bbox and image processing libraries)
• we need some tool for productive use as long as we have not fixed the offending (producing) processors themselves

[bertsky]

This has been solved long ago – ocrd-segment-repair does fix (trivial) validation errors automatically