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

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

Допустим, решили для х-к использовать 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. Например: "Трубы_индекс", "Трубы_диаметр_мм", "Трубы_длина_м", "Трубы_материал", "Трубы_производитель".

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

[ShaggyDoc]

Сообщение от Сергей812 Это же блог ТС ?

Видимо там описывается система, сложившаяся еще в AutoCAD R.10, когда еще никаких средств для хранения информации кроме атрибутов не было. И Autodesk демонстрировала примеры с извлечением данных из атрибутов, с самым простейшим примером - блоки оборудования.

Нам тоже тогда приходилось делать InCAD - "ГИС на базе Автокад". Там блоками создавались объекты (точечные, линейные, площадные), но в скрытых атрибутах были уже ссылки на БД.

Это были времена DOS, БД велись в Clipper. Геометрия объектов хранилась в БД, причем в специальном формате, в котором Clipper читал и записывал массивы чисел, наподобие {{x1,y1}{x2,y2}...{xn,yn}}.

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

Система несколько лет работала, потом перешли уже под Win95 и AutoCAD R14. Вот там уже были более серьезные возможности.

Потом от Автокадов совсем ушли, но все данные, вместе с геометрией, перекочевали в другие ГИС.

Но самое большое извращение я видел, когда информацию, требуемую для извлечения в СО хранили в именах блоков.

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

Сообщение от ShaggyDoc Это та область, где необходимо действовать именно программно...

Вопрос в том, что в Xdata поля определяются только типом и позицией относительно других полей. Из-за этого никакими средствами, ни "кнопками", ни программно понять, что в этом поле Int записан "номер", а в этом "количество" невозможно. Эта информация просто отсутствует. Вообще.
В т.ч. и потому, что названия "application" в Xdata не определяют ничего - любые два одноименных Xdata могут иметь совершенно разную структуру полей.
Поэтому и интересно, как разные люди решают эту проблему - проблему определения что где в Xdata.
Я нашел два варианта решения - 2-й, когда в каждом Xdata только одно поле, а его назначение дается в названии "application", и 3-й, когда поля всегда описываются парами: название, содержание.
Оба, конечно, фиговые. Но кто-то же мог уже найти способы получше.

Сообщение от Сергей812 Это же блог ТС ?

Там в статьях о том, что Xdata и Xrecord лучше, чем атрибуты. В принципе, как подход. И там же про отвратительную реализацию их самих для пользователей.

[Сергей812]

Сообщение от АлексЮстасу Вопрос в том, что в Xdata поля определяются только типом и позицией относительно других полей. Из-за этого никакими средствами, ни "кнопками", ни программно понять, что в этом поле Int записан "номер", а в этом "количество" невозможно. Эта информация просто отсутствует. Вообще.

как отсутствует возможность для обычных пользователей залезать в эти XData, т.е. изначально они ориентированы под программные надстройки (ET тоже надстройка). Ограничение на объем данных - ссылку выше давал уже, хотите хранить все в XData - храните, никто не запрещает. Первый ваш вариант - храните в начале байт или два, определяющий версию данных и считывайте в зависимости от их значения последующие поля. Или первое число рассматривайте как битовое поле, определяющее - какие поля будут пропущены в дальнейшем в XData. Это все для экономии места, структура данных при этом будет "жесткая". И т.д. Но какой смысл это с вами обсуждать, если вы все равно

Сообщение от АлексЮстасу Я не программист,

а доступа без программирования к XData нет.

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

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

Во-первых, не факт, что "изначально они ориентированы под программные надстройки". Общее место, что в AutoCAD нечто есть, но слабо или очень слабо или почти никак не обеспечено пользовательскими инструментами.
Во-вторых, дополнительные/расширенные/описательные данные так же нужны пользователям, как и программистам. Пользователям больше. Иначе бы не изобретали, не пользовались издревле и до сих пор костылем в виде атрибутов.

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

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

[Сергей812]

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

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

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

есть штатное средство создания заготовок отчетов в виде извлечения данных. А с вашими даже идентифицированными по типу хранимой информации "полями" в XData что делать дальше?

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

Сообщение от Сергей812 Вот для атрибутов блоков, о которых вы так пренебрежительно отзываетесь

Не приписывайте мне своего. Я атрибуты всячески люблю. А вот их использование в качестве альтернативы описательным данным - типичный костыль. "Костыль" - это применение чего-либо не по назначению, несмотря на непригодность или относительную непригодность.

Сообщение от Сергей812 А с вашими даже идентифицированными по типу хранимой информации "полями" в XData что делать дальше?

Очевидно же что делать - дать пользователям достаточный набор инструментов работы с XData. (А лучше не с ними из-за их врожденных пороков).

Но, опять-таки, это очередное отклонение от темы - здесь не вопрос об использовании XData, а о том, как обеспечить определенность их содержания.

[Сергей812]

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

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

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

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

Вопрос определенности XData абсолютно одинаков для любого их содержания. Как узнать, что именно "извлекаете" и что именно "обрабатываете" из XData?
"...тогда и будет их нужная интерпретация" - возникнет волшебным образом? Сама?
Раз Вы знаете секрет, как определить, что в таком-то поле XData описана взаимосвязь, а в таком-то "Primary Key БД", а не наоборот или не что-то еще другое и т.п., то поделитесь же, наконец.
Тема именно об этом.

[Сергей812]

Сообщение от АлексЮстасу что в таком-то поле XData описана взаимосвязь, а в таком-то "Primary Key БД", а не наоборот

уже писал

Сообщение от Сергей812 Вар4. В отдельном AppName XData хранится Primary Key БД. Т.е. унифицированный механизм, преобразующий хэндл примитива и имя файла в логический ключ. А дальше делайте что хотите - привязывайте данные, формируйте логические взаимосвязи - главное, что dwg файл (как некий черный ящик) в этом участвует по минимуму)

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

[__Valdemar]

Сообщение от АлексЮстасу Как узнать, что именно "извлекаете" и что именно "обрабатываете" из XData?

А как мы определяем что сохраняем и потом извлекаем и обрабатываем в локальных (или глобальных) переменных в программном коде (например, на лисп)? Структурой данных и логикой программы. Если принять что application в xdata это имя переменной для хранения значения, то хранимую в них информацию можно жестко структурировать. Записать в виде строки можно длинный и сложный список. Например, такой, какой мы получаем, когда обращаемся из lisp к БД SQL-запросом.
Те же (проверенные временем) атрибуты - в них любые значения (строки, метки, натуральные и вещественные числа) хранятся в виде строк, которые при извлечении сначала интерпретируются, а затем используются должным образом. В любом случае в документе все храниться в бинарном виде.

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

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

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

Сообщение от __Valdemar Если принять что application в xdata это имя переменной для хранения значения, то хранимую в них информацию можно жестко структурировать.

Можно жестко структурировать. Но ничто не мешает появляться Xdata с теми же названиями, но с другой структурой. Защитного механизма для Xdata от этого нет.
И, получив от кого-то данные, не имея соответствующих программ, как определить, что где в Xdata записано?

Сообщение от __Valdemar Те же (проверенные временем) атрибуты - в них любые значения (строки, метки, натуральные и вещественные числа) хранятся в виде строк, которые при извлечении сначала интерпретируются, а затем используются должным образом.

Именно что. У атрибутов есть названия "полей" - названия тегов, уникальные в пределах блока. И у блоков уникальные названия в пределах dwg. Даже при копировании одноименных блоков с другим набором атрибутов после ATTSYNC они будут приведены к одному виду.
Т.е. у атрибутов блоков есть такой защитный механизм, обеспечивающий однозначность определения какой атрибут что содержит.

Придумал еще три варианта:
Вариант 4. В неубиваемом месте dwg хранить Xdata, описывающих нужную структуру используемых application.
Вариант 5. Каждому элементу, к которому присоединяется Xdata с данными, добавлять специальные Xdata с описанием соответствующей структуры.
Вариант 6. Отвести первое строчное поле каждого Xdata под хранение его описания.
Вроде: "Полей: 5; 1 - Long, ID; 2 - Str, Название; 3 - Real, Диаметр; 4- Str, Материал; 5 - Str, Тип". Или т.п.

[Сергей812]

Сообщение от АлексЮстасу Придумал еще три варианта: Вариант 4. В неубиваемом месте dwg хранить Xdata, описывающих нужную структуру используемых application. Вариант 5. Каждому элементу, к которому присоединяется Xdata с данными, добавлять специальные Xdata с описанием соответствующей структуры. Вариант 6. Отвести первое строчное поле каждого Xdata под хранение его описания. Вроде: "Полей: 5; 1 - Long, ID; 2 - Str, Название; 3 - Real, Диаметр; 4- Str, Материал; 5 - Str, Тип". Или т.п.

чудеса велосипедостроения... Вы всерьез думаете, что среди пользователей акада столько программистов-самоучек, прямо так горящих желанием внести деструктивные действия в ваши XData?) Уровень большинства пользователей максимум - это снести все эти скрытые данные в процессе очистки/уменьшения чертежа.

[ShaggyDoc]

Сообщение от Сергей812 чудеса велосипедостроения...

Вот именно. Потому что всё это

Сообщение от Сергей812 Вроде: "Полей: 5; 1 - Long, ID; 2 - Str, Название; 3 - Real, Диаметр; 4- Str, Материал; 5 - Str, Тип". Или т.п.

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

АлексЮстасу никак не может смириться, что базовый AutoCAD - всего лишь "шасси" для разработки предметных приложений. "Вертикальных", "Горизонтальных", "Наискосячных". И все они создаются в результате программирования.

Сообщение от АлексЮстасу Вопрос определенности XData абсолютно одинаков для любого их содержания. Как узнать, что именно "извлекаете" и что именно "обрабатываете" из XData?

А это знает программист и это совершенно не нужно (и вредно) знать пользователю. Он вообще не должен подозревать о существовании каких-то XDATA. Так же, как не знает, что вводя, например точку он изменяет базу данных самого Автокада.

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

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

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

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

Фактически так и поисходит.

Сообщение от ShaggyDoc А это знает программист и это совершенно не нужно (и вредно) знать пользователю. Он вообще не должен подозревать о существовании каких-то XDATA.

Разве спорю? Лишь оговорю, что кроме условных "теток" и программистов еще есть организаторы, техподдержка, технологи и т.п., которым нужно понимать много больше пользователей.

Есть большой класс процессов - обмен данными. В т.ч. нужные данные могут быть в Xdata. (Льзя-нельзя, правильно-неправильно - не в этой теме).
(Так же, как во внешних БД, в Xrecord, в Object Data из Map, Property Sets из Civil, Architecture, MEP, в атрибутах...).

Здесь вопрос о том, как можно записывать в Xdata данные так, чтобы их могли полно и правильно интерпретировать другие. Не Вы сами, а другие. Без Вашего участия, вашего кода и пр. Как это можно сделать с атрибутами, Property Sets и т.п.

У Варианта 4 недостаток, что всегда можно создать Xdata с тем же названием, но другой структуры. Т.е. общее для dwg описание Xdata перестанет быть действительным.
У Варианта 6 недостаток, что в строчном поле Xdata можно записать только 255 (или 259?) символов. Точнее, записать можно хоть 8000, но первый же AUDIT их обрежет. 255 явно мало.
Варианты 2, 3, 5, вроде, неплохи. Самый надежный, однозначный, похоже, Вариант 2. См. первый пост.

[trir]

как можно записывать в Xdata данные так, чтобы их могли полно и правильно интерпретировать другие. Не Вы сами, а другие.

никак

[Сергей812]

Сообщение от trir никак

Бессмысленно, АлексЮстасу на своей волне - ему даже в голову не приходит, что пытаться делать универсальный формат обмена данными с хранением внутри проприетарного dwg - это изначально тупиковая затея)

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

Сообщение от trir никак

Вариант 2 позволяет же это сделать?

[trir]

Вариант 2 позволяет же это сделать?

зачем?

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

Сообщение от trir зачем?

"Зачем", "не нужно" и т.п. обсуждать в других темах.
Здесь тема для обсуждения "как".
Если нечего об этом сказать, то зачем засорять эфир?

Повторю, что есть задача обмена данными. Которые могут быть в Xdata.
Еще есть требования заказчиков. Которые могут заказать данные в Xdata. (Или это тоже вариант обмена?).
И т.д.

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

[trir]

Xdata не предназначен для обмена, а только для хранения - подразумевается, что их читает только тот, кто знает что там записано, а остальным туда соваться не стоит