Хранение геодезических координат в базе данных

← →
ShaggyDoc © (2002-09-05 09:32) [0]

Задача: хранить в одной из таблиц БД геодезические координаты объектов (земельных участков, трасс и т.п.).
Каждый объект может иметь две и более (обычно до нескольких десятков, но отдельные - до нескольких сотен) вершины.
Каждая вершина имеет координату из трех чисел X,Y,Z

В БД надо хранить список координат вершин.

Уже лет 10 использую такую технологию:

1. Объекты с координатами хранятся в одной из таблиц.
2. Координаты хранятся в MEMO в виде текстовой строки-списка в нескольких форматах (так сложилось исторически для разных систем), например:

((x1 y1 z1)(x2 y2 z2)...(xn yn zn))

Имеется специальный компонент для отображения контуров, экспорт-импорт и т.д. Все прекрасно работает.
Теперь возникло желание написать некий "географический SQL", позволяющий находить объекты по пространственному признаку, например
"лежащие внутри конутра" "проходящие рядом" "пересекающие контур" и т.п.
Очевидно это потребует другого способа хранения данных.

Вопрос: Может ли кто-нибудь предложить более рациональный способ?

Про хранение в Oracle SpatialWare я знаю, нужен свой формат. Возможные БД - Interbase, Access

← →
Lord Warlock © (2002-09-05 09:40) [1]

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

← →
Alex Y © (2002-09-05 10:39) [2]

2 Lord Warlock
А не поделишся алгоритмами этой самой геометрии буду очень признателен.

← →
ShaggyDoc © (2002-09-05 11:13) [3]

>Lord Warlock © (05.09.02 09:40)
Это традиционый для разработчиков БД способ. Здесь все понятно. Много достоинств и много недостатков.

Хочется один объект - одна запись. Из условий обмена информацией, использования этой таблицы в разных системах и т.п.

← →
roottim (2002-09-05 11:29) [4]

для плоских БД, подойдет только мастер-деталь, и это не есть минус!
и ежели хочется именно так как есть, то видимо необходимо будет написать несколько ХП для извлечения координат и использования их в СКЛ

← →
Alex Y © (2002-09-05 11:36) [5]

2 ShaggyDoc могу предложить такой вариант
Храни координаты в Memo, а для поиска поля MinX,MinY,MaxX,MaxY - область покрытия объекта. По этим координатам можно определить примерное наложение, а далее разбирай координаты из Memo в полученной выборке.

← →
KDS © (2002-09-05 12:07) [6]

Необходимо использовать две таблицы А (объекты) и Б(координаты)
Структура А
Field, Type
------ ---------
ID_Obj Integer
Obj_Name String(50)
===============
Структура Б
Field, Type
------ ---------
ID_Obj Integer
X Float
Y Float
Z Float
======================
Связывать А с Б или фильтровать вторую таблицу по полю ID_Obj

← →
Jeer © (2002-09-05 12:36) [7]

>Теперь возникло желание написать некий "географический SQL",

Postgres 7.2 поддерживает геометрические типы и определяет множество операций над ними.
К сожалению, Вы не включили эту СУБД в свой список..

# Number of points in polygon
## Point of closest proximity point
&& Overlaps? box
&< Overlaps to left? box
&> Overlaps to right? box
<-> Distance between circle
?- Is horizontal?
?-| Is perpendicular?

etc

← →
Desdechado © (2002-09-05 12:43) [8]

для Interbase это делается достаточно просто (я бы так делал). Написать UDF, которая, получая на вход MEMO, анализирует нужным способом и выдает результат. Любую UDF можно включить прямо в запрос. Есть правда большой недостаток - последовательный перебор записей без индексов и реализуемость только в IB.

← →
Shaman_Naydak © (2002-09-05 15:29) [9]

Честно говоря, мне странно видеть, как идут на нарушение 1-ой нормальной формы, а потом пытаются эффективно работать!

"Человек любит создавать себе трудности, чтобы потом их с восторгом преодолевать!"

← →
Ura (2002-09-05 16:15) [10]

А может так.
Вариант 1
Таблицы
1. Объекты
2. Типы координат
3. Координаты объектов
4. Типы объектов
5. Лепим процедуры по геомериии - на входе только данные значения
аля API для этой базы
Вариант 2
ОБЪЕКТНЫЕ БАЗЫ
Работаем только через объект, а внутри него есть все его данные, но в нутри похожая система как раньше.

← →
Ларик (2002-09-05 19:08) [11]

Я бы сделал так:

таблица OB (объекты)
--------------------
ID integer (ключ)
прочие поля (тип объекта и т.д.)
--------------------

таблица OBCHAIN (координатные цепочки)
--------------------
ID integer (ключ)
OB_ID integer (объект)
NN integer (порядковый N точки в цепочке)
X float
Y float
Z float
--------------------

Вроде нормально, но есть одна проблема. Если сделать выборку по условию типа: (X>x1) AND (X<x2) AND (Y>y1) AND (Y<y2) AND (Z>z1) AND (Z<z2) то компьютер "перелопатит" всю таблицу от начала до конца. Тут как ни строй индекс, ничего не выйдет. В лучшем случае, можно сократить перебор лишь по одной из координат. Если база данных большая, то это препятствие может сильно испортить жизнь.

Чтобы избежать этого, можно добавить в таблицу одно избыточное поле BOX

таблица OBCHAIN (координатные цепочки)
--------------------
ID integer (ключ)
OB_ID integer (объект)
NN integer (порядковый N точки в цепочке)
X float
Y float
Z float
BOX integer (номер клетки)
--------------------
строим индекс для ускорения поиска: BOX,OB_ID,NN

Что это за клетки такие?
Заранее все гипотетическое пространство условно делим на клетки-кубики. Клетки нумеруем каким-либо простым образом. Строим функцию, BOX_NO которая по любой тройке координат (x,y,z) находит номер клетки. Поле BOX заполняем с помощью нее:
BOX=BOX_NO(X,Y,Z). Заботу об этом можно переложить на соответствующий тригер (если все делать в InterBase). Теперь можно осуществлять перебор только в пределах одной клетки.

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

Размер клетки не должен быть слишком большим и не должен быть слишком маленьким. Все зависит от задачи и интуиции.

← →
ShaggyDoc © (2002-09-06 06:58) [12]

Спасибо всем. К счастью (или к сожалению) все это мы уже проходили. Только Jeer © (05.09.02 12:36) указал на неизвестные мне ранее сведения.

Что касается еретических отступлений от нормализации (Shaman_Naydak © (05.09.02 15:29)), то суть в том, что делаются не конкретные приложения с известной структурой данных (это отдельные частные задачи), а универсальная базовая система, в которой основной является БД (или таблица) с координатами контуров, идентификатором и, возможно, минимумом единых атрибутов.

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

>Ларик (05.09.02 19:08)
"Клетки", которые вы предлагаете сущестуют реально и называются топографическими планшетами. Это квадрат на местности со строго определенным именем и определенными координатами. Ваш способ очень хорош тем, что могут использоваться понятия, используемые многими специалистами. То есть результатом может быть и список клеток-планшетов, а это бывает очень нужно. Это реализовано гораздо проще в графической части, про которую я здесь не упоминал.

А пользоваться стандартными геоинформационными пакетами не приходило в голову? Или это дорого и не совсем подходит для вашей конкретной задачи? Например MapInfo Professional и другие продукты MapInfo (MapX и т.д.)? На MapInfo и crack имеется, если не требуется обязательно лицензионное ПО...

>>Nikolai_S © (06.09.02 10:37)
Почему же не приходило? У меня имеется и легальная Mapinfo, и легальная MapX, и много еще чего. Но как раз работа с базами данных в Mapinfo весьма примитивна. Вернее с ее таблицами. Довольна удобна для локальной работы (за исключением убогого до неприличия интерфейса редактирования и просмотра таблиц). Когда ГИС-аналитик какдые полчаса перестраивает структуру данных.

Крупнейший недостаток, как и многих других ГИС, что координатная информация сидит во внутреннем графическом формате (за исключением точек с X и Y). Чем все пользователи привязываются к конкретной системе.

Может работать с таблицами DBF и Access, но только с ограниченными типами данных. Ни МЕМО, ни графики. При работе с удаленными БД то же делает копии данных в свои локальные таблицы.

Вот и делаем свою СУБД для ГИС, из которой данные могут посылаться в том числе и в Mapinfo

Ну тут могу не согласиться. Зачем все данные запихивать в MapInfo? Да, она позволяет хранить данные, поддерживает какие-то СУБД даже. Достаточно хранить ключевое поле в таблице MapInfo, а все данные в своей СУБД, которая имеет свою структуру, а географические нужные объекты привязаны со своей СУБД по своему ключевому полю. Я так работаю - и это очень удобно. MapX тоже поддерживает много СУБД и разные технологии (ODBC, ADO, BDE и т.д.). Помимо этого MapX имеет много встроенных гео-функций, позволяет получить полный доступ к гео-объектам карты, и самое главное позоваляет встраивать карту в свое приложение, в котором свой интерфес и свой набор функций-инструментов, удобных для аналитика...

Ну а экспорт в другие ГИС-системы есть и MapInfo, да и с помощью MapX тоже можно это делать

В целом с ГИС все сложнее. Мы делаем систему областного уровня, в которую входят и ГИС разных городов и предприятий. Работают с разными инструментами. И MapInfo, и AutoCAD, и ИнГЕО и др. И привести к единому никак нельзя, не по техническим, а по "политическим" причинам.

Каждый считает "Я так работаю - и это очень удобно".

А надо вместе, разумно сочетая разделение и совместное использование данных. Экспорт данных - половинчатое решение. Пока все на стадии "доказательства концепции" - помогает. Но это мы уже прошли. Надо не "какие-то СУБД даже", и не только ODBC. И с доступом через Интернет, и много чего еще.

Вот такой координацией и приходится заниматься.

Ну раз политические причины, то дело другое. Ну а доступ через интернет MapInfo предоставляет (MapInfo MapXStream, MapInfo MapX Site и др.).

Хранение геодезических координат в базе данных Найти похожие ветки