- 1
ORDER BY (|lng - :lng| + |lat - :lat|) ASC LIMIT 1-
SQL / Говнокод #29223
0
«Иногда нам нужно определить местоположение пользователя, когда мы точно знаем его координаты (например получили их используя датчики GPS устройства или Geolocation API в браузере). Тут есть два варианта — обратное геокодирование нам возвращает название того места, где находится пользователь. Но что произойдет, если пользователь находится где-то на трассе между городами, или в пригороде или просто в чистом поле и хочет посмотреть объявления о продаже участков на этом поле? Не всегда обратный геокодер с этим справится.
В этом случае лично я поступаю так — у меня в базе данных хранятся все координаты городов России, в которых у нас имеются объявления и с которыми мы вообще работаем. И по координатам пользователя я просто определяю ближайший к нему город из нашей базы, с помощью простого запроса.»
С Х-ра. Кто сразу поймёт, почему эта формула плоха?Запостил:
HoBorogHuu_nemyx,
26 Января 2026
Follow us!
Метки: #sql #geocoding #geolocation #геометрия #ма-те-ма-ти-ка
1/1 километр разницы это расстояние в 1.414, когда 1.9/0 это 1.9
чёт мало сложных задачек в последнее время в этой соцсети
ссылку на хабр бы ещё, чтобы посмотреть, как ему в панаму насовали
upd: https://habr.com/ru/articles/462011/
Такая метрика (если исправить следующую ошибку, на которую я намекаю) называется «метрикой Нью-Йорка», в ней направления по меридианам и по параллелям предпочтительнее направлений по другим азимутам.
Но это ещё не всё. Подсказка про вторую ошибку: эта формула работает только в окрестностях экватора.
один градус соответствует разному расстоянию в зависимости от положения на планете. чем ближе к полюс, тем больше сжимается долгота
На экваторе цена градуса долготы около 111 км (как и широты), на широте Питера — около 55 км (а градус широты по-прежнему 111 км). Долготу надо домножать на косинус широты. Т. е. на широте Питера запрос из заметки будет чаще выдавать объекты к северу и к югу от тебя, а объекты к западу и к востоку от тебя будет ошибочно считать расположенными в два раза дальше.
Оставлю вопрос пирфоманса, вернусь к геометрии.
Теперь ви таки будете смеяться, но то, что нужно автору, есть даже в крошке Мю:
https://dev.mysql.com/doc/refman/8.4/en/creating-spatial-indexes.html
SRID 4326 — это вот эта питушня:
https://epsg.io/4326
А так считается расстояние:
https://dev.mysql.com/doc/refman/8.4/en/spatial-relation-functions-object-shapes.html#function_st-distance
Да, готовая функция есть даже в крошке Мю!
https://habr.com/ru/companies/otus/articles/858680/
Эквидистанта точки в данной метрике будет иметь форму не привычной нам окружности, а квадрата, поставленного на угол (повёрнутого на 45 градусов).
Есть ещё одна метрика с «квадратной окружностью»: если в исходной формуле плюс заменим на функцию MAX, то получим метрику Пафнутия Львовича Чебышёва. В ней эквидистантой точки будет квадрат с горизонтальными и вертикальными сторонами.
Если алгоритм с манхэттенской метрикой неохотно показывает объекты по азимутам 45° (135°, 225°, 315°), то алгоритм с метрикой Чебышёва наоборот, будет выдавать их чаще.
Какое 1D )))
https://postgis.net/workshops/postgis-intro/indexing.html
https://ru.wikipedia.org/wiki/SpatiaLite
Но это же надо документацию по СУБД читать...
Допустим, автор не знал, что именно искать в документации. Но оказалось, что он живёт в плоском (если даже не в одномерном) мире.
Библиотекарь (Плоский мир)
> если даже не в одномерном
гологуб вон выше тоже заметил.
> Но это же надо документацию по СУБД читать...
правельно зачем что-то читать я вообще храню отношения много ко многим черех зопаятую в таблице и мне хорошо