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

[juffin_h]

"Панорама" как раз и отталкивается от "объектной модели".
Думаю "панорамщики" не раз задавались вопросом об оптимальном количестве и составе слоев. Считаю классификаторы "Панорамы" хорошая отправная точка для решения этих вопросов.

[lovangeron]

2trir

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

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

[gamm]

Не соглашусь. Сущности уже сформированы в ГОСТе. Городить огород незачем.

сущности у вас сформированы топографической карты им.Генштаба СССР, работать с ними нельзя (если вы не военный).

Это экспериментальный факт. Поэтому все, кто работает, переводят (матерясь и стеная) такое "панорамное" месево им.Генштаба СССР во что-то пристойное и соответствующее задачам. Если же задачи работать не стоит, и парсить блобы вы не можете, то и думать не нужно - каждому типу свой слой, все равно атрибутивные таблицы разные. Ничего страшного, я видел кадастровую систему на Акаде, в которой каждый объект (из тысяч) сидел в своем слое. И ничего, работала

[gamm]

"Панорама" как раз и отталкивается от "объектной модели".
Думаю "панорамщики" не раз задавались вопросом об оптимальном количестве и составе слоев. Считаю классификаторы "Панорамы" хорошая отправная точка для решения этих вопросов.

панорамщики моделировали топографическую карту, представить там ландшафтную или геологическую карту невозможно (как и многое другое). Все остальное пытаются притянуть за уши с помощью "ситуационных слоев".

[lovangeron]

2gamm

сущности у вас сформированы топографической карты им.Генштаба СССР, работать с ними нельзя (если вы не военный).

Это экспериментальный факт. Поэтому все, кто работает, переводят (матерясь и стеная) такое "панорамное" месево им.Генштаба СССР во что-то пристойное и соответствующее задачам. Если же задачи работать не стоит, и парсить блобы вы не можете, то и думать не нужно - каждому типу свой слой, все равно атрибутивные таблицы разные. Ничего страшного, я видел кадастровую систему на Акаде, в которой каждый объект (из тысяч) сидел в своем слое. И ничего, работала

Не горячитесь. Зачем же все в кучу-то сваливать. Скромно напоминаю, что, собственно вопрос и касается структуры базы данных для хранения топографической основы М 1:500. Также не вижу никакой натужной необходимости кидаться в разные крайности. Можно прекрасно обойтись и без парсинга блоб-полей, и, в то же время, не плодить кучу слоев. Все прекрасно моделируется и визуализируется в рамках вполне себе приемлемого набора слоев. Вопросы касаются сугубо эпизодических ситуаций, по которым я надеялся получить советы опытных людей, решавших похожие проблемы. Что же касается категорических мнений о непригодности для «серьезной» работы топографических материалов, выполненных согласно требованиям ГОСТ и соответствующих инструкций, то, исходя из личного опыта, скажу Вам, что первое место, куда бегут все, желающие набросить на территорию города свою гениальную аналитическую ГИС-модель – это местное управления архитектуры. Очень расстраиваются, если там не оказывается топоосновы на территорию города в электронном виде, а если она и есть, еще больше расстраиваются из-за того, что она слабана черте как и без соблюдения соответствующих требований и нормативов.

[trir]

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

[gamm]

Скромно напоминаю, что, собственно вопрос и касается структуры базы данных для хранения топографической основы М 1:500.

то, что вы пытаетесь обсуждать (мели, и т.д.) никакого отношения к хранению топоосновы не имеет. Если вам нужна картинка (а ничего другого вы не обсуждаете), так и храните, как в Панораме или на картофабриках в Неве, состав слоев давно расписан.

[Донецков]

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

[lovangeron]

2trir

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

Да, наверное, можно и так. Но сегодня и завтра – это как? Между «сегодня» и «завтра» какой временной период? Предположим, выполняются замеры на некотором участке территории величины химического загрязнения. В итоге получается некое облако точек. На его основе с привлечением соответствующего математического аппарата строится функция непрерывного распределения, позволяющая определить величину загрязнения в произвольной точке целевой территории. Зачастую как таковое непрерывное распределение не нужно, а интерес представляют лишь участки территории, на которых идет превышение некоторого граничного порога загрязнения. В итоге на выходе вся расчетная цепочка выдает некоторое множество зон, локализующих те самые участки. Далее эти производные данные уже участвуют в каких-то последующих аналитических расчетах. Если вся эта система предполагает динамический мониторинг целевой территории в режиме реального времени, то расчет зон превышения пороговых значений «по запросу» оправдан. Ну а если замеры выполняются раз в сутки. А потребителями данных являются несколько сотен клиентских мест в клиент-серверной среде. В такой ситуации динамический обсчет модели «по запросу» становится накладным. С учетом того, что между замерами на вход модели поступают статичные данные, трата вычислительных ресурсов на холостой обсчет просто не оправдана. В таких ситуациях обычно прибегают к кэшированию промежуточных результатов и оформлению их, как самостоятельного информационного элемента в базе данных. Чем в этом отношении мели хуже? Это ровно такой же объект ориентирного значения, являющийся в заданной предметной среде фокусом внимания, также как в системе по анализу загрязнения зона превышения допустимой нормы является лишь виртуальным фокусом внимания в контексте специфической задачи.

2gamm
Допускаю, что неверно использую термин «топографическая основа». Если Вам несложно, просветите, пожалуйста, меня на предмет его правильного определения. Вполне возможно, мы просто говорим о разных вещах.

[juffin_h]

панорамщики моделировали топографическую карту,...

Какая разница какую карту они моделировали? Смоделируйте другую. Важен подход. Вы ошибочно противопоставили "Панораму" и "объектную модель".

[Franklin1967]

bingeomap,

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

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

от Autocad Map уже начинают отказываться а Вы только начинаете её поиск с целью изучения.
Если Вы имеете ввиду инсталляцию отображённую на картинках в этой теме viewtopic.php?f=38&t=7326
Могу дать Вам инсталляцию Autocad Map 2007 + Raster Design 2007 под него. Если заинтересует, то учитывая коллосальный объём для Интернета выберите каким образом вам залить инсталляцию