Обсуждение формата SXF в качестве стандарта геоданных

[Дмитрий Барышников]

Посмотрим на эту проблему в другом разрезе, о котором товарищ или забыл указать или от неопытности не знал о ней.
Имеется некая геопространственная база данных которая содержит таблицу объектов. Таблица содержит десяток полей которые несут семантическую информацию. Допустим земельный участок:
ИД, площадь, периметр, тип участка, материал покрытия, тип насаждений, характер грунта, тип владения и.т.п (думаю для наглядности хватит)
В БД вносятся участки разного типа, например 2 участка "асфальтное покрыте города - тротуар", 2 участка "частное владения", 2 участка "огороды".
Вопрос. Нужны ли для записей "асфальтное покрыте города - тротуар" такие характеристики как тип насаждений, характер грунта или для сады такие как материал покрытия, тип владения ?
Не знаю как это называется на языке геодезистов или картографов, на языке администраторов и программистов это называется избыточность данных, занимающая в БД лишние кластера которые никогда не будут заполненными.

Не знаю, ко мне обращались или нет. Но попробую ответить.
При такой постановке вопроса модель данных ESRI или PostGIS рулят. Они позволяют создавать связанные и даже "унаследованные" таблицы.
Т.е. создав таблицу всего с двумя полями, например, ID и геометрия, остальную атрибутику можно взять из других источников данных. Нет необходимости менять классификатор. Просто добавляется таблица с новым составом полей или даже специальные программные объекты, со своим поведением - пример трубопровод и задвижка.
Программное обеспечение с этим нормально работает. Пользователь получает большую гибкость.
Кому-то проще по покрытию асфальта классифицировать, а кому-то - по ширине, а еще кто-то вообще хочет отображать и работать только те тротуары под которыми кабели проложены (причем информация о кабелях получается из другого источника).
Суть "западных" ГИС: данные отдельно, представление данных - по усмотрению и требованиям пользователя.

Работал с триалкой с сайта КБ Панорама - Панорама Версия 10.5.2. Не нашел, как посмотреть таблицу атрибутов векторного слоя.
Возможно вы (Подкидыш) подскажите, как это можно сделать - не нашел в документации и обычным тыканьем тоже.

[Подкидыш]

Bishop, вижу Вы образованный и опытный человек и главное адекватный в отличии от некоторых ... (лан не буду)
Реляционная БД с распределёнными функциями это отлично, и я с Вами полностью согласен. Вернёмся теперь в теме обменный формат.
Пользователь Вася, решил что он самый умный и создал по своему вкусу свою БД со своими названиями полей.
Пользователь Маруся, решила эти же данные передать уже по другому потому что имя ObjectName она не понимает и назвала её NazvanieObjecta + сделала её не той размерностью что Вася.
Начинаем обмениватся данными.
С точку контроля А, приходит информация от тысячи таких Вась и Марусь причём каждый из них считает что он самый умный, и что его модель данных самая правильная. Что делать админу в точке контроля?
Сидеть и догадыватся что пользователь ХХХХ хотел сказать назвав поле таблицы PlObVn ?
А если приходит таблица в которой десяток полей формата float и в каждой сродные по порядку значения, что есть что. Куда админу сливать те или иные данные ?
Вот скажите, учитывая эти факты, свободная реляционная БД в любом её проявлении может быть обменным форматом между сотнями разношёрстных производителей геоинформационных систем?

добавлено
Для наглядности, вот Вам структура мною придуманых данных, а Вы принимающая сторона. Ловите и думайте что у меня творится в голове:

[Дмитрий Барышников]

Спасибо за скриншоты. Наверное это и есть ответ на мой вопрос по Панораме. Хотя я так и не понял путь открытия табличного вида. А в этом виде можно сортировать данные, подсвечивать выбранные на карте данные, изменять атрибутивные данные?

По поводу обмена данными - все просто - принимающая система устанавливает правило валидации поступающей информации. Не проблема приемщика следить за корректностью данных, а передающего. Это везде сделано таким образом, не только в ГИС - веб сервер на кривой запрос вернет ошибку, на кривой xml парсер наругается.
Если же идет намек на документированность (самодокументированность) самого документа - типа XSD. То я противник такого. Лишняя информация. Это как раз на принимающей стороне должны быть опубликованы правила "приема".
В принципе, опять возвращаемся к тому что OGS GML наиболее предпочтительный вариант.
Единственное уж больно теги у них в нем огромные и слишком часто Entry Content используется вместо атрибутов, что приводит к неоправданному увеличению объема.
Эх, нет на свете ничего идеального.

Я считаю что темя себя изжила и можно закрывать. Т.к. основной спор от формата перешел к выбору конкретного ПО. А это слишком субъективно, да и от задачи зависит. Через месяц ровно год будет обсуждению!

[gimran]

Обычно в таких случаях, Подкидыш, делается описание БД.
А Вас я наконец-то понял: Вам нравится Панорама и SXF тем, что поля стандартизированы по размеру и названию для всего множества полей и таблиц?

[gamm]

gamm, у меня нет времени и желания готовить Вам MTQ-модель результатов ДЗЗ в Панораме и передавать из в sxf формате.

а причем здесь матрицы и ДЗЗ, если речь шла о диаграмме Вороного?

Упростим задачу - просто скажите, можно ли в SXF передать ландшафтную карту без потери топологии, которая нужна для подсчета ландшафтных индексов, и перечислите используемые элементы формата SXF. И приведите, пожалуйста, ссылку на официальное описание формата SXF, в котором эти элементы описаны. Готовить ничего не нужно, ответ потребует от Вас не более 5 минут. Спасибо.

P.S. На всякий случай, ландшафтная карта имеет иерархическую структуру, на каждом пространственном масштабном уровне это планарное разбиение (обычно используется цепочно-узловая структура), кроме того ландшафтные единицы более высокого ранга состоят из объектов более низкого ранга (объектная модель, связи между объектами).

P.P.S. Указанная выше топологическая структура не имеет отношения к ESRI, так ландшафт устроен, в том числе и в РФ.

P.P.P.S. Цытатка из Ю.В.Андрианова ссылка:
вспомним наш отраслевой стандарт 68-3.5-99 "Карты цифровые топографические. Обменный формат. Общие требования", который, как я понимаю, лежит в основе SXF, и который, вроде, еще никто не отменял. Именно этот стандарт говорит, что обменный формат должен утверждаться приказом руководителя службы после его пробной эксплуатации и устранения выявленных недостатков. Достаточно интересный документ, в чем-то прогрессивный для своего времени, но требования которого так до конца и не выполнены при разработке SXF. Вот хотя бы эти два:
"8.7 Логическая структура обменного формата ЦТК должна обеспечивать представление метрики объектов в объектно-ориентированной и цепочно-узловой формах.
8.8 Логическая структура обменного формата ЦТК должна обеспечивать представление пространственно-логических связей между объектами."

Подозреваю, что именно по этой причине данный ОСТ не стал ГОСТом, в отличие от четырех его собратьев из серии о ЦТК. Ведь тогда SXF был бы признан не соответствующим гос. стандарту, и его нельзя было бы применять для обмена и хранения цифровых топокарт.

[nadiopt]

2 Подкидыш: вы сильно преувеличиваете мой опыт, тут на форуме есть гораздо более квалифицированные специалисты, а большое количество моих постов, в основном, относятся к решению той или иной прикладной проблемы, а то и вовсе к игре "Ассоциации". Кстати, многих весьма уважаемых мною людей вы почему-то нещадно ругаете...
предлагаю результаты конвертации выложить открыто, чтобы мнение было не только мое, но и всей общественности.

[Подкидыш]

Bishop »

Наверное это и есть ответ на мой вопрос по Панораме.

Нет уважаемый Bishop, в Панораме всё чётко классфицировано и стандаризировано, эти скрины с совершенно других источников. В Панораме, к примеру,если есть асфальтное покрытие, то у него не будет никогда характеристики "толщина деревьев". Впрочем её можно без проблем задать, если делать нечего.

Я считаю что темя себя изжила и можно закрывать.

Я так тоже считаю. Но есть некоторые личности, которые никак не могут успокоится когда увидели что с них капает. Мне извесен такой контингент людей, они мне напоминают шавок которая тявкает при присуствии большой собаки, а как большая собака уходит мочатся под себя, и чтобы как то выправдать своё существование в этом мире пытаются кусатся.
gimran »

Обычно в таких случаях, Подкидыш, делается описание БД.

А что есть "описание БД" , или так называемая спецификация ? Что есть согласование структур БД между принимающей и отправляющей стороной? Это случаем не та же классификация?
nadiopt »

2 Подкидыш: вы сильно преувеличиваете мой опыт

Уважаемая nadiopt, по поводу приувеличение и приуменшение опыта, Максим Дубинин меня предупредил постом Выше. Опытов работы и уровень IQ, обсуждать на форуме не моя превилегия, это запрещено правилами.

предлагаю результаты конвертации выложить открыто

Входящие данные Ваши. Их роль и значимость определяете лично Вы. У меня нит никакого морального права выкладывать чужую информацию на всенародное обсуждение.
.
П.С. Вроде ответил всем конструктивно мыслящим специалистам.

[nadiopt]

ОК тогда я выложу, никакой особой секретности тут нет.
http://delphi-gis.ucoz.ua/smiles/GIS_LAB.ZIP
я давала исходники в мифах и табах, конвертированные из лесоустроительной ГИС
в любом случае в наших интересах не ругаться, а разобраться что за зверь sxf и с чем его едят

[gimran]

А что есть "описание БД" , или так называемая спецификация ?

Именно это и подразумевал.

Что есть согласование структур БД между принимающей и отправляющей стороной? Это случаем не та же классификация?

Не совсем. Это согласование спецификаций баз данных между принимающей и отправляющей стороной.
Скажем, у Вас слой зданий имеет поля: номер дома — NAME с таким-то типом данных и размерностью, название улицы — STREET_NAME с таким-то типом данных и размерностью, а район города — RAION с таким-то типом данных и размерностью.
А у меня: NOMER_DOMA с таким-то типом данных и размерностью, название улицы — ULICA с таким-то типом данных и размерностью, а район города — RAJON с таким-то типом данных и размерностью.

Для того, чтобы «не угадывать», что есть что, спецификацию согласовывают.

Разумеется, единая спецификация на всю РФ для ГИС была бы полезна, причем, думаю, полезнее «обменного формата», если только в нём её не заложить.

[gamm]

to Подкидыш

так что там насчет ландшафтной карты? Если ее представить в SXF нельзя, то так и скажите.

[Подкидыш]

в любом случае в наших интересах не ругаться

а тут никто не ругается. Есть конструктивные участники и Вы в их числе, есть товарищи которым нечего сказать и они бешенно ищут в старых книгах с математического анализа, умные фразы, чтобы на форуме хоть как то показать свою значимость.

Разумеется, единая спецификация на всю РФ для ГИС была бы полезна, причем, думаю, полезнее «обменного формата», если только в нём её не заложить.

gimran как говорится на Укарине "говорылы балакалы, силы и заплакалы". А я Вам о чём изначально говорю ?
Классификация уже лет так 15-20 назад разработана. Нормальные и здравомыслящие люди уже давно разобрались чем характеризуется объект в реальном мире, и сделали классификаторы.
Обменный формат без классификации это шаг в назад
Вот представим гипоттетически такую ситуацию:
В качестве обменного формата приняли SHP. SXF и классфикаторы, как пережиток СССР (из цитаты одного из участников конференции ГИС-Ассоциации) перемножены на 0.
Все бурно начинают обмениватся данными и замечают что пошла коса на камень. У одного такой формат представления тех же данных по лесоустройству у другого второй у третего третий.
Люди садятся за круглый стол, что-бы начать изобретать велосипед, который рони успешно умножили на 0 (см. выше) то есть общую спецификацию струкутуры передаваемой информации в отраслях.
Структура БД, то есть её спецификация, подразумевает структуру отдельных элементов геопространственных данных. То есть к примеру дерево, будет иметь: породу, толщину ствола, возраст, высоту и.т.п характеристики.
И что мы получили на выходе ?
Создание тех же классификаторов но для ESRI.
Господа, я поддерживаю участников форума, и прошу Максима Дубинина поставить на эту тему признак закрыто.
Всем и так всё понятно. Лично мой вывод:
1. Обменный формат должен удовлетворять все ГИС ПО. Если разработчик ГИС ПО считает себя "умнее других" и по субьективным причинам (захват рынка, получение максимум прибыли, стремление к монополии) это я о ESRI не хочет писать конвертор то такого разработчика нужно перемножать на 0, по карйней мере на рынке ГИС в России.
2. Данные должны быть классифицированы, чтобы к примеру я не раздуплялся что означает поле
Mu Float или Mu1 Float см. примеры предоставленные nadiopt
3. Разработка конверторов под разлиные ГИС - головная боль разработчика этой ГИС. Правила рынка суровы, не хочеш по них играть - вон с рынка.
Почему то MapInfo не посчитала что с них упадёт корона и разработала конвертор SXF формата, да потому что хочет выжить на Российском рынке, и выживет, и ещё начнёт развивтася. И нет никаокой гарантии что лет через 5-10 может даже серьёзно конкурировать с Панорамой в Росии. А с таким "барским" подходом как у ESRI, её будущее предначертано - назад на дикий запад.

[nadiopt]

мне кажется, можно
я только не могу взять в толк - потеря всей атрибутики, которая была зашита в миф - это баг или фича?

[gimran]

Я в украинской мове не силён, но. кажется, надобно так написать (в соответствии с украинским): "говорили балакали, сіли и заплакали" (хотя да, Вы верно передали произношение).

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

[gimran]

дубль

[Газонокосильщик]

Подкидыш совершенно справедливо упомянул про классификацию. Вот все претензии - именно к ней, Системе классификации и кодирования. А формат хранения - дело десятое.
Как практик скажу - довелось мне работать с DMF-форматом (ЦФС ака Digitals) - проклял всё на свете. Большего бреда я не видел.