потому что не бывает расстояния в градусах

Понятно, ладненько забил. Оставил как примерный размер, для визуализации с шестиугольниками правильной формы пойдёт. Вопрос про h3geo. У меня через пару недель станет вопрос mapmatching. Естественно делать буду не на postgis, данных много и прилетает и нужно будет делать в реальном времени. Выбираю между h3 и s2 индексов для того что бы выбирать ближайшие рёбра дорожного графа. Вот и думаю что лучше использовать. У нас стек на golang и есть порт s2 без cgo, но ее разработка уж очень давно не активна, h3 и можно и развивается. По идеи h3 для индексации линий лучше подходит.

да ну, вон даже на гислабе есть
https://gis-lab.info/qa/sphere-geodesic-direct-problem.html#:~:text=Прямая геодезическая задача — это нахождение,значениям начального направления и расстояния.

чож так сложно та, только с s2 разабралися тут ещё гексагональный h3 😳😳😳

Подскажите, по вашему мнению. Какой лучше индекс использовать для хранения в памяти коллекций пространственных объектов и поиска ближайших? В s2 все делают обычный btree. Геометрии линейные - рёбра дорожного графа, задача очень быстро найти ближайшие рёбра к точке. Соответственно в h3 есть функции для индексации прямых между двумя точками, и для одного рёбра будет коллекция таких линий.

gist

Я не постгис имею ввиду:) очень накладно в БД постоянно бегать да и логику разбивать не хочется.

эмм
если ты хранишь данные не в БД, то то, где ты хранишь данные, становится БД

перенеси тогда логику в БД и не выходи из неё

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

а так ты будешь просто заново писать R-дерево

Делаю (собираюсь) алгоритм mapmatching соответственно постоянно валятся точки, для того что бы работал алгоритм нужно искать рёбра кандидаты, дальше скрытая Марковская цепь и поиск пути по графу от последней точки с вероятностью привязывает трек к рёбрам графа удс. Точек примерно до 1000 в секунду. Соответственно ходить в базу 1000 раз в секунду и получать 2-3 рёбра это плохо. Перенести поиск пути в БД это ж, пробовал работает жутко медленно. Идея (подсмотрено) в том что бы забрать из БД все рёбра в память, построить граф, и проиндексировать рёбра h3, вот собственно и вопрос в какой структуре данных в таком случае лучше держать индекс что бы можно было средствами h3 быстро сравнивать и находить ближайшие рёбра. Если говорить про Rдерево то тут вопрос насколько оно выигрывает по сравнению с b деревом, с учётом того что индекс строится по инту (h3Index)

H3CellID

В s2 все проще, потому что разница между CellID на одном уровне, мала там где физическое расстояние в пространстве мало - свойства гильбертовой кривой. Ну ладно, позже не туда вопрос, это про то как работает h3 индексация и как ее использовать

ты переписываешь заново osrm /match ?

Osmr мне не подходит, у меня своя информация по дорожной сети

Перекрытия и прочее

так положи их в osrm

он нормально динамические веса умеет