Мой вопрос может быть немного странным. Я «разработал» алгоритм и не знаю, есть ли подобный алгоритм уже там.Именование этого алгоритма: сравнение и интерполяция точек?
Ситуация: У меня есть трек, определяемый точками трека (2D). Например, точки трека представляют собой повороты. Между точками следа есть только прямые линии. Теперь мне задан набор координат в этом двумерном пространстве. Я вычисляю расстояние от первой точки трека до новых координат и расстояние для интервала для первых двух точек трека. Если расстояние до измеренных координат меньше расстояния от первой до второй точки трека, я предполагаю, что эта точка находится между этим интервалом. Затем я выполняю линейную интерполяцию. Если он больше, я проверю его со следующим интервалом.
Таким образом, в основном это происходит с интервалом и пытается вместить их туда. Я пытаюсь отслеживать объект, перемещающийся примерно вдоль этого трека.
Звучит это знакомо кому-то? Может кто-нибудь придумать предложение для аналогичного существующего алгоритма?
EDIT: Из того, что я сказал до сих пор, хочу уточнить, что позиция не умножается на точки следа. Рассмотрим мелкий рисунок ASCII Джонатана:
Позиция X находится в пределах сегментов 1 и 2 (S12). Теперь следующая позиция Y, которая не должна считаться достаточно близкой, чтобы быть на S12. Я перейду к S23 и проверю, находится ли он.
Если он есть, я не буду проверять S12 на любое другое значение, потому что я нашел его в следующем сегменте. Алгоритм «не оглядывается назад».
Но если он не найдет правильный сегмент оттуда, потому что он будет находиться вдалеке от первого сегмента, но все равно еще дальше от любого другого сегмента, я опустим значение и следующую позицию будет снова возвращаться на S12.
Петля все еще остается проблемой. Подумайте, что я получаю Y для S23, а затем пропускаю две или три позиции (поскольку они слишком далеки), я могу потерять трек. Я мог бы определить одну позицию на S34, где она уже была бы на S56.
Возможно, я смогу придумать некоторую среднюю скорость, чтобы определить, в каком сегменте это должно быть.
Кажется, чем больше сегментов, тем больше шансов принять правильное решение.
убедитесь, что вы не вычисляете squareroot для каждой точки. Это очень медленно, и не нужно. Расстояние по квадрату можно также проверить, чтобы определить ближайшую точку. – Toad
Это предназначено для координат GPS, где я использую типы SQL Server для получения расстояния до дуги (география.STDistance (другая география)) между двумя координатами. Хотя я мог проверить, насколько велика разница, он будет вычислять с помощью 2D-значений вместо дуги, учитывая измеренные относительно небольшие расстояния. И тогда я мог бы, конечно, использовать квадратные расстояния (и избегать квадратных корней), спасибо за подсказку! – rdoubleui