Структура организации данных векторной карты

← →
Tab (2006-10-06 08:00) [0]

Собственно сабж. Если кто-нибудь этим занимался или есть идеи, поделитесь.

← →
Джо © (2006-10-06 08:08) [1]

> Если кто-нибудь этим занимался

Занимался.

> есть идеи

Были и идеи.

Только вопрос, ИМХО, слишком общий, чтобы на него можно было вразумительно ответить.

← →
Tab (2006-10-06 08:12) [2]

> Только вопрос, ИМХО, слишком общий, чтобы на него можно
> было вразумительно ответить.

Да действительно, уточню.
Интересует хранение данных , ну допустим в базе.
С линией и окружностьью все понятно, две точки, или точка и радиус. А как буть с многоугольником? Число точек ведь разное. Как хранить такие данные и в какую структуру их читать?

← →
MBo © (2006-10-06 08:13) [3]

Число точек, массив точек
Метафайлы не подойдут?

← →
Джо © (2006-10-06 08:19) [4]

> А как буть с многоугольником? Число точек ведь разное. Как
> хранить такие данные и в какую структуру их читать?

Ну, разве это проблема? :) Хранишь число узлов, затем сами координаты.

Кстати, если планируется использовать СУБД, то могу сразу посоветовать использовать бесплатную СУБД со встроенной поддержкой пространственных данных — PostgreSQL. Очень мощный инструмент.

← →
Tab (2006-10-06 08:37) [5]

> Хранишь число узлов, затем сами координаты.

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

что-то искал сейчас определение "поддержкой пространственных данных" почитал но до конца не понял что это?

← →
Джо © (2006-10-06 08:46) [6]

> [5] Tab (06.10.06 08:37)
> нет ну это понятно. как это будет выглядеть? число узлов
> один элемент,
> все координаты другой, просто как некое целое, не хранить
> же для каждого по столбцу?

Если не использовать СУБД, то реализовать это можно простейшим образом при помощи динамического массива. Для хранения в файле использовать схему: сначала записываем кол-во узлов, затем сами узлы.

> что-то искал сейчас определение "поддержкой пространственных
> данных" почитал но до конца не понял что это?

Что тут непонятного конкретно? Что есть "пространственные данные" (spatial data) понятно? А их поддержка в PostgreSQL подразумевает:
1. Готовые типа данных в СУБД для их хранения.
2. Набор функций для работы с ними.
3. Встроенные SQL-операторы для работы с ними.

← →
Tab (2006-10-06 08:53) [7]

Джо © (06.10.06 08:46) [6]

> Для хранения в файле использовать схему: сначала записываем
> кол-во узлов, затем сами узлы.

а если хранить данные в базе (простой)

> Что тут непонятного конкретно? Что есть "пространственные
> данные" (spatial data) понятно?

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

2 MBo

> Число точек, массив точекМетафайлы не подойдут?

метафайлы это хорошо, но только получается я потом не буду иметь контроля над отображением (или скрытием ) определенных элементов. Если не разбираться с форматом файла?

← →
Джо © (2006-10-06 08:58) [8]

> [7] Tab (06.10.06 08:53)
> а если хранить данные в базе (простой)

То это будет гемморой. :) Но решаемо, иногда даже довольно изящно. Зависит от того, что ты имеешь в виду под "простой базой". Oracle тоже, например, имеет готовую поддержку spatial data.

> чем они отличается от просто числа? могу только предположить,
> что это некий тип данных отражающий координаты точки в
> пространстве?

Не только "точки", разумеется. Есть тип данных POLYGON, CIRCLE, LINE и т.п. С готовыми функциями проверки на вхождение, пересечение и тому подобное.

← →
Tab (2006-10-06 09:04) [9]

> То это будет гемморой. :) Но решаемо, иногда даже довольно
> изящно. Зависит от того, что ты имеешь в виду под "простой
> базой". Oracle тоже, например, имеет готовую поддержку spatial
> data.

нет, под простой имел в виду, чтобы при распространении не пришлось много тащить за собой. Кстати PostgreSQL, только в виде сервера идет?

> Не только "точки", разумеется. Есть тип данных POLYGON,
> CIRCLE, LINE и т.п. С готовыми функциями проверки на вхождение,
> пересечение и тому подобное.

Хм, даже так. Ну тогда это действительно вещь.

← →
Джо © (2006-10-06 09:08) [10]

> [9] Tab (06.10.06 09:04)
> Кстати PostgreSQL, только в виде сервера идет?

Кому бы, интересно, нужен был только "сервер" без клиента? :) Клиентская библиотека, libpq.dll, занимает примерно 200 Кб.

← →
MBo © (2006-10-06 09:09) [11]

>метафайлы это хорошо, но только получается я потом не буду иметь контроля

можно воспользоваться концепцией.
Метафайл - набор команд, записей, содержащих размер записи, идентификатор граф. примитива и блок данных (разного типа в завимимости от примитива)

← →
Джо © (2006-10-06 09:10) [12]

Ну, еще ODBC-драйвер в систему (к примеру), если native-доступ слишком неудобен.

← →
ShaggyDoc (2006-10-06 09:16) [13]

Если бы было так просто - взял PostgreSQL и все... Или Oracle SpatialWare...

Нет, не зря разрабатываются разные системы хранения пространственных данных в БД. Обычно секреты такого хранения и использования все прячут. Ну, с хранением можно и просто решить, а вот использовать...

Прежде всего программа должна уметь нарисовать в какой-то графической среде пространственную информацию. Обычно используется три вида - точка (один список координат, чаще только X, Y, хотя может быть и Z), Линия (список точек с возможным флагом замкнутости) и полигон (замкнутая полилиния, возможно несколько контуров для одного объекта).

Где-то еще должен быть описан способ отображения - условный знак, цвет, заливка и т.п. Визуальный вид желательно отделять от координат, так как для разных задач он может меняться, в том числе динамически. Это все лучше выносить из СУБД в некий "проект" и хранить, например, в XML. Хотя есть и варианты - в Mapinfo офомление в файле "рабочего пространства", являющегося просто программой на специальном языке MapBasic.

В итоге в БД должен для каждого объекта храниться список координат. Для частного случая точки - список из одной координаты.

Просто точки можно хранить в полях таблицы X,Y и это неинтересно. Многоточечные списки можно хранить в таблице, где для каждой вершины - одна запись. Это просто, но в работе чрезвычайно неудобно и ненадежно.

И есть подход, когда в таблице каждому объекту соответствует запись, а координаты хранятся в MEMO или BLOB. Вот здесь и начинаются фирменные секреты - формат хранения. Мне приходилось делать несколько, сейчас остановились на формате, совместимом с AlovMap. Он же используется еще в нескольких ГИС. Для раскрытия "секрета" пришлось поковыряться в исходниках. Но зато теперь можем хранить в любой таблице любой СУБД. Опробовано на всем - от примитивного DBF до Firebird и MySQL. Кстати, в MySQL карты строятся раз в 10 быстрее, чем из Firebird.

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

Ну и еще есть варианты хранения в текстовых форматах. Самый простой и известный MIF/MID от Mapinfo. Он вообще-то для экспорта-импорта, но ничто не мешает (кроме открытости) использовать как хранилище вообще.

И есть несколько диалектов "географических XML" - LandXML, например. Все просто, легко обрабатывается, но чересчур объемно.

← →
Tab (2006-10-06 09:19) [14]

2 MBo

> можно воспользоваться концепцией.Метафайл - набор команд,
> записей, содержащих размер записи, идентификатор граф.
> примитива и блок данных (разного типа в завимимости от примитива)

по сути свой формат вообщем. да это было бы хорошо.
Но с другой стороны если требуется найти объект по признакам придеться весь файл просмотреть.

> Ну, еще ODBC-драйвер в систему (к примеру), если native-
> доступ слишком неудобен.

для локального компьютера наверное так и придеться делать.
киньте ссылку плиз (на оффсайте почему то нету). А может есть какие то компоненты работющие напрямую?

← →
Джо © (2006-10-06 09:21) [15]

> [13] ShaggyDoc (06.10.06 09:16)
> Если бы было так просто - взял PostgreSQL и все... Или Oracle
> SpatialWare...

Кто же говорит, что "просто"?! Очень даже не просто. Просто пока речь шла просто о хранении данных.

← →
Джо © (2006-10-06 09:23) [16]

> И есть несколько диалектов "географических XML" - LandXML,
> например. Все просто, легко обрабатывается, но чересчур
> объемно.

Я бы сказал, что черезчур "тормознутно". Но это, конечно, на любителя.

← →
Джо © (2006-10-06 09:24) [17]

> киньте ссылку плиз (на оффсайте почему то нету).

Да есть. Ищи psqlodbc*

← →
Tab (2006-10-06 09:26) [18]

2 ShaggyDoc
спасибо за информацию

> Кстати, в MySQL карты строятся раз в 10 быстрее, чем из
> Firebird.

почему же так ?

> И есть подход, когда в таблице каждому объекту соответствует
> запись, а координаты хранятся в MEMO или BLOB. Вот здесь
> и начинаются фирменные секреты - формат хранения. Мне приходилось
> делать несколько, сейчас остановились на формате, совместимом
> с AlovMap. Он же используется еще в нескольких ГИС.Для раскрытия "секрета" пришлось поковыряться в исходниках

где же можно поковырятся в исходниках :)?

← →
pasha_golub © (2006-10-06 09:30) [19]

> Джо © (06.10.06 09:08) [10]
>
> > [9] Tab (06.10.06 09:04)
> > Кстати PostgreSQL, только в виде сервера идет?
>
> Кому бы, интересно, нужен был только "сервер" без клиента?
> :) Клиентская библиотека, libpq.dll, занимает примерно
> 200 Кб.

libpq.dll - 174kb v8.1.4

Однако стоит заметить, что для работы этой ДЛЛ нужны еще 6 библиотек. Некоторые имеются в Виндоус ХР, а некоторых нету.

Конкретней:
19.06.2006 09:30 24 576 comerr32.dll 19.06.2006 09:30 524 288 krb5_32.dll 19.06.2006 09:30 1 064 960 libeay32.dll 19.06.2006 09:30 916 849 libiconv-2.dll 19.06.2006 09:30 51 016 libintl-2.dll 19.06.2006 09:30 178 778 libpq.dll 19.06.2006 09:30 200 704 ssleay32.dll

← →
Tab (2006-10-06 09:37) [20]

с хранением вроде как наметки есть, а как быть с проверкой на вхождение, главным образом для плавных-составных линий?

> если требуется найти объект по признакам придеться весь
> файл просмотреть.

А базы данных хранят таблицы не в файлах?

← →
Tab (2006-10-06 09:51) [22]

> А базы данных хранят таблицы не в файлах?

имелось в виду что задача поиска ложиться на плечи БД.

> метафайлы это хорошо, но только получается я потом не буду
> иметь контроля над отображением (или скрытием ) определенных
> элементов.

Метафайл имеет поля для коментариев, и их можно перечислять и фильтровать записи.

← →
ShaggyDoc (2006-10-06 12:03) [24]

> Tab (06.10.06 09:26) [18]
> 2 ShaggyDoc
> спасибо за информацию
>
> > Кстати, в MySQL карты строятся раз в 10 быстрее, чем из
>
> > Firebird.
>

почему же так ?

Да уж не знаю. Установили экспериментально. Один и тот же сервер, данные. Возможно, у Firebird больше "накладные расходы". Он тоже быстро делает, но карты публикуются в Интернет, надо бы побыстрее. Да, и запросы идут через Java, может быть здесь затор.

> > с AlovMap. Он же используется еще в нескольких ГИС.Для
> раскрытия "секрета" пришлось поковыряться в исходниках
>
> где же можно поковырятся в исходниках :)?

В Сиднейском университете. Они там.

Если не добиваться совместимости с чем-то, то можно использовать и собственный формат. У меня давным-давно такие БД обрабатывались на Clipper, там для простоты использовалась клипперовская запись массива прямо в виде текста в MEMO.

Наподобие {{x,y}{x,y}}

Clipper своими внутренними средствами автоматически "вычислял" такую текстовую строку в массив. Были и варианты для LISP, с круглыми скобками. Потом пошли на совместимость - сделали двоичный. Заодно и секретность соблюдаем. Не каждый вытащит данные. А можно и любыми стандартными средствами Delphi записать в BLOB. Если не "совмещаться" с кем-то.

← →
Tab (2006-10-06 14:37) [25]

а как потом прочитать этот BLOB и раскидать по массиву?

> Да действительно, уточню.
> Интересует хранение данных , ну допустим в базе.
> С линией и окружностьью все понятно, две точки, или точка
> и радиус. А как буть с многоугольником? Число точек ведь
> разное. Как хранить такие данные и в какую структуру их
> читать?

> Tab (06.10.06 08:00)
> Собственно сабж. Если кто-нибудь этим занимался или есть
> идеи, поделитесь.

1. Вариант. Серилизация/десериализация объекта многоугольник в базу(Blob). Пишется в полпинка. Далее при создании объекта просто передаешь ему DBConnection и SQL Query он сам себя считывает кеширует и сохраняет. Хотя медленно, но вопрос масштабируемости отпадает.

2. Вариант. Таблицы с полями
TPoligonData
ID:integer|Name:Varchar|Color:integer|Size:integer|Type:integer|StartX:integer|S tartY:integer
TPoligonLineData
ID:integer|FKPoligonID:integer|NextX:integer|NextY:integer
Тоже в общем-то сериализация и десериализация.

3. Использовать какую-то из Object Database и все изменения и вычисления вести через механизмы доступа к ней. Изврат, но многим нравится.

Может и оффтопик, НО !!!
А если посчитать затраты на разработку "с нуля" и покупку готового движка???

Кстати недавно узнал про интересную разработку Питерских - ZULU ГИС.
Можно купить полномерный пакет, а можно "движок", вокруг которого навертеть что нада...

← →
Tab (2006-10-10 08:18) [28]

поднимаю старую тему, появились еще вопросы.
Как быть с масштабированием изображения?
Просто пересчет координат всех объектов в области с учетом масштаба?

> А можно и любыми стандартными средствами Delphi записать
> в BLOB.

это какими например?

Можно еще описать пользовательские типы данных для 2005 сиквела, создать свои методы в типе для определения расстояния, взаимопересечения и т.д.
Все прекрасно сериализуется, ищется.

Структура организации данных векторной карты Найти похожие ветки