Add LineZone unit tests

[tc360950]

Description

Added unit tests for LineZone.

Type of change

Please delete options that are not relevant.

• New unit tests

[LinasKo]

Thank you for the changes, @tc360950 !

Would you have some time to add a few extra cases? What I'm thinking of is the following:

• object crossing pependicular to the line, but to its side. As if crossing the line extended to infinity, but not the segment defined by start-end.
• diagonal line
• negative coordinates
• Ensure error is raised when no anchors are defined

Does that sound like something you'd have time for, by any chance?

[tc360950]

@LinasKo Ok, I will add the changes. Could you clarify what you mean by "diagonal line" - there are already test cases for lines which are not horizontal or vertical. Do you want more (e.q. with different slope)?

[LinasKo]

Ah, indeed non-vertical and non-horizontal is what I meant. If we have it, we don't need any additional tests for it.

[tc360950]

@LinasKo I've added changes you had requested

[LinasKo]

Thank you @tc360950, this looks great!

I'll verify over the weekend, potentially push a tiny stylistic update, but otherwise, it looks good to go 😉

[LinasKo]

Hey @tc360950,

Apologies for the delay! To save time, I've pushed a few updates to the branch.
Despite our questions, the function names were descriptive enough so that docstrings aren't needed. We typically go very light on comments if there's code explaining the behaviour nearby.
Also, while not a typical practice, we internally agreed to ship a similar ValueError check to PolygonZone. I've added some tests for that.

@SkalskiP, This is ready to merge, but your review is outstanding. When you have the time, please resolve it ;)

[LinasKo]

Hey @tc360950,

We've had a chat with @SkalskiP - we really want to make sure that if we merge this, it needs to be thorough.

You've done a lot of work already. To make life a bit easier, I'll take this one over, get the tests to the point we're happy. There might be internal discussion yet to come and I don't want to force minor back-and-fourth changes on you 🙂

@SkalskiP: For our records, here's some visuals.
https://colab.research.google.com/drive/179sq8joJ-7JSYMqYNBQlMIPYEClq1PDi?usp=sharing

My plan is to visualise the multi-detection cases too, check if those are needed.
Moving forward, given we want to be thorough, if we're evaluating trickier tests, let's ask for visuals too.

[LinasKo]

I've added additional tests but found a case where LineZone does not work.
Crossing the line while moving from outside to inside the limits, or vice versa, does not count as a crossing.

This is an issue for large jumps or short lines.

I did not test cases with multiple lines present, for I don't see how they would interact.

Happy to merge this, ahead of the vectorized solution.

[tc360950]

I've added additional tests but found a case where LineZone does not work. Crossing the line while moving from outside to inside the limits, or vice versa, does not count as a crossing.

This is an issue for large jumps or short lines.

@LinasKo Isn't it an intended result? LineZone is "dumb" in the sense that it does not look at trajectories, there's no correlation between subsequent positions of an object.
For instance:
If an objects appears "in limits" on the left of the line, then goes around it and lands "in limits" on the right hand side it will be counted as crossing.

[LinasKo]

@tc360950 potentially intended, potentially not. If we assume small time increments, we're also in many cases assuming direct motion.

I can imagine an algo where we check for whether each anchor displacement line crosses the LineZone (well, only a line in this case), which would work for motions coming from outside the limits. I think it's more intuitive for the users as well.

However, that's a long-term thought. For now, we're 100% sticking with your vectorized solution.

[LinasKo]

Hi @SkalskiP,

I believe this is ready to merge. When you have time, please have a look.