Координаты Google.Maps и Яндекс.Карты
 

Имеется 2 вопроса, на которые интересно получить ответ, в интернете не смог найти ответа.

1. какой тип данных использовать для хранения координат в БД MySQL?
координаты имеют вид: 50.12345 (только не знаю точно сколько цифр до точки и после) Как я понимаю логичнее использовать тип FLOAT и хранить в двух полях. Если есть, знаток координат, то подскажите сколько цифр может быть до и после точки.

2. у Google.Maps и Яндекс.Карты одна система координат. Следовательно координаты от гугла подходят к яндексу, правда говорят что есть смещения на *цать метров. У кого-то есть реальный опыт одновременного использования двух видов карт на сайте? Поделитесь, какое реально идет смещение.

А чем VARCHAR не нравится? Я бы не советовал FLOAT из-за проблем IEEE754 с точностью.

Спасибо, за подсказку!
Ну раз так, то наверно логичнее использовать VARCHAR. Тогда можно хранить в одном поле через пробел или запятую.
Еще бы кто-то подсказал какая размерность у координат, чтобы создать VARCHAR нужной длины.

DOUBLE и числа такого типа 53.6754

Коллеги, если в запросах планируются какие то вычисления с координатами, то VARCHAR не покатит!
Юзаю FLOAT, из ног в руки проблем не наблюдал..
Делал выборки из базы, доставая точки относительно другой в определенном радиусе
и сравнивал с результатами функций яшкиного API для определения расстояний -
погрешности были настолько минимальны, что можно было и забить.

float(10,6) вполне достаточно,
если ты не собираешься мерить расстояния
от струи пениса комара в Москве
до четвертой по счёту щёточки на второй левой лапке майского жука во Владивостоке :)

да, тоже верно... вычисления скорее всего после буду делать, видимо придется float.
Можете немного уточнить, что за проблемы с точностью(не смог найти инфы по данному вопросу) и на сколько вероятна погрешность (как я понял вы говорили о погрешности в вычислениях).

а почему 10? если не 2 или 3 наверно будет достаточно для целой части числа.

Сорри, отвлекают.. я имел ввиду цифры после точки..
для целой части тройки достаточно

всё-же нужно разобраться, что лучше, float или double.

значит после запятой может быть 6 цифр максимум в координатах?

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

Если верить Яндексу (я сейчас написал вывод координат для точек на карте) то смог установить что координаты бывают как положительные, так и отрицательные. Целая часть 3 знака. Дробная часть до 6 знаков.

При попытке создать DOUBLE( 3, 6 ) получаем ошибку:
Тут говорится что целая часть, должна быть больше или равна дробной. Следовательно придется делать так: DOUBLE( 6, 6 )

Тут я был не прав, даже с DOUBLE( 6, 6 ) при попытке сохранить число 123.123456 я получил ошибку
ИМХО: истина найдена. прошу прощение за непрофессиональность и флуд. Необходим DOUBLE( 9, 6 ), где 9 количество сумарное символов, а 6 число знаков после точки. (если я не прав, просьба поправить)

судя по документации MySQL
Вы правы.

И опять я ошибся, в гугле координаты вида "30.3102493286133".
Следовательно: DOUBLE( 17, 14 )

Если ошибаюсь, поправьте.

Речь идёт не о всех возможных величинах, а о том сколько достаточно,
для того чтобы рассчитать необходимое расстояние от точки до точки,
если дело не касается подобных расчетов
Необходимо немного отвлечься от программирования и освежить в голове географию, коллега ;)

используйте просто DOUBLE без каких либо значений... Мускул сам разберется с цифрами.

Тут планируется опись всех объектов Земли, афтар экономит дисковое пространство :D

Расчеты на сайте желательны с точностью до пары метров, конечно это в перспективе, на данный момент видимо оставлю координаты в полном виде. Проанализировал туристические сайты, там также используют полные координаты, следовательно чтобы не ловить лишних проблем буду делать как все.
На самом деле я не знаю насколько эта избыточность данных критична, в отношении оптимизации работы сервера.
дисковое пространство не экономлю(может только из объема экономлю оперативу на сервере), важна лишь скорость выполнения запросов, и соответствие желаемому результату в поиске. Видимо для поиска ближайших объектов разумно делать отдельную таблицу наполненную координатами объектов (сотни тысяч объектов), ну и продумать хитрое кеширование. Хотя если так подумать, в этой таблице и можно ограничить координаты до нужной длины, если это существенно отразится на скорости. Но это уже совсем другая история.

Не знаю как насчет сотни тысяч, на десяти тысячах у меня летает,
без всяких отдельных таблиц для координат и индексов..