Комментарии 12
Проблема геохеша (соседние клетки) вроде решается: www.bigfastblog.com/geohash-intro (раздел The Gotcha Solution)
Вы, кажется, перепутали 0 у широты и долготы.
А как с производительностью этого запроса, используя PostGis?
На каком числе записей тестировался указанный в статье запрос, который занял полсекунды?
Вы рассматривали/сравнивали с той же функциональностью в ElasticSearch?
На каком числе записей тестировался указанный в статье запрос, который занял полсекунды?
Вы рассматривали/сравнивали с той же функциональностью в ElasticSearch?
Как вариант, не для вашей задачи, наверное, просто в качестве доп информации. У радиолюбителей для определения локации кореспондента используется QTH-Locator
Наверняка расширения для PGSQL нет, но система достаточно удобная, с несколькими градациями точности. Как правило хватает 6 знаков.
Здесь можно узнать свой QTH — http://no.nonsense.ee/qth/map.html, если интересно.
Наверняка расширения для PGSQL нет, но система достаточно удобная, с несколькими градациями точности. Как правило хватает 6 знаков.
Здесь можно узнать свой QTH — http://no.nonsense.ee/qth/map.html, если интересно.
По сути gist индекс в постгрешке — это тот же префиксный поиск что и с гео-хэшем. И еще посмотреите Hilbert Curves Locality Preserving Hashing — там другой принцип обхода ячеек, и, в среднем по больнице, хэши соседей лежат ближе друг к другу.
Мы решали такую же задачу. Заюзали готовое kd-tree. 1 млн точек. Скорость около 100к операций в сек. java. Нас устроило, дальше не копали.
А кто в курсе как дела с производительностью гео-поиска у MongoDB?
Наверное уже не актуально, но всё же напишу, мало ли кому понадобиться.
В MongoDB есть возможность работать с GeoJson, с помощью 2dsphere. К сожалению гео-запросов очень мало, по этому разгуляться не получиться, да и поиск работает в разы медленнее чем postgis. Но если задача сводиться к поиску ближайшей точки из небольшего списка точек/линий/полигонов — тогда mongodb будет хорошим вариантом. А вот в случае если необходимо создать обратный геокодер — то лучше воспользоваться postgres [postgis].
В MongoDB есть возможность работать с GeoJson, с помощью 2dsphere. К сожалению гео-запросов очень мало, по этому разгуляться не получиться, да и поиск работает в разы медленнее чем postgis. Но если задача сводиться к поиску ближайшей точки из небольшего списка точек/линий/полигонов — тогда mongodb будет хорошим вариантом. А вот в случае если необходимо создать обратный геокодер — то лучше воспользоваться postgres [postgis].
Геохешинг выглядит каким-то искусственным и накрученным усложнением с непонятными преимуществами. Мороки много, а смысла мало.
Если большая точность не нужна, просто используем float одинарной точности, да и все. Байтов меньше, точность примерно такая же, мороки ноль.
Если точность критична, тогда double. Зачем усложнять на ровном месте?
Если большая точность не нужна, просто используем float одинарной точности, да и все. Байтов меньше, точность примерно такая же, мороки ноль.
Если точность критична, тогда double. Зачем усложнять на ровном месте?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с геолокациями в режиме highload