Организация структуры БД для хранения топоосновы М 1:500

[lovangeron]

Здравствуйте!
Для нужд муниципалитета возникла необходимость разработать базу данных для хранения топографической информации общего назначения. Проще говоря, топографической подосновы, объектовый состав которой соответствует топографическому плану М 1:500. Для реализации подобной затеи для начала был разработан классификатор топографической информации. Далее на его основе принялись разрабатывать правила цифрового описания топографической информации, в результате чего предполагается получить, в частности, перечень слоев базы данных. При этом для каждого слоя будет определен набор атрибутов, список видов объектов, которые будут заносится в данный слой, маска заполнения атрибутов (для каких видов объектов какие атрибуты нужно заполнять в пределах данного слоя) и тип локализации объектов слоя (полигоны, линии, точки, текст).
По ходу разработки возник ряд вопросов. Возможно, кто-то, имеющим опыт разработки подобных или похожих баз данных, сможет дать по ним совет:
1. Есть такое семейство объектов: опоры, столбы, опорные фермы и т.п. Корректно ли сгруппировать все объекты подобного типа в какой-то один слой (или группу слоев) так называемого общего назначения, или правильней будет, если каждая тематическая группа слоев будет иметь в своем составе свои опоры (например, в слое «Сооружений на ЛЭП» хранятся опоры ЛЭП, а в слое «Части зданий и сооружений» хранятся опоры балконов и навесов, и т.п.)?
2. Есть ряд объектов комбинированного типа: фонари на столбах, часы на столбах и т.п. Следует ли в таких случаях отдельно выделить объект опоры и отдельно объект, который может быть размещен на опоре, либо формировать неразъемные объекты: фонарь на деревянном столбе, фонарь на бетонном столбе и т.д.?
3. Можно ли интерпретировать некоторые объекты гидрографии, как объекты рельефа дна водоемов и, соответственно, группировать их в один слой (или группу слоев) с объектами рельефа? Например, такие объекты, как обрывистый берег, мель, камень в воде и т.п.. Либо выделить эти объекты в самостоятельный слои (группу слоев)? Либо группировать их с водоемами и водотоками, как специализированные части водного объекта?

[trir]

1. Не смешивайте коммуникации и «Части зданий и сооружений», коммуникации это всё таки линейный объект и точечные объекты должны принадлежать соответствующему линейному объекту. Ну а здания - полигон. При анализе коммуникаций, «Части зданий и сооружений» будут восприниматься как мусор, а анализ коммуникаций требуется чаше.
2. Лучше сделать подчинённый объект (таблицу) без геометрии, но с привязкой к соответствующему объекту
3. Надо смотреть конкретней

P.S. Лучше выложите примеры, структуру БД...

[Александр Мурый]

Может быть, вам в чём-то помогут классификаторы КБ "Панорама"?

[Донецков]

Все таки многое зависит от используемого ПО.
когда-то встречал набор стилей для ArcGIS для 1:500 - 1:5000.
Что-то подобное разрабатывают под AutoCAD Map ...

[bingeomap]

Что-то подобное разрабатывают под AutoCAD Map ...

Донецков, вы не знаете кто или какая компания разрабатывает под AutoCADMap, откуда слышали? Я долгое время искал но не нашёл...

[lovangeron]

2 trir
По первому вопросу предполагается вот такая примерная структура:

Спойлер

Группа слоев «Части зданий, строений, сооружений»:

Слой «Части зданий, строений, сооружений (полигоны)»
…
- столб фермовой
- ферма
…

Слой «Части зданий, строений сооружений (линии)»
…
- ферма (линейный вариант)
- опорная оттяжка
…

Слой «Части зданий, строений, сооружений (точки)»
…
- столб, опора
…

Группа слоев «Сооружения на ЛЭП и линиях ТСУ»:

Слой «Сооружения на ЛЭП и линиях ТСУ (полигоны)»
…
- трансформатор
- башня радиопередающая
…

Слой «Сооружения на ЛЭП и линиях ТСУ (точки)»
…
- мачта радиопередающая
- фонарь
- фонарь двойной
…

Группа слоев «Коммуникации»:

Слой «Линии электросвязи»
…
- ЛЭП высокого напряжения
- ЛЭП низкого напряжения
…

Слой «Линии ТСУ»
…
- линия ТСУ кабельная
- линия ТСУ проводная
…

Такая модель предполагает, что все опорные сооружения сосредоточены в одном месте, а не размазаны по другим тематическим группам. Недостаток: сложно выделить опоры, относящиеся именно к инфраструктуре ЛЭП.

2 Александр Мурый.

Спасибо. Знакомился, когда только приступал к обдумыванию концепции. С этим и рядом других. Учли некоторые моменты, но в основном опираемся на ГОСТ Р 52439-2005 «Каталог объектов местности». В приведенном Вами классификаторе, как я понимаю, идет смешение в пределах одного слоя объектов с разным типом локализации, что, по ряду причин, нас не устраивает.

[trir]

Структуру БД лучше на SQL'е

Посмотрите ещё CityGML
http://www.citygml.org/
http://www.opengeospatial.org/standards/citygml

[Донецков]

Под Autocad Map читал на форумах, но в "руках не держал"...

[bingeomap]

Под Autocad Map читал на форумах, но в "руках не держал"...

Вы помните в каком форуме прочитали? Можете ссылку дать? Может так могу доехать до создателя?!

[Донецков]

Поищите поиском "Отраслевая модель данных" в Autodwsk Map 3D/Civil...
а видел у CSoft на курсах....

[lovangeron]

2trir
На данный момент пока не стоит вопрос о проектировании физической структуры базы данных. Хотя в итоге БД будет развернута на базе СУБД Oracle. Речь идет о логической структуре или, скорее, о корректной организации набора слоев пространственных данных. Иными словами, у меня на входе есть массив типов пространственных объектов, атрибутика которых определена соответствующим ГОСТом (выше я его упоминал). Необходимо распределить (сгруппировать) эти типы (или виды) объектов по как можно наименьшему числу слоев. С точки зрения формальной задачи нормализации объектов БД следует для каждого типа (вида) объектов сформировать свою собственную таблицу (слой) с характерным набором полей. Но с практической точки зрения такое решение неприемлемо, так как необходимо получить достаточно компактный набор слоев, чтобы с ним было удобно работать. Я не рассматриваю варианты нормализации объектов БД при помощи разбиения «плоских» таблиц (слоев) на несколько иерархически связанных таблиц по ряду причин, в которые я не буду вдаваться.

[gamm]

Необходимо распределить (сгруппировать) эти типы (или виды) объектов по как можно наименьшему числу слоев.

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

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

не совсем так - с формальной точки нужно сначала формализовать предметную область, и выделить в ней объекты, с которыми вы будете работать. Если же идти от ГОСТа, то получите ровно Панораму, в которой моделируется не предметная область, а топографическая карта (как картинка).

[Andrey Zhukov]

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

ЕСАУЛ уже запатентован!

[lovangeron]

2gamm

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

Такой вариант не подходит. Мало какое клиентское ПО ГИС способно «в лоб» парсить сложносочиненные поля и извлекать из них, например, информацию для автоматического подписывания или тематического ранжирования. Такое решение неизбежно сужает круг клиентского ПО, которое буде способно адекватно интерпретировать такую БД. Если же делать так называемые «представления», то мы возвращаемся на исходную, только теперь будет стоять задача проектирования набора представлений.

не совсем так - с формальной точки нужно сначала формализовать предметную область, и выделить в ней объекты, с которыми вы будете работать. Если же идти от ГОСТа, то получите ровно Панораму, в которой моделируется не предметная область, а топографическая карта (как картинка).

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

[trir]

Если делать по ГОСТ'у - получится "Панорама", без вариантов. Потому, что все ГОСТ'ы "про карту"
А если делать "для работы" - надо отталкиваться от "объектной модели"
"Вам шашечки или ехать?"