`min_distance` doesn't work with 3D tracking where `dz` not constant

[freemansw1]

Reported to me by Yishi Hu from OU. When you use min_distance in feature detection with a non-constant dz, it fails as the coordinate interpolation takes place after min_distance is called. That means min_distance doesn't have any vertical information. This should be able to be solved by reversing the order of the two calls.

• [x] Have you searched the issue tracker for the same problem?
• [x] Have you checked if you're using the latest version? If not, which version are you using?
• [x] Have you mentioned the steps to reproduce the issue?
• [x] Have you, if applicable, included error messages?

[freemansw1]

There's a secondary bug in filter_min_distance, line 1534 of main, where it always uses dz even if none is passed.

[w-k-jones]

I realised this when you pointed out the issue with dz in #372 . It's a bit trickier with feature detection, as we will need to perform coordinate interpolation before distance filtering. It may have to wait until I have time to fix it in a later release

[freemansw1]

I realised this when you pointed out the issue with dz in #372 . It's a bit trickier with feature detection, as we will need to perform coordinate interpolation before distance filtering. It may have to wait until I have time to fix it in a later release

Shouldn't we be able to just do interpolation first without too much of an issue? There's probably a performance penalty there, but I assume it isn't too bad of one.

[w-k-jones]

It probably should be fine, I just haven't had any time recently to look into implementing it. I'll look into making the kdTree/BallTree neighbour search a more generic method to avoid these issues in future, as it it will be useful for other methods