|
Задавайте вопросы, мы ответим
Вы не зашли.
Что есть сейчас:
2 столбца "широта" и "долгота", в формате double(9,6)
Поиск вхождения точки в полигон из четырёх сторон по такому алгоритму:
). Я понимаю, что для радиуса он намного лучше, но что делать со старыми задачами? И тут как бы два момента:Неактивен
Почему бы Вам не воспользоваться mysql'евскими типами данных и соответствующими индексами ( http://dev.mysql.com/doc/refman/5.0/en/ … sions.html )? Там и функции есть некоторые геометрические.
Неактивен
deadka написал:
Почему бы Вам не воспользоваться mysql'евскими типами данных и соответствующими индексами ( http://dev.mysql.com/doc/refman/5.0/en/ … sions.html )? Там и функции есть некоторые геометрические.
Ну когда делался первый вариант уже не помню почему это отвергли. Сейчас проблема в том, чтобы не сломать готовый велосипед. Ну то, что вы скинули, это тот же POINT, что я сверху указала. Вопрос был в другом, я понимаю, что мимо него мне не куда не деться, для выдачи по радиусу. Но его проблема в читаемости данных, они там своими кракозябрами записаны, а данные нам нужно не только находить, но и выдавать обратно. Так, что я думаю POINT сделать по соседству с уже используемыми столбцами.
Вопросы в принципе следующие:
- стоит ли избавляться от плавающей точки?
- если с радиусом как бы ясно, то с вхождением в прямоугольник, обгонит ли GIS функция указанный сверху алгоритм? Ведь для этого нужно будет задавать полигон, это всё конвертации лишние.
Неактивен
Если количество знаков после запятой фиксировано, всм ограничено сверху, то я бы скорее рекомендовал тип decimal. Сам его использую в гис-проекте, и норм.
Что до обгоняния - тут проверять надо 
, слишком от многих факторов зависит. Как померите скорость - обязательно расскажите, что получилось 
.
Неактивен
deadka написал:
Если количество знаков после запятой фиксировано, всм ограничено сверху, то я бы скорее рекомендовал тип decimal. Сам его использую в гис-проекте, и норм.
Что до обгоняния - тут проверять надо
фиксировано - всегда одинаково? Если так, то нет, иногда гугл выдаёт не полную длину кушая нули в конце. Я где-то буквально сегодня начиталась, что по какой-то причине при SELECT тип влияет на скорость поиска. Наткнулась случайно, там стояло, что если погрешность сильно напрягает, как например денежные операции, то стоит использовать DECIMAL, но он будет медленнее, чем DOUBLE/FLOUT при поиске.
deadka написал:
Что до обгоняния - тут проверять надо
Я надеялась, что либо уже кто-то проверял до меня, либо хотя бы в теории подскажут. Пока не обновим локальный тест-сервер, до уровня продакшена, на нём нету смысла тестить
Отредактированно animegirl (26.07.2014 15:35:16)
Неактивен
