[АлексЮстасу]

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

Допустим, решили для х-к использовать Xdata.
Xdata определяются названием (application name) и входящими в них данными с типами Int, Long, Real, Str и пр.

Я вижу два варианта таких описаний:

Вариант 1. Все х-ки в одном Xdata. Допустим, придаем линии (3Dполилинии, телу - не важно) Xdata с названием "Трубы", в котором определяем одно поле Str для индекса, второе Real для диаметра, третье Real для длины, четвертое Str для материала и пятое Str для производителя. Вроде: "1-Т/22-94", "25.4", "72.6", "ППЭ", "Полипласт".

Вариант 2. Каждая х-ка в своем Xdata. Например: "Трубы_индекс", "Трубы_диаметр_мм", "Трубы_длина_м", "Трубы_материал", "Трубы_производитель".

Кто как чаще делает? Как-то принято? Есть какие-то конвенции? И подводные камни у этих вариантов?

[Кулик Алексей aka kpblc]

АлексЮстасу, с определением троллинга - к Админу. С моей точки зрения на вопрос ответы и варианты решения были даны, и просто постоянно к ним возвращаемся в том или ином варианте. Считаешь, что тут троллинг - вперед, "Обратить внимание модератора". Лично я вряд ли буду реагировать, поскольку не уверен в собственной беспристрастности.

[Сергей812]

Сообщение от АлексЮстасу Когда я ее начинал, то Вариант 2 был умозрительным.

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

[АлексЮстасу]

Прямо сейчас попался такой вариант от индийских кабельщиков, оба Xdata у одного кабеля:

* Registered Application Name: CYIENT_ID * Code 1000, ASCII string: 14070027450225690C789F * Registered Application Name: SplitInfo * Code 1000, ASCII string: SplitID=Merged * Code 1000, ASCII string: Status=Open * Code 1000, ASCII string: OBJECTID=(140700274502256)

Можно предположить, что CYIENT_ID для идентификатора кабеля.
А SplitInfo, возможно, для описания состояния кабеля, разрывов в нем. SplitInfo есть только у одного кабеля.
Названия полей пишутся до знака "=", значения - после.
Первое Xdata - как Вариант 2. Второе - похоже на Вариант 7 из #72. Отличается тем, что тип данных не записан.

[Сергей812]

Сообщение от АлексЮстасу Названия полей пишутся до знака "=", значения - после.

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

[Александр Ривилис]

Сообщение от АлексЮстасу Прямо сейчас попался такой вариант от индийских кабельщиков, оба Xdata у одного кабеля:

Боюсь, что "индийские кабельщики" не в курсе, что ObjectId сохранет значение только в пределах одной сессии AutoCAD. Поэтому строка вида: OBJECTID=(140700274502256) бессмысленна и даже опасна.
Когда-то (лет 25 назад) я хранил данные в виде строки, которая раскрывалась в ассоциативный список. Если длины в 255 символов было недостаточно, то список содержался в нескольких последовательных полях с кодом 1000. С этим списком достаточно удобно было работать из lisp'а и возможно было работать из ObjectARX.
Так что это еще один возможный вариант.
АлексЮстасу,
Я не занимался троллингом, а лишь высказал своё мнение.

[АлексЮстасу]

На днях попался забавный вопрос: человек сделал в AutoCAD модель автомобиля из 3D отдельных деталей, и теперь для каждой из них хочет определить характеристики. У двигателя - свои, у рессор другие и т.д.
А вопрос обращен к специалистам Map 3D! Т.е., вероятно, его уже кто-то обломал с возможностями базового AutoCAD (включая, похоже, и с Xdata), но этот кто-то слышал, что задача определения описательных данных давно решена в Map 3D.

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

В этой теме возникали некоторые общие вопросы, на которые отвлекаться было не к месту. Я написал свои соображения о них здесь - https://dwg.ru/blog/300.

Offtop: Александр Ривилис, я написал не "занимался", а "поучаствовал". Ехидство без оснований посреди троллинга и одобрение троллящего очень похоже на участие.

[Сергей812]

Offtop: Троллинг - это когда человек носится с одной идей фикс много лет подряд, пишет кучу статей и создает прочую шумиху вместо решения самой проблемы) Я предложил рабочий вариант в посте 68, что вы даже не смогли за неделю найти любую статью для начинающих по NetApi и хотя бы попытаться собрать приведенный готовый код. Прямо так чувствуется практическое желание работать над проблемой описательных данных в акаде)

[АлексЮстасу]

Сообщение от Сергей812 и получаем дополнительный парсинг: поиск позиции начала значения, преобразование значения к соответствующему виду.

Наверное, получаем. Но без этого мы можем вообще ничего не получить - набор непонятно для чего предназначенных полей.

Сообщение от Александр Ривилис Когда-то (лет 25 назад) я хранил данные в виде строки, которая раскрывалась в ассоциативный список. Если длины в 255 символов было недостаточно, то список содержался в нескольких последовательных полях с кодом 1000. С этим списком достаточно удобно было работать из lisp'а и возможно было работать из ObjectARX. Так что это еще один возможный вариант.

Это способ хранения длинных строковых значений. Но не помогает понимать какое поле для чего предназначено.

[Сергей812]

Сообщение от АлексЮстасу Наверное, получаем. Но без этого мы можем вообще ничего не получить - набор непонятно для чего предназначенных полей.

так любое решение - что в XData, что во внешней БД или иным способом - это всего лишь условно принятый способ хранения нужных характеристик. Например, применительно к тому же оборудованию - ток вместе с напряжением определяет мощность потребления (на постоянном токе). А с параметрами кабеля - погонным сопротивлением и длиной - падение напряжение (будет ли вообще подключенное оборудование работать) и правильно ли выбрано сечение кабеля (не будет ли перегрева). И т.д. Но это уже не проблемы dwg - это программная интерпретация входных данных, полученных с чертежа. Само хранение данных в чертеже или в связанном хранилище - лишь верхушка айсберга.

[Александр Ривилис]

Сообщение от АлексЮстасу Это способ хранения длинных строковых значений. Но не помогает понимать какое поле для чего предназначено.

Речь вообще-то шла об ассоциативных списках, представленных в виде строки. Например,

Код:

[Выделить все]

 ("ROOM_NUMBER" 666) ("ROOM_AREA" 12.15) ("ROOM_NAME" "Кухня")

И вот этот список завернут в строку.

[АлексЮстасу]

Сообщение от Сергей812 так любое решение - что в XData, что во внешней БД или иным способом - это всего лишь условно принятый способ хранения нужных характеристик.

Собственно, я и задал исходный вопрос о том, можно ли и как сделать способ хранения в Xdata однозначно или достаточно понятным. При том, что сами Xdata не слишком к этому располагают.
Например, для моих Object Data Map 3D такого вопроса вообще нет - в них все понятно и однозначно.

Сообщение от Сергей812 А с параметрами кабеля - погонным сопротивлением и длиной - падение напряжение (будет ли вообще подключенное оборудование работать) и правильно ли выбрано сечение кабеля (не будет ли перегрева). И т.д. Но это уже не проблемы dwg - это программная интерпретация входных данных, полученных с чертежа.

Естественно, что эти вопросы здесь не рассматриваются. Здесь рассматривается вопрос возможности правильно интерпретировать первичные данные из Xdata.

Сообщение от Сергей812 Само хранение данных в чертеже или в связанном хранилище - лишь верхушка айсберга.

Для проверки тлетворного влияния описательных данных в чертеже я выложил такие тестовые dwg в посте - https://dwg.ru/blog/301.
Правда там не предлагаются Xdata, т.к. я использую либо Object Data Map 3D, либо Xrecord. Но я о принципе - хранение описательных данных в dwg не добавляет проблем и вполне оправдано для относительно небольших моделей и объемов данных.

----- добавлено через ~9 мин. -----

Сообщение от Александр Ривилис Речь вообще-то шла об ассоциативных списках, представленных в виде строки. Например, Код: 1 ("ROOM_NUMBER" 666) ("ROOM_AREA" 12.15) ("ROOM_NAME" "Кухня") И вот этот список завернут в строку.

Просто я не телепат и не программист, чтобы без пояснений и примера сообразить.
Так - действительно, это новый вариант. Вариант 8.
Он сразу сочетает в себе и черты варианта 2 (единственное поле в appname), и варианта 7 (в поле/-я записано название "таблицы", "поля таблицы" и само значение). Но вся запись одной "таблицы" одной строкой.
Ок.

[Сергей812]

Сообщение от АлексЮстасу Здесь рассматривается вопрос возможности правильно интерпретировать первичные данные из Xdata.

да легко. Напишите стандарт, описывающий однозначную интерпретацию всех возможных данных, пролоббируйте - чтобы его приняли в качестве ФЗ - и все, проблема решена. Точнее, это уже станет общей проблемой) А на практике нужно знать - что это число означает, например, ток, а это - погонное сопротивление. И тогда будет понятно, что перемножив эти числа - получишь падение напряжения на кабеле. Естественно, надо учитывать в каких единицах эти значения - чтобы не перемножив мА на Ом, приятно удивиться минусовым значениям напряжения на нагрузке. А вы все абстрактным чем то грезите.

[Boxa]

Сообщение от Кулик Алексей aka kpblc xml?? в dwg?!?! Да лааааадно!

Увы, но очень похоже на это =(

Сообщение от АлексЮстасу На днях попался забавный вопрос: человек сделал в AutoCAD модель автомобиля из 3D отдельных деталей, и теперь для каждой из них хочет определить характеристики. У двигателя - свои, у рессор другие и т.д. А вопрос обращен к специалистам Map 3D! Т.е., вероятно, его уже кто-то обломал с возможностями базового AutoCAD (включая, похоже, и с Xdata), но этот кто-то слышал, что задача определения описательных данных давно решена в Map 3D. Понятно, что у Autodesk может быть другое ПО, лучше подходящее для моделирования автомобилей.

Для этого существуют гиперссылки.

Offtop: Общение слепых с глухими, всегда интересно.

[АлексЮстасу]

Сообщение от Boxa Для этого существуют гиперссылки.

Да, о гиперссылках я все время забываю. Их кто-то практикует?
Чем они лучше тех же Xdata? Записать в Xdata тип, марку, мощность и пр. двигателя, свое про колеса и т.д. Вполне в Xdata все подобное уместится. Будет однозначно связано с графикой. Автоматически передаваться вместе с графикой при передаче dwg. При написании или заимствовании соответствующих несложных программок будет доступно для выбора, изменений и пр. - любых нужных задач.

[Сергей812]

Сообщение от АлексЮстасу Автоматически передаваться вместе с графикой при передаче dwg. При написании или заимствовании соответствующих несложных программок будет доступно для выбора, изменений и пр. - любых нужных задач.

представил себе глаза посредников/смежников/заказчиков при словах - остальные данные у нас в XData, напишете там несложную программку, чтобы посмотреть)

[АлексЮстасу]

Кулик Алексей aka kpblc, с чем сейчас ты согласен, что одобрил?
Сейчас была речь об альтернативе - использовании гиперссылок для описательных данных. Т.е. они лучше Xdata? (В тему: обнаружил, что гиперссылки описываются как раз Xdata ).
И я ошибался, что для Xdata можно найти больше программных наработок, чем для гиперссылок или пр.?
Подскажи тогда, что и где для гиперссылок можно посмотреть, попробовать готового пользовательского для "посредников/смежников/заказчиков"?

Добавил в https://dwg.ru/blog/301 пример dwg с Xdata, аналогичный примерам с Xrecord, Object Data.
Результат вроде бы такой же - достаточно большой объем описательных данных не так уж и раздувает dwg (добавляет примерно 1/30 от их объема), и не заметно снижения скорости работы в AutoCAD.
Возможный вывод: целесообразность хранения описательных данных в dwg ограничена главным образом не свойствами и объемами Xdata, Xrecord или т.п. и пр., а общими возможностями AutoCAD. В первую очередь - объемами графических данных в dwg, с которыми AutoCAD еще может удовлетворительно работать.
Но все это нужно еще получше проверить.

[Сергей812]

Сообщение от АлексЮстасу Сейчас была речь об альтернативе - использовании гиперссылок для описательных данных. Т.е. они лучше Xdata?

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