| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Хранение геодезических координат в базе данных [D6, IB6.x, dBase, FoxPro, Paradox]
ShaggyDoc © (2002-09-05 09:32:00)Задача: хранить в одной из таблиц БД геодезические координаты объектов (земельных участков, трасс и т.п.).
Каждый объект может иметь две и более (обычно до нескольких десятков, но отдельные - до нескольких сотен) вершины.
Каждая вершина имеет координату из трех чисел X,Y,Z
В БД надо хранить список координат вершин.
Уже лет 10 использую такую технологию:
1. Объекты с координатами хранятся в одной из таблиц.
2. Координаты хранятся в MEMO в виде текстовой строки-списка в нескольких форматах (так сложилось исторически для разных систем), например:
((x1 y1 z1)(x2 y2 z2)...(xn yn zn))
Имеется специальный компонент для отображения контуров, экспорт-импорт и т.д. Все прекрасно работает.
Теперь возникло желание написать некий "географический SQL", позволяющий находить объекты по пространственному признаку, например
"лежащие внутри конутра" "проходящие рядом" "пересекающие контур" и т.п.
Очевидно это потребует другого способа хранения данных.
Вопрос: Может ли кто-нибудь предложить более рациональный способ?
Про хранение в Oracle SpatialWare я знаю, нужен свой формат. Возможные БД - Interbase, Access
Nikolai_S (2002-09-06 12:27:00) [1]Ну раз политические причины, то дело другое. Ну а доступ через интернет MapInfo предоставляет (MapInfo MapXStream, MapInfo MapX Site и др.).
ShaggyDoc (2002-09-06 12:16:00) [2]В целом с ГИС все сложнее. Мы делаем систему областного уровня, в которую входят и ГИС разных городов и предприятий. Работают с разными инструментами. И MapInfo, и AutoCAD, и ИнГЕО и др. И привести к единому никак нельзя, не по техническим, а по "политическим" причинам.
Каждый считает "Я так работаю - и это очень удобно".
А надо вместе, разумно сочетая разделение и совместное использование данных. Экспорт данных - половинчатое решение. Пока все на стадии "доказательства концепции" - помогает. Но это мы уже прошли. Надо не "какие-то СУБД даже", и не только ODBC. И с доступом через Интернет, и много чего еще.
Вот такой координацией и приходится заниматься.
Nikolai_S (2002-09-06 11:44:00) [3]Ну а экспорт в другие ГИС-системы есть и MapInfo, да и с помощью MapX тоже можно это делать
Nikolai_S (2002-09-06 11:39:00) [4]Ну тут могу не согласиться. Зачем все данные запихивать в MapInfo? Да, она позволяет хранить данные, поддерживает какие-то СУБД даже. Достаточно хранить ключевое поле в таблице MapInfo, а все данные в своей СУБД, которая имеет свою структуру, а географические нужные объекты привязаны со своей СУБД по своему ключевому полю. Я так работаю - и это очень удобно. MapX тоже поддерживает много СУБД и разные технологии (ODBC, ADO, BDE и т.д.). Помимо этого MapX имеет много встроенных гео-функций, позволяет получить полный доступ к гео-объектам карты, и самое главное позоваляет встраивать карту в свое приложение, в котором свой интерфес и свой набор функций-инструментов, удобных для аналитика...
ShaggyDoc (2002-09-06 11:28:00) [5]>>Nikolai_S © (06.09.02 10:37)
Почему же не приходило? У меня имеется и легальная Mapinfo, и легальная MapX, и много еще чего. Но как раз работа с базами данных в Mapinfo весьма примитивна. Вернее с ее таблицами. Довольна удобна для локальной работы (за исключением убогого до неприличия интерфейса редактирования и просмотра таблиц). Когда ГИС-аналитик какдые полчаса перестраивает структуру данных.
Крупнейший недостаток, как и многих других ГИС, что координатная информация сидит во внутреннем графическом формате (за исключением точек с X и Y). Чем все пользователи привязываются к конкретной системе.
Может работать с таблицами DBF и Access, но только с ограниченными типами данных. Ни МЕМО, ни графики. При работе с удаленными БД то же делает копии данных в свои локальные таблицы.
Вот и делаем свою СУБД для ГИС, из которой данные могут посылаться в том числе и в Mapinfo
Nikolai_S (2002-09-06 10:37:00) [6]А пользоваться стандартными геоинформационными пакетами не приходило в голову? Или это дорого и не совсем подходит для вашей конкретной задачи? Например MapInfo Professional и другие продукты MapInfo (MapX и т.д.)? На MapInfo и crack имеется, если не требуется обязательно лицензионное ПО...
ShaggyDoc (2002-09-06 06:58:00) [7]Спасибо всем. К счастью (или к сожалению) все это мы уже проходили. Только Jeer © (05.09.02 12:36) указал на неизвестные мне ранее сведения.
Что касается еретических отступлений от нормализации (Shaman_Naydak © (05.09.02 15:29)), то суть в том, что делаются не конкретные приложения с известной структурой данных (это отдельные частные задачи), а универсальная базовая система, в которой основной является БД (или таблица) с координатами контуров, идентификатором и, возможно, минимумом единых атрибутов.
Другие данные привязываются к контурам разными организациями независимо друг от друга. Например, здание "Дом Архитекторов" с одной точки зрения очаг культуры, с другой - притон, где тараканятся всякие бородатые шаромыги, с третьей - абонент электросетей с определенной нагрузкой и долгами. Но все эти данные привязываются к одному контуру, заданному списком координат.
>Ларик (05.09.02 19:08)
"Клетки", которые вы предлагаете сущестуют реально и называются топографическими планшетами. Это квадрат на местности со строго определенным именем и определенными координатами. Ваш способ очень хорош тем, что могут использоваться понятия, используемые многими специалистами. То есть результатом может быть и список клеток-планшетов, а это бывает очень нужно. Это реализовано гораздо проще в графической части, про которую я здесь не упоминал.
Ларик (2002-09-05 19:08:00) [8]Я бы сделал так:
таблица 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). Теперь можно осуществлять перебор только в пределах одной клетки.
Чтобы делать перебор в произвольном параллелепипеде, нужно написать встроенную процедуру, которая возвращает список клеток, попадающих в этот параллелепипед. После чего, делать перебор в каждой клетке отдельно.
Размер клетки не должен быть слишком большим и не должен быть слишком маленьким. Все зависит от задачи и интуиции.
Ura (2002-09-05 16:15:00) [9]А может так.
Вариант 1
Таблицы
1. Объекты
2. Типы координат
3. Координаты объектов
4. Типы объектов
5. Лепим процедуры по геомериии - на входе только данные значения
аля API для этой базы
Вариант 2
ОБЪЕКТНЫЕ БАЗЫ
Работаем только через объект, а внутри него есть все его данные, но в нутри похожая система как раньше.
Shaman_Naydak (2002-09-05 15:29:00) [10]Честно говоря, мне странно видеть, как идут на нарушение 1-ой нормальной формы, а потом пытаются эффективно работать!
"Человек любит создавать себе трудности, чтобы потом их с восторгом преодолевать!"
Desdechado (2002-09-05 12:43:00) [11]для Interbase это делается достаточно просто (я бы так делал). Написать UDF, которая, получая на вход MEMO, анализирует нужным способом и выдает результат. Любую UDF можно включить прямо в запрос. Есть правда большой недостаток - последовательный перебор записей без индексов и реализуемость только в IB.
Jeer (2002-09-05 12:36:00) [12]>Теперь возникло желание написать некий "географический 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
KDS (2002-09-05 12:07:00) [13]Необходимо использовать две таблицы А (объекты) и Б(координаты)
Структура А
Field, Type
------ ---------
ID_Obj Integer
Obj_Name String(50)
===============
Структура Б
Field, Type
------ ---------
ID_Obj Integer
X Float
Y Float
Z Float
======================
Связывать А с Б или фильтровать вторую таблицу по полю ID_Obj
Alex Y (2002-09-05 11:36:00) [14]2 ShaggyDoc могу предложить такой вариант
Храни координаты в Memo, а для поиска поля MinX,MinY,MaxX,MaxY - область покрытия объекта. По этим координатам можно определить примерное наложение, а далее разбирай координаты из Memo в полученной выборке.
roottim (2002-09-05 11:29:00) [15]для плоских БД, подойдет только мастер-деталь, и это не есть минус!
и ежели хочется именно так как есть, то видимо необходимо будет написать несколько ХП для извлечения координат и использования их в СКЛ
ShaggyDoc (2002-09-05 11:13:00) [16]>Lord Warlock © (05.09.02 09:40)
Это традиционый для разработчиков БД способ. Здесь все понятно. Много достоинств и много недостатков.
Хочется один объект - одна запись. Из условий обмена информацией, использования этой таблицы в разных системах и т.п.
Alex Y (2002-09-05 10:39:00) [17]2 Lord Warlock
А не поделишся алгоритмами этой самой геометрии буду очень признателен.
Lord Warlock (2002-09-05 09:40:00) [18]Насчет рациональности не знаю, у меня аналогичная задача, данные хранятся в 2-х таблицах мастер-деталь. В мастере лежит описание примитивов, в детале - их координаты. В программе - здоровое дерево классов, которое все это читает, пишет из базы, добавляет, строит на их основе условные знаки, находит пересечения, вхождения и еще много чего. Насчет аналитической геометрии - все ручками, уже после загрузки данных из базы
| |
