Methods to measure complexity of trajectories (paths) #406 Open

[demoncoder-crypto]

This PR implements trajectory complexity measures for analyzing animal movement paths.

New features:

• Added trajectory_complexity.py module with the following functions:
  • compute_straightness_index: Ratio of Euclidean distance to path length
  • compute_sinuosity: Local measure of path complexity using a sliding window
  • compute_angular_velocity: Rate of change in direction
  • compute_tortuosity: Measures path winding (fractal dimension and angular variance methods)
  • compute_directional_change: Quantifies total turning within a time window
• Added comprehensive unit tests
• Added example script demonstrating how to use the new functions
• Updated init.py to expose the new functions

Fixes Issue #406

This PR addresses the need for methods to measure complexity of trajectories (paths).

I have not tested it thoroughly or implemented it properly right now. I just wanted to know if this is the issue what we were trying to solve and I am on the right track to solve it.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[demoncoder-crypto]

@niksirbi So should i continue with this implementation and make it compatible with everything? Does it cover the functionality?

[niksirbi]

@niksirbi So should i continue with this implementation and make it compatible with everything? Does it cover the functionality?

Hi @demoncoder-crypto, thanks for taking the time to contribute to movement!

From a cursory look, you've made a great start in this PR:

• these metrics are exactly the kind of thing we need to solve Methods to measure complexity of trajectories (paths) #406
• you have nicely described what each metric does in the docstrings
• you've included tests

We will need to review the PR in detail, and also take a look at the relevant papers, but this might take some time given our increased workload at the moment. Nevertheless, we definitely want these metrics in movement and one of us will eventually get back to you with detailed feedback.

In the meantime, see if you can deal with some of the CI failures.

[demoncoder-crypto]

Thanks For replying @niksirbi, I would love to fix CI failures but because the implementation is quite up in the air as I assumed that this would how the implementation would go. If I fix CI failures on half implemented solution I would have to go back and change everything from start. regarding the code and why did i make a certain change Please ask me anytime I am very happy to answer but I am still unsure if this is the path forward because there was nothing mentioned in Pull request by the initial person so I am not sure if this what they are looking for. Thanks once again means a lot.

[niksirbi]

If I fix CI failures on half implemented solution I would have to go back and change everything from start.

You are right about that. That's why the usual workflow we'd recommend is the following:

• Open a draft PR to get initial feedback (to gauge if it's in the right direction). At the draft PR stage you don't need to worry about CI failures too much
• After the initial feedback stage, you may polish the PR and deal with CI
• Once all CI checks pass, then mark the PR as "Ready to review"

You've done everything right, except that I'd rather have this as "Draft PR" for now.

I actually have a proposal on how to move forward with this more efficiently:

• Convert this PR to draft, for the aforementioned reasons
• I encourage you to open a separate PR, in which you implement only 1 of these metrics (pick one of the simpler ones, like "straightness index") and also include unit tests for that metric specifically.
• We will review that one, polish it together, and hopefully merge it
• Once we've established one metric, we can use that function as a "template" to implement the other metrics too. Reviewing the rest will be easier.

In general we try to make small changes in each PR, which makes both the implementation and the reviewing easier.

Let me know if this plan sounds good to you.

[demoncoder-crypto]

That Sounds amazing, not only it would clearly define what we are working on but also gives us the room for improvement to execute it perfectly. Just let me know what issue is decided as a path to move forward and I will start implementing them slowly iterate over it. Thanks

[niksirbi]

Great @demoncoder-crypto, I've started creating sub-issues to #406, starting with #517 for the straightness index, which I see you already started working on in #514.

The idea is that we will gradually create more sub-issues, one for each complexity metric that we think is worth implementing.

I've also converted this PR to draft. The individual smaller PRs will take precedence, and we will just keep this one around for reference.

[vtushar06]

Hii @niksirbi,
I’d love to contribute to this effort particularly in discussions and raised PRs and around implementing and testing individual metrics or helping clean up CI as the work progresses. Please let me know.
Thanks

[niksirbi]

I appreciate your motivation @vtushar06, but this is currently not a priority as the team is focusing on other features. When we find the time to get back to this, we'll start by finalising PR #517 before attempting to implement other such metrics.

In any case, I'd rather have PRs completed by their original author whenever possible, assuming they are available when we turn our attention to path complexity metrics. I can ping you if/when we'll need additional support on this topic.

[vtushar06]

Got it, thanks @niksirbi! Happy to help whenever needed.