Deprecate get_spacings

[freemansw1]

Resolves #502 . Removes get_spacings from all tutorials, replacing it with explicit grid spacing and time interval declaration. Marks get_spacings as deprecated.

• Have you followed our guidelines in CONTRIBUTING.md?
• Have you self-reviewed your code and corrected any misspellings?
• Have you written documentation that is easy to understand?
• Have you written descriptive commit messages?
• Have you added NumPy docstrings for newly added functions?
• Have you formatted your code using black?
• If you have introduced a new functionality, have you added adequate unit tests?
• Have all tests passed in your local clone?
• If you have introduced a new functionality, have you added an example notebook?
• Have you kept your pull request small and limited so that it is easy to review?
• Have the newest changes from this branch been merged?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.11%. Comparing base (188046f) to head (ff0f0fa).
⚠️ Report is 10 commits behind head on RC_v1.6.x.

Additional details and impacted files

@@              Coverage Diff              @@
##           RC_v1.6.x     #538      +/-   ##
=============================================
+ Coverage      63.55%   64.11%   +0.56%     
=============================================
  Files             27       27              
  Lines           3858     3913      +55     
=============================================
+ Hits            2452     2509      +57     
+ Misses          1406     1404       -2     

Flag	Coverage Δ
unittests	64.11% <100.00%> (+0.56%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Linting results by Pylint:

Your code has been rated at 8.33/10 (previous run: 8.34/10, -0.01)
_{The linting score is an indicator that reflects how well your code version follows Pylint’s coding standards and quality metrics with respect to the RC_v1.6.x branch.
A decrease usually indicates your new code does not fully meet style guidelines or has potential errors.}

[w-k-jones]

Should we consider this a major enough change to warrant being part of a 1.7 release? Or introduce it sooner but focus on adding more coordinate awareness (e.g. using lat/lon rather than fixed x/y spacing) for 1.7?

[freemansw1]

Should we consider this a major enough change to warrant being part of a 1.7 release? Or introduce it sooner but focus on adding more coordinate awareness (e.g. using lat/lon rather than fixed x/y spacing) for 1.7?

I think we can hold this back for v1.7, although I think holding it back until we resolve all coordinate issues is probably not a great idea. I'm working on lat/lon tracking code now to resolve an issue I'm encountering with periodic boundaries on global data (namely that it can be slow), which would help. Because we're reliant on the scikit-learn distance metrics outside of using a python -> numba function, though, that function is intended to be 2D only, at least at first.

[freemansw1]

Should we consider this a major enough change to warrant being part of a 1.7 release? Or introduce it sooner but focus on adding more coordinate awareness (e.g. using lat/lon rather than fixed x/y spacing) for 1.7?

I think we can hold this back for v1.7, although I think holding it back until we resolve all coordinate issues is probably not a great idea. I'm working on lat/lon tracking code now to resolve an issue I'm encountering with periodic boundaries on global data (namely that it can be slow), which would help. Because we're reliant on the scikit-learn distance metrics outside of using a python -> numba function, though, that function is intended to be 2D only, at least at first.

My ideal is actually that we move to a world where we don't ask the user to input anything for dxy or dt. Migrating away from dt is relatively straightforward, and could/would come when we have adaptive dt working. Migrating away from dxy is harder, particularly for the specification of the search radius for trackpy.

[freemansw1]

I was thinking about this more - perhaps we can split this into two PRs: one to remove get_spacings from the tutorials, targeted at either 1.6.2 or 1.6.3, and then deprecating get_spacings in 1.7.0. It's not a breaking change, and removing it from the tutorials would save us a lot of headache.

[Sven-248]

I noticed that in the basics example 'Idealized-Case-3_Tracking-of-a-Test-Blob-in-3D', get_spacings is still used.
Since this example was introduced with the new release it would be good to update it accordingly for consistency.