Fix RTreeError for elements with floating-point precision issues (Issue #140)

[dolfim-ibm]

Description

This PR fixes an RTreeError that occurs when querying the spatial index with elements that are very close together vertically. Due to floating-point precision issues, the calculated y_min could be greater than y_max, causing the R-tree library to raise an error with the message "Coordinates must not have minimums more than maximums".

The fix ensures that y_min and y_max are properly ordered by using min() and max() functions when calculating the bounding box for spatial queries, instead of assuming a specific ordering based on element positions.

Issue resolved by this Pull Request:
Resolves #140

Changes

• Modified reading_order_rb.py to use min() and max() when calculating y_min and y_max for spatial index queries
• Added comprehensive test cases to verify the fix:
  • test_close_elements_with_floating_point_precision(): Tests elements with boundaries that differ by tiny floating-point amounts
  • test_identical_boundaries(): Tests edge case where elements have identical vertical boundaries

Checklist:

• Documentation has been updated, if necessary.
• Examples have been added, if necessary.
• Tests have been added, if necessary.

[github-actions]

✅ DCO Check Passed

Thanks @dolfim-ibm, all your commits are properly signed off. 🎉

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🔴 Enforce conventional commit

Waiting for:

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

This rule is failing.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

🔴 Require two reviewer for test updates

Waiting for:

• #approved-reviews-by >= 2

This rule is failing.

When test data is updated, we require two reviewers

• #approved-reviews-by >= 2

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[nikos-livathinos]

Even without this change, all tests still pass.
I have also tried the code with the coordinates of pelem_i, pelem_j provided in the issue and again all tests pass (with or without this change).
It would be very helpful if we can get hands on a document that reproduces this issue.

[dolfim-ibm]

@simonschoe would you be able to test this fix with your document?

[simonschoe]

@nikos-livathinos , @dolfim-ibm Thanks for your work and picking this issue up once more.

I must admit that I was not able to reproduce above described issue with the exact same document. It is now being processed correctly even without the fix (as @nikos-livathinos suggested that the fix might not be necessary). I have no idea why to be honest. I used the exact same document and even without your fix @dolfim-ibm it worked as expected. The issue that I described here with the printed values was the cause of the error when I tried it six week ago with that document. Maybe some dependencies changed/updated in the meantime that fixed the issue? I am not quite sure