расчет растояния по координатам. Опции

[alexdos]

Подскажите где почитать про расчет растояния по координатам, нужно упрощенная формула, для растояний до 500 метров, точность не шибкая, и пару метров устрит. Но чтоб просто и быстро. Нужно знать приблизился ли обьект с жпс на какоето растояния до статической координаты. Координат будет штук 500, а может и больше.

[_Артём_]

Подскажите где почитать про расчет растояния по координатам, нужно упрощенная формула, для растояний до 500 метров, точность не шибкая, и пару метров устрит.

Для таких дистанций можно считать Землю плоской и расстояние считать по Пифагору, с учётом того что дельта растояния по долготе зависит от широты.

Но чтоб просто и быстро. Нужно знать приблизился ли обьект с жпс на какоето растояния до статической координаты.

Мало данных: если у вас PC или Cortex-M4F - можно работать с плавучкой и будет всё равно быстро, если что-то типа PIC16 - то совсем по другому - работать лучше с целыми величинами. Опять же в какое время должен вложится обсчёт?



Ещё момент - нужно ли учитывать что полушария бывают западное и восточное?

[adnega]

Подскажите где почитать про расчет растояния по координатам, нужно упрощенная формула, для растояний до 500 метров, точность не шибкая, и пару метров устрит. Но чтоб просто и быстро. Нужно знать приблизился ли обьект с жпс на какоето растояния до статической координаты. Координат будет штук 500, а может и больше.

Я вот так считаю:

Код

#include <math.h>

double sdlat, sdlon, dist;
volatile double lat, clat, lon, clon;

clat = 57.60904722 * M_PI / 180.0;
clon = 39.82411944 * M_PI / 180.0;

lat = 57.6083 * M_PI / 180.0;
lon = 39.82488333 * M_PI / 180.0;

sdlat = sin((lat - clat) / 2.0);
sdlon = sin((lon - clon) / 2.0);
dist = 2.0 * asin(sqrt(sdlat * sdlat + cos(clat) * cos(lat) * sdlon * sdlon)) * 6367444.6571225;

На Cortex-M4F довольно быстро.

[_Артём_]

Я вот так считаю:

Код

dist = 2.0 * asin(sqrt(sdlat * sdlat + cos(clat) * cos(lat) * sdlon * sdlon)) * 6367444.6571225;

Почему через арксинус? Sqrt недостаточно? Или точность выше?

[alexdos]

Почему через арксинус? Sqrt недостаточно? Или точность выше?

расчет будет проводится на STM32f100.
Вот и я думаю, зачем усложнения в вычислениях косинусами, арксинусами. По сути задача на моё мнение сводится к вычислению гипотенузы в треугольнике. Где гипотенуза искомое расстояние, а катеты, разница между координатами (проэкции на широту и долготу). Учитывая что это все растояния будут не более 500 метров, точность не высокая, даже ошибка в пару метров устроит, то можно все упростить.

[GeGeL]

Для таких дистанций можно считать Землю плоской и расстояние считать по Пифагору, с учётом того что дельта растояния по долготе зависит от широты.

Все равно косинус нужен, но есть хорошие целочисленные алгоритмы для MC, уже обсуждалось в этой ветке около года назад.

[mempfis_]

Подскажите где почитать про расчет растояния по координатам, нужно упрощенная формула, для растояний до 500 метров, точность не шибкая, и пару метров устрит. Но чтоб просто и быстро. Нужно знать приблизился ли обьект с жпс на какоето растояния до статической координаты. Координат будет штук 500, а может и больше.

Давно пользуемся таким методом.

Код

#define Pi 3.14159265358979

//вычисление расстояния между двумя точками
unsigned int calcDist(double Lat1, double Long1, double Lat2, double Long2)
{
  double Lat1_Radi=0, Lat_metr=0, Long_metr=0, Res=0;


  Lat1_Radi = 111112*cos( (Pi*Lat1)/180 );


  Lat_metr = (Lat1*111112) - (Lat2*111112);

  Long_metr = (Long1*Lat1_Radi) - (Long2*Lat1_Radi);

  Res = sqrt( (Lat_metr*Lat_metr) + (Long_metr*Long_metr) );
  return ((unsigned int) Res);
}

[_Артём_]

Все равно косинус нужен

Можно затабулировать с каким-то шагом, например для каждого градуса.

есть хорошие целочисленные алгоритмы для MC, уже обсуждалось в этой ветке около года назад.

Что за тема?

[V_G]

Гораздо лучше, быстрее и точнее считать расстояния не по географическим, а по прямоугольным координатам. Все GPS-приемники считают в XYZ (относительно центра Земли), но в стандартном NMEA вывод наружу прямоугольных координат не предусмотрен. Приходится переключаться на бинарные протоколы.

[Frolov Kirill]

Формулы здесь: http://gis-lab.info/qa/great-circles.html Алгоритм проще писать с плавающей точкой. Переписывать с фиксированной IMHO заметный маразм (float работает и на PIC18 но тянет за собой много мат. функций в ПЗУ). Понадобятся: синус и косинус, корень квадратный и atan2 -- всё кордиком (если вручную, с фикс. точкой). Но, повторюсь, маразм, ибо с плавающей может даже быстрей считаться (для фикс. точки разрядность бОльшая).

Если памяти на float нет (double не нужен и медленее, cosf() вместо cos() и т.п.), то остаётся только считать на плоскости. В 16 битах расстояния до ~65км с погрешностью до 500м на больших расстояниях. Понадобятся корень квадратный (32 бита кордиком) и косинус (12 бит кордиком).


Сообщение отредактировал Frolov Kirill - May 1 2013, 12:55

[GeGeL]

...есть хорошие целочисленные алгоритмы для MC, уже обсуждалось в этой ветке около года назад.

Что за тема?

Тема по стояночному дрейфу координат:
http://electronix.ru/forum/index.php?showtopic=96786
Кстати, таки получилось у меня сделать хороший фильтр стояночных звезд. Вкратце: использую очередь с адаптируемым размером, обсчитываю по оригинальному фильтрующему
алгоритму всю группу накопленных в ней точек (фрейм). В итоге подавляет как быстрый, так и медленный дрейф, последовательно приближаясь к средней координате. Но даже при медленном начале движения с маневрами четко фиксирует и выдает начало трека. Вместе с использованием отправки точек по перемещению (тоже адаптируемому) и по повороту дает очень плавный трек без никаких артефактов даже в условиях города (помехи, застройка). А при быстром относительно равномерном движении размер очереди (и латентность фильтра) минимальны.
Проверено на Quectel M12 под OCPU: для его 32bit ARM7 это легкая задача.

[x893]

Тема по стояночному дрейфу координат:
http://electronix.ru/forum/index.php?showtopic=96786
Кстати, таки получилось у меня сделать хороший фильтр стояночных звезд. Вкратце: использую очередь с адаптируемым размером, обсчитываю по оригинальному фильтрующему
алгоритму всю группу накопленных в ней точек (фрейм). В итоге подавляет как быстрый, так и медленный дрейф, последовательно приближаясь к средней координате. Но даже при медленном начале движения с маневрами четко фиксирует и выдает начало трека. Вместе с использованием отправки точек по перемещению (тоже адаптируемому) и по повороту дает очень плавный трек без никаких артефактов даже в условиях города (помехи, застройка). А при быстром относительно равномерном движении размер очереди (и латентность фильтра) минимальны.
Проверено на Quectel M12 под OCPU: для его 32bit ARM7 это легкая задача.

Было бы интересно проверить на своем приемнике - не планируете опубликовать ?

[GeGeL]

Пока нет, к сожалению: алгоритм работает в составе коммерческого софта.

[Telit_Sprt]

Доброй ночи,
всем пользователям модемов от Телит, предлагается новый сервис M2M Locatе, для определения местоположения модуля по базовым станциям, причем все вычисления проходят на стороне сервиса M2M locate. Более подробно об этом сервисе можно прочитать по ссылке - Telit M2M Locate

Желаю удачи!

[GeGeL]

вычисления проходят на стороне сервиса

А можно поподробнее алгоритм? ТА хоть используется?

А тестовых целях сервис предоставляется в свободном доступе, но с ограничением до 10 запросов в сутки с одного модуля.

Как то даже неконкурентно в сравнении с тем же Quectel: у них все бесплатно и неограниченно...