quad tree with points that have a set of line indices as data

[stijnvermeeren-swisstopo]

Code review proposal for #38

• Link multiple lines with a single point in the quad tree
• Remove the need for recursive calls of the "merge lines by quad tree" method
• Remove the need for the inefficient check for duplicate lines

I think that some unit tests for the LinesQuadTree class could be really useful, but I did not have time to implement any new tests yet. I'll leave that up to you @redur to either add some unit tests, or to accept this PR as-is already and to leave writing unit tests for later.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
src/stratigraphy
__init__.py	8	1	88%	11
extract.py	189	189	0%	3–460
get_files.py	21	21	0%	3–48
line_detection.py	26	26	0%	3–76
main.py	85	85	0%	3–225
src/stratigraphy/util
dataclasses.py	32	3	91%	37–39
depthcolumn.py	204	67	67%	26, 30, 51, 57, 60–61, 85, 88, 95, 102, 110–111, 121, 138–154, 187, 210, 226–234, 244, 249, 256, 263, 268, 286, 296, 299–306, 321–322, 365–407
depthcolumnentry.py	20	4	80%	12, 15, 27, 34
description_block_splitter.py	70	2	97%	24, 139
draw.py	62	62	0%	3–184
duplicate_detection.py	32	32	0%	3–81
find_depth_columns.py	82	4	95%	57–58, 149–150
find_description.py	39	6	85%	27–34, 111–114
geometric_line_utilities.py	87	2	98%	83, 133
interval.py	107	52	51%	25–28, 32–35, 40, 45, 48, 100–146, 166, 171–187
language_detection.py	18	18	0%	3–43
line.py	49	26	47%	25, 42, 51, 65–95, 98
linesquadtree.py	46	1	98%	76
plot_utils.py	44	44	0%	3–121
predictions.py	154	154	0%	3–322
textblock.py	74	8	89%	27, 51, 63, 75, 98, 119, 127, 155
util.py	40	22	45%	15–18, 22, 26, 40–47, 61–63, 87–88, 100–105
TOTAL	1489	829	44%

Tests	Skipped	Failures	Errors	Time
44	0 💤	0 ❌	0 🔥	0.502s ⏱️

[redur]

Looks good to me. Thanks.

Performance is also improved on my Mac. Even sligthly faster than the old non-quad tree implementation.

[redur]

The end points confused me for a second. Maybe it's better to say with all start and end points of all lines.
I think you meant it the right way, a line (segment) has two end points. But since our implementation has line.start and line.end; it can be confusing.

[stijnvermeeren-swisstopo]

Yes, good point, I see that it can be confusing.

However, "end point" is a rather standard name for the extremities of a line segment. And our line segments don't really have an inherent direction, so maybe we should reconsider the naming of "line.start" and "line.end", rather than avoid the word "end point" in other contexts such as here...

What do you think? Merge it like this and deal with it later?

[redur]

Merge it and deal with it later. The implementation is rather explicit. So any confused reader will figure it out quickly.