Пересчет координат Yandex в координаты Гугла

[leha2000]

Здравствуйте Господа Геодезисты!
Я к сожалению не являюсь геодезистом, поэтому обращаюсь к вам за помощью.
Существует проект ПО для gps, называемый tangogps, поддерживающий репозитории карт OSM, Google и т.д.
Туда необходимо добавить репозиторий Яндекс карт.

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

Фактически нужна формула пересчета проекции Яндекса в проекцию Гугла. Сам допетрил только пересчет через полином, т.е. ряд Тейлора, вычисляющийся по нескольким точкам, и то только по Y, по Х несовпадения карт напоминают случайный процесс. Да и вобще это какойто неправильный эмпирический подход.

Яндекс в своем описании пишет что использует элипсоид WGS84 и "равноугольную цилиндрическую проекцию Меркатора", Гугл вроде UTM на томже элипсоиде, хотя встречал мнение, что "У гугла используется проекция на сфероиде", хотя в это с трудом вериться.

Как это все пересчитать подскажите тупому программисту, не имеющему времени изучить курс геодезии и картографии. Нужна формула пересчета.

[geologic]

Вы сначала все же с проекциями разберитесь, до начала программирования. Иначе какой к черту полином?! И про какой Гугл вы вообще ведете речь, Google maps? Там проекция для привязки тайлов обычный Меркатор на сфере, в интернете это уже лет пять как обсорсано А проекция UTM (Univ. Transverse Mercator) никакого отношения к делу не имеет, это "поперечный меркатор", для топокарт.

Проекция Яндекса действительно меркатор на WGS (как и Google Earth, кстати). Определитесь, что за проекции вам нужны, и тогда уже ищите формулы, в любом геодезическом справочнике они есть. Можно на Posc.org, можно еще где-нибудь в мануалах. Если с уговорами и картинками, то есть для совсем программистов, вот тутможно почитать детально про проекцию и принцип привязки.

[bim2010]

Пример переключения wgs84(EPSG:4326) и Google maps - sphericalMercator
http://www.openlayers.org/dev/examples/ ... cator.html
Другие примеры: http://www.openlayers.org/dev/examples/

Подсмотреть как это делается: http://www.openlayers.org/dev/lib/OpenLayers/Layer/
Файл SphericalMercator.js и, возможно другие рядом...

[leha2000]

Подсмотреть как это делается: http://www.openlayers.org/dev/lib/OpenLayers/Layer/
Файл SphericalMercator.js и, возможно другие рядом...

Файлик понятный. Мне видимо нужен следующий метод Given a x,y in Spherical Mercator, return a point in EPSG:4326.
Непонятно только в чем x,y измеряется у меня есть lat и lon меркатора на сфере, а нужно получить lat и lon меркатора на wgs84.
как бы всетаки получить lat,lon -> lat,lon
posc.org конечно очень хороший сайт, всеми рекомендуемый, но на изучение всего, чего там есть уйдут месяцы.

[geologic]

Чтобы найти там формулы, месяц не нужен - они лежат уже готовые к расчетам, по всем основным проекциям. Оттуда составить процедуры у меня заняло дня три, не больше (текст могу и дать, если надо). Словом, так бы и сказали сразу, что вы на бейсике только привыкли понимать...

X,Y в "меркаторе на WGS", как и в любой другой проекции измеряется в метрах. Никак нельзя получить широту-долготу в градусах. Если что-то получить в градусах, будет ровно столько же, сколько и не в меркаторе - они зависят только от эллипсоида (про датум молчу, месяцы ваши жалко)

Короче, вам для понимания - меркатор и любая проекция - это плоскость с метрами по ней, градусы = шар или эллипсоид. Поглядите описания проекций все же, хотя бы день один.

[leha2000]

Чтобы найти там формулы, месяц не нужен - они лежат уже готовые к расчетам, по всем основным проекциям. Оттуда составить процедуры у меня заняло дня три, не больше (текст могу и дать, если надо). Словом, так бы и сказали сразу, что вы на бейсике только привыкли понимать...

X,Y в "меркаторе на WGS", как и в любой другой проекции измеряется в метрах. Никак нельзя получить широту-долготу в градусах. Если что-то получить в градусах, будет ровно столько же, сколько и не в меркаторе - они зависят только от эллипсоида (про датум молчу, месяцы ваши жалко)

Короче, вам для понимания - меркатор и любая проекция - это плоскость с метрами по ней, градусы = шар или эллипсоид. Поглядите описания проекций все же, хотя бы день один.

Наверно неправильно объяснил...
Имею: lat,lon, и pixel_y, pixel_x для гугла. Яндекс тайлы с гуглами не совпадают это понятно. Нужно рассчитать некий offset_x,offset_y. Что такое проекция и в частности Меркатора - понимаю прекрасно, что такое шар или элипсоид - тоже.
Чтобы не переделывать исходники offset можно либо в пикселях либо в градусах. Думал, что так проще будет для понимания. Ну извините уж коль что не так.

[bim2010]

viewtopic.php?f=1&t=2606&p=8330&hilit=S ... ator#p8330

[leha2000]

К сожалению ничего из этого я не понял. ( наверное не судьба (
Единственное, что нашел более менее понятное, т.е. то что нужно взял здесь: http://www.shmuma.ru/maemo-mapper-shmuma.html
расковыряв код и немного подправив под себя получил пересчет:

#define YANDEX_Rn (6378137.0)
#define YANDEX_E (0.0818191908426)
#define YANDEX_A (20037508.342789)
#define YANDEX_F (53.5865938)
#define YANDEX_AB (0.00335655146887969400)
#define YANDEX_BB (0.00000657187271079536)
#define YANDEX_CB (0.00000001764564338702)
#define YANDEX_DB (0.00000000005328478445)

float tmp = tan (M_PI_4 + deg2rad (lat) / 2.0);
float pow_tmp = pow (tan (M_PI_4 + asin (YANDEX_E * sin (deg2rad (lat))) / 2.0), YANDEX_E);
int unitx = ((YANDEX_Rn * deg2rad (lon) + YANDEX_A) * YANDEX_F)/64*pow(2,zoom-17);
int unity = ((YANDEX_A - (YANDEX_Rn * log (tmp / pow_tmp))) * YANDEX_F)/64*pow(2,zoom-17);;

yandex_offset_y = unity-pixel_y;
yandex_offset_x = unitx-pixel_x;

Москва совпала полностью, правда вот незадача, в регионах есть смещения, небольшие но есть, причем по x больше, чем по y и достигают десятков метров. Может ли это не быть связано с неправильностью пересчета?

[feya]

достигают десятков метров

Это нормально.

[geologic]

Да вроде где-то так, что-то знакомое. Пиксели или метры в итоге, ведь нет особой разницы в расчете, пропорция зависит от масштаба, т.е. формула с Posc (та, что для перевода градусов в метры) подходит один в один.

Да и еще совет бывалого - замените везде POW (2, ) на SHL или SHR - в десятки раз быстрее работает, не знаю, в чем вы сидите правда, есть ли у вас такие операторы.

Насчет разницы - гугл с яндексом и по москве не совпадают до 50 метров, привязка снимков разная. Это нормально. Сосредоточьтесь лучше на микронеточностях, начинающие обычно округления по границам тайлов путают, и если в ГИС передавать привязку, забывают про "полпиксела". Самотесты это не кажут, а потом оно вылезает

[leha2000]

Да вроде где-то так, что-то знакомое. Пиксели или метры в итоге, ведь нет особой разницы в расчете, пропорция зависит от масштаба, т.е. формула с Posc (та, что для перевода градусов в метры) подходит один в один.

Немогли бы ссылочку кинуть с этой формулой, а то, что-то сложно эта формула дается мне для понимания. Про пиксели и метры, то понятно, что заменяют друг друга. На вскидку сложно понять, что при пересчете двух поверхностей второго порядка получаются тангенсы и экспоненты. Самому выводить пока нету желания, хотя видится, что это единственный путь чего-либо понять

Да и еще совет бывалого - замените везде POW (2, ) на SHL или SHR - в десятки раз быстрее работает, не знаю, в чем вы сидите правда, есть ли у вас такие операторы.

К сожалению в Си нету операторов возведения в степень и функция pow() является единственным простым решением возведения в степень. Я к сожалению ни в чем не сижу, а пишу новое, т.е. дописываю существующее, малоизвестное, бесплатное под linux, поэтому видимо, почти все ссылки форумчан мне не совсем подходят.

Насчет разницы - гугл с яндексом и по москве не совпадают до 50 метров, привязка снимков разная. Это нормально. Сосредоточьтесь лучше на микронеточностях, начинающие обычно округления по границам тайлов путают, и если в ГИС передавать привязку, забывают про "полпиксела". Самотесты это не кажут, а потом оно вылезает

Москва у меня чуть ли не метр в метр совпала причем по х вообще нету различий, по У чуть-чуть ну да и бог с ним, а вот в регионах несовпадения приличные причем по Х совсем как-то случайно то в + то в -, а по У небольшие, похожие на погрешности вычисления, может как раз по полпикселя и накладывается. К северу от Москвы яндекс чуть-чуть выше гугла, а по Х не поддается описанию. Вообще, честно говоря похоже, что просто отснято немного кривовато, ну или обрезано, не знаю как это делается. В чем разница привязок тайлов между Я и Г и как это лечить??

[bim2010]

http://www.geofaq.ru/forum/index.php?ac ... c=7&page=5
http://mapnav.spb.ru/site/e107_plugins/ ... p?13518.50
http://clubs.ya.ru/mapsapi/replies.xml? ... ncrnd=4386

[leha2000]

Здорово! Т.е. они их чуть сдвинули на крупных масштабах. Интересно насколько чуть чуть и в какую сторону. У меня правда видны сдвиги и на 12 масштабе не сказалбы, что это крупный масштаб.

[geologic]

На формулы пересчета широты-долготы со сферы в меркатора и в пикселы я уже ссылку давал, ну, могу еще раз - вот http://www.geofaq.ru/art/2google_geo.shtm#2 . Это проработано, обсорсано - процедуры есть, если на код хотите подивиться. Обратные и для эллипсоида остались на Posc, но там тоже все понятно, лишь маленько вчитаться. Коды тоже где-то у меня были зарифмованы... Если надо, сыщу, но по формулам мне, например, всегда удобней - нагляднее.

Ссылка bim2010 на geofaq правильная, детали гугла с яндексом там не раз обсасывали, в т.ч. с ведущими с разработчиками.

Еще раз, SHL и SHR операторы НЕ возведения в степень, а битового сдвига. В СИ они есть, как и остальные битовые дела. Применяйте обязательно, а то ваш сорц выглядит непрофешно

Насчет сдвига - вот тут детально разбирается разница 50 м между гуглом и яндексом, на север Москвы. Не надо с ходу говорить, что это "только в области" и что "они их просто сдвинули", надо глядеть как следует, и не в ходе программирования, а то запутаете и без того сложный вопрос. Причины совсем другие, какие- читайте по ссылке, там сидели-гадали, примерялись к этому довольно долго.

[leha2000]

Если надо, сыщу, но по формулам мне, например, всегда удобней - нагляднее.

Не надо время тратить

Еще раз, SHL и SHR операторы НЕ возведения в степень, а битового сдвига. В СИ они есть, как и остальные битовые дела. Применяйте обязательно, а то ваш сорц выглядит непрофешно

Немогу не согласиться, но в действительности временем вычисления степени можно пренебречь по сравнению с выводом тайлов на экран

Насчет сдвига - вот тут детально разбирается разница 50 м между гуглом и яндексом, на север Москвы. Не надо с ходу говорить, что это "только в области" и что "они их просто сдвинули", надо глядеть как следует, и не в ходе программирования, а то запутаете и без того сложный вопрос. Причины совсем другие, какие- читайте по ссылке, там сидели-гадали, примерялись к этому довольно долго.

За это БОльшое спасибо на досуге погляжу.