Предварительная обработка полигонов и линий в области сетки для разделения данных

Из-за размера, количества и производительности моих полигональных запросов (полигон в полигоне) я хотел бы предварительно обработать свои данные и разделить полигоны на сетки. Мои данные довольно однородны в интересующей меня области, поэтому 12 четных сеток будут работать хорошо. Я могу скорректировать это число позже в зависимости от производительности. По сути, я собираюсь создать 12 таблиц со связанными пространственными индексами или, возможно, я просто создам одну таблицу с ключом раздела моей сетки. Это уменьшит мой общий размер индекса в 12 раз и, надеюсь, повысит производительность. Со стороны запроса я направлю запрос к соответствующей таблице.

Ключ для меня в том, чтобы понять, как группировать полигоны в эти сетки. Если полигон попадает в несколько сеток, я, скорее всего, создам запись в каждой и дедуплицирую по запросу. Я бы не ожидал, что это будет происходить очень часто.

По сути, у меня будет «сетка», которую я хочу пересечь с моим многоугольником и выяснить, в какие сетки попадает многоугольник.

Спасибо


person user2092856    schedule 28.02.2013    source источник


Ответы (1)


Мой процесс будет примерно таким:

  1. Найдите значения ординаты MIN/MAX для всего набора данных (обе оси)
  2. Расширьте эти значения с запасом, который кажется подходящим (в случае, если ординаты при объединении не образуют обычную прямоугольную форму)
  3. Напишите небольшой цикл, который генерирует многоугольники с заданным интервалом в пределах этих ординат MIN/MAX, т.е. создает один многоугольник на квадрат сетки.
  4. Используйте SDO_COVERS, чтобы увидеть, какие квадраты сетки покрывают каждый полигон. Если несколько квадратов сетки покрывают многоугольник, вы должны увидеть несколько совпадений, как вы описываете.

Я также согласен с вашей стратегией разделения данных в одной таблице. Я слышал положительные отзывы об этом, но я никогда не пробовал это лично. Накладные расходы на переход к нескольким столам кажутся тем, чего вам следует избегать.

person Ben    schedule 28.02.2013