JTS с широтой/долготой

У меня есть некоторые пространственные данные, все координаты которых представлены в виде пар широта/долгота (с десятичной точностью около 10 цифр), они хранятся в базе данных как данные WGS84. Некоторые данные представлены в виде многоугольников, которые являются результирующим объединением несколько меньших полигонов, границы которых сохраняются. Затем у меня есть несколько точек, из которых я строю сегменты линий (всего 2 точки в каждом сегменте), которые я использую позже для тестов пересечения с полигонами.

Я использую SpatialIndex для улучшения своих запросов, поэтому я вставляю оболочки всех полигонов в дерево (протестировано как с QuadTree, так и с STRtree). Затем я соединяю две точки в линейный сегмент и использую его оболочку для запроса дерева. для возможных пересечений. Проблема в том, что в результате я получаю почти все полигоны, что явно неверно. Чтобы дать вам некоторое представление о реальном масштабе моих данных, у меня есть около 100 полигонов, которые охватывают всю Северную Америку, каждый линия покрывает очень-очень маленькую часть одного полигона. В идеале я бы ожидал, что в результате получится не более 2-х полигонов.

Я использую JTS для этого расчета, и я знаю, что он не очень подходит для сферических данных, поэтому можете ли вы предложить мне другую библиотеку/инструмент для достижения желаемого поведения или возможного обходного пути (например, проецирование перед использованием JTS)?


jts latitude-longitude spatial-index
person dpp    schedule 03.03.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если у вас есть только Северная Америка, просто поверните землю на 90 градусов, чтобы Аляска больше не находилась на дальнем востоке. (Забавный факт: Аляска — это одновременно и самый северный, и западный, и восточный штат США). Тогда ваши прямоугольники должны быть в порядке.

Однако есть ряд нетривиальных случаев при работе со сферическими данными. В зависимости от того, как определены ваши данные, границы полигонов могут быть изогнутыми линиями, а не прямыми. Рассмотрим этот скриншот Google Ingress: https://lh4.ggpht.com/S_9jrMqf08JfIbr7DgUDH96rvXMK4wOGtaSKYPGCruXv2HE4oeRuEaQIDIywMgH4198=h900

Я где-то читал, что несоответствие текстуры «тумана» и зеленой линии, видимой в левом поле, связано с тем, что две функции рисования используют разные приближения. Одна всегда прямая, а другая повторяет кривизну земли. Если у вас большое поле (полигон!), ошибка становится хуже.

К сожалению, «пересечение» становится сложным термином, когда ваши данные состоят из непрямых линий на поверхности сферы; а «прямая» линия на поверхности земли часто дает кривую арктангенса в широтных координатах.

Прогнозы: они могут помочь, но в основном, когда ваши данные локальны. Проекции UTM довольно хороши, но вам нужно как минимум 9 зон UTM, чтобы охватить Северную Америку без Аляски. Пока ваши данные находятся в пределах одной зоны UTM, проецирование данных в эту зону и последующая работа с двумерным евклидовым пространством должны работать хорошо. Но если это станет больше, чем это, вам может понадобиться сшить разные проекции, и это тоже очень грязно.

person Has QUIT--Anony-Mousse    schedule 22.04.2014