| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму | Файлообменник |

Вернуться   Форум DWG.RU > Сообщество > Организация проектирования и оформление документации > ГОСТ Р 21.101-2020 Основные требования к проектной и рабочей документации

ГОСТ Р 21.101-2020 Основные требования к проектной и рабочей документации

Ответ
Поиск в этой теме
Непрочитано 03.08.2020, 03:28 3 |
ГОСТ Р 21.101-2020 Основные требования к проектной и рабочей документации
ГОСТ&ОПОКА
 
Регистрация: 10.04.2009
Сообщений: 134

"ГОСТ Р 21.101-2020 Система проектной документации для строительства. Основные требования к проектной и рабочей документации" утвержден приказом Росстандарта от 23.06.2020 N 282-ст и вводится в действие с 01.01.2021 взамен ГОСТ Р 21.1101-2013.

Опубликован на gost.ru
Просмотров: 250945
 
Непрочитано 31.01.2021, 12:22
#181
superkot007


 
Регистрация: 15.01.2010
Сообщений: 254


Цитата:
Сообщение от Sno Посмотреть сообщение
а что мешает горизонтальный А3 вшить?
Да я так и сделаю, просто интересна логика применения горизонтального А4 (п.5.2.7, с основной надписью по длинной стороне) в документах, комплектуемых под вертикальный А4.
superkot007 вне форума  
 
Непрочитано 31.01.2021, 12:55
#182
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Кстати
Цитата:
Сообщение от superkot007 Посмотреть сообщение
Есть текстовый документ, в котором есть несколько страниц, где необходимо развернуть рисунок, чтобы его корректно вписать.
по логике п.5.2.1
Цитата:
На листах формата А4 по ГОСТ 2.301 основную надпись располагают вдоль короткой стороны листа. Для документов в табличной форме допускается располагать основную надпись вдоль длинной стороны листа формата А4.
т.е. не для всех текстовых документов, а только для тех - которые выполнены в табличной форме. Рисунок, надеюсь, в таблице вращаете?)
Сергей812 вне форума  
 
Непрочитано 31.01.2021, 13:48
#183
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от superkot007 Посмотреть сообщение
Да я так и сделаю, просто интересна логика применения горизонтального А4 (п.5.2.7, с основной надписью по длинной стороне) в документах, комплектуемых под вертикальный А4.
А для чего так делать-то - непременно впихать в вертикальную папку разное расположение "штамов" с переворачиванием листов ради того, чтобы основная надпись была непременно в правом нижнем углу? Иначе "расстрел"?

Могу заверить - десятки лет делали, никого не спрашивая, листы А4 с основной надписью вдоль длинной стороны. Если кто-то не сталкивался, не значит что такого нет. Этот действительно в основном таблицы, которые просто не входят в 185 мм по ширине. И такие документы вшивают длинной стороной, как показано на рис. в) приложения И.

Об одном из таких документов и в ГОСТ сказано:
Цитата:
6.2 Групповую спецификацию по форме 8 при ее выполнении на отдельных листах или в виде отдельного документа размещают по длинной стороне листа формата А4 (см. приложение И).
и таких документов много бывает, для которых А3 слишком широкий, а А4 вертикальный слишком узкий. У меня вот программы выводят сотни страниц таблиц с расчетами, оформленными в виде тома. Там как раз и не хватает ширины 185 мм, приходится всячески ужиматься.

ГОСТ просто зафиксировал сложившуюся практику. Но немного неточно написали

Цитата:
Для документов в табличной форме допускается располагать основную надпись вдоль длинной стороны листа формата А4
.
надо бы "Для документов преимущественно в табличной форме...".

Потому что таблицы обычно предваряются несколькими строчками какого-то текста. А так есть повод буквоедам открыть целую ветвь на форуме.
ShaggyDoc вне форума  
 
Непрочитано 31.01.2021, 15:40
#184
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Цитата:
Сообщение от ShaggyDoc Посмотреть сообщение
Потому что таблицы обычно предваряются несколькими строчками какого-то текста. А так есть повод буквоедам открыть целую ветвь на форуме.
Ну для текстовых документов пока еще действует п.4.4.1 ГОСТ Р 2.105-95 ЕСКД. Общие требования к текстовым документам:
Цитата:
Цифровой материал, как правило, оформляют в виде таблиц в соответствии с рисунком 1.
т.е. нет прямого запрета на размещение между заголовком таблицы и самой таблицы еще строчек текста. А ГОСТ Р 2.105 включен в нормативные ссылки ГОСТ Р 21.101-2020. Беда только, что сейчас и нормоконтроль пытается зачастую показать свою полезность для менеджмента в виде ИБД с соответствующей отчетностью - "похоронив" при этом здравый смысл.
Сергей812 вне форума  
 
Непрочитано 31.01.2021, 18:22
#185
Lil377


 
Регистрация: 29.01.2021
Сообщений: 2


Добрый день!
Помогите нормоконтролеру со стажем, но по-видимому, блондинке, понять некоторые моменты касательно Ведомости документов графической части:
а) если графическая часть раздела оформлена в виде отдельных графических документов (в нашей организации ...-Ч1, ...-Ч2 и т.д.), то все они должны быть приведены как в содержании тома, так и в ведомости документов графической части, так? Это если строго придерживаться ГОСТ Р 21.101-2020, пп.4.1.6 и 8.1.5.
К сожалению, такой документ, как Обзор изменений к ГОСТ Р 21.101-2020, где господин Сорокин поясняет, что содержание тома теперь не служит для перечисления документов графической части, для экспертов ГГЭ и ГЭ не аргумент, если они захотят придраться к этому моменту;
б) в наших проектах почти всегда графическая часть разделов не помещается в один том с текстовой частью (так как проектируем трубопроводы), а частенько располагается в нескольких (5-ти - 6-ти) томах. Как в таком случае должен комплектоваться том? Если по ГОСТ, то:
1) титульный лист;
2) содержание тома;
3) ведомость документов графической части;
4) графические документы.
В связи с этим возникают вопросы:
Нужно ли в таком случае содержание тома, ведь оно полностью будет дублировать ведомость документов графической части? Если нет, то на что ссылаться в случае замечаний от экспертов ГЭ?
Ведомость документов графической части вкладывать только в первый том, где начинается графическая часть или во все тома с графикой?
Какие графические документы указывать в ведомости документов графической части в случае, если ее вкладывать в каждый том - ВСЕ графические документы раздела или только те, которые входят в данный том?

Буду благодарна за любые ответы, а особенно если ответит сам Николай Иванович.
Lil377 вне форума  
 
Непрочитано 31.01.2021, 19:16
#186
superkot007


 
Регистрация: 15.01.2010
Сообщений: 254


Цитата:
Сообщение от Lil377 Посмотреть сообщение
все они должны быть приведены как в содержании тома, так и в ведомости документов графической части, так?
Тут об этом диспут на несколько страниц идет, а вы хотите быстро разобраться))
Если текстовая и графическая часть вместе - однозначно да. Но такой неудобный вариант лучше избегать, нелогично часть информации дублировать.
Есть только графическая часть, то формально - да, как может быть комплект без содержания. По логике - нет, в графической части роль содержания тома берет на себя ведомость, будет дублирование по сути.
П.8.1.5 распространяется на ДВА и более документов (между строк - основных, содержание таковым не является).
Мое мнение - НЕТ.

Цитата:
Сообщение от Lil377 Посмотреть сообщение
если они захотят придраться к этому моменту;
Вы не угадаете, к чему могут придраться эксперты. Некоторые вообще считают, что если не напишут замечания, то это будет значить "эксперт не работает".

Цитата:
Сообщение от Lil377 Посмотреть сообщение
Нужно ли в таком случае содержание тома
См. ответ выше.

Цитата:
Сообщение от Lil377 Посмотреть сообщение
Ведомость документов графической части вкладывать только в первый том, где начинается графическая часть или во все тома с графикой?
В каждый том - свою ведомость, с перечислением только тех чертежей, которые в томе. С припиской, что есть другие книги с графической частью (как в случае с текстовой частью).
Логика - вам не нужна избыточная информация о том, чего нет в томе, но в тоже время - вы должны знать, взяв отдельный комплект в руки, что есть связанные с ним (другие графические части).
Так же у вас есть состав проекта, в котором перечислены ВСЕ тома документации.
Хотя, если хотите загрузить проектировщиков - можете в каждый том полную ведомость чертежей вставлять. Ничего при этом не нарушается, но это тяжело с точки зрения формирования общей ведомости, а потом, если будут изменения в документации, изменения придется вносить во все тома графической части (как минимум, корректируя единую ведомость).

Цитата:
Сообщение от Lil377 Посмотреть сообщение
особенно если ответит сам Николай Иванович.
Комментарий Николая Ивановича эксперту вы не приложите, сами же понимаете.
Если только появятся какие-нибудь разъяснения или рекомендации, которые для экспертизы будут иметь какой-то вес... Но это вряд ли.

----- добавлено через ~23 мин. -----
Цитата:
Сообщение от Сергей812 Посмотреть сообщение
по логике п.5.2.1
По логике - да, но мне "шьют"именно п.5.2.7, в котором нет упоминаний, в каких случаях применяется горизонтальный А4.
Мне же не нравится конечный вид документа - где основная надпись для А4 будет "плавать".

ShaggyDoc, вы не поняли суть. Речь о том, что при наличии п.5.2.1 нет смысла делать замечание, ссылаясь на п.5.2.7 в случаях с документами со сплошным текстом. Никто не отрицал, что "горизонтальные А4" существуют, разрешены и используются.
В моем случае содержимое на листе - не таблица, а рисунок. Который маловат для А3, но не вписывается в вертикальный А4 без поворота.

Проще растянуть рисунок (и фиг с ним, что большой получится), развернуть его, разместить на А3 и не тратить больше время, раз доказать бессмысленность п.5.2.7 для конкретного случая не получается ("есть п.5.2.7 - переделывайте").

Последний раз редактировалось superkot007, 31.01.2021 в 19:40.
superkot007 вне форума  
 
Непрочитано 01.02.2021, 07:08
| 1 #187
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от superkot007 Посмотреть сообщение
В моем случае содержимое на листе - не таблица, а рисунок. Который маловат для А3, но не вписывается в вертикальный А4 без поворота.

Проще растянуть рисунок (и фиг с ним, что большой получится), развернуть его, разместить на А3 и не тратить больше время, раз доказать бессмысленность п.5.2.7 для конкретного случая не получается
Если рисунок можно растянуть, то его можно и сжать. И вписать в А4 безо всяких доказательств. Вот у меня в программе в текстовую часть автоматически вписываются иллюстрации, даже большие планы и фасады, сделанные скриншотами, а там могут быть и размеры и другие надписи.

Если же иллюстрация специально подготовлена, то и смотреться будет идеально. Примером тому все ГОСТы с "картинками".
ShaggyDoc вне форума  
 
Непрочитано 01.02.2021, 07:27
#188
Lil377


 
Регистрация: 29.01.2021
Сообщений: 2


Спасибо за ответы)

Цитата:
Тут об этом диспут на несколько страниц идет, а вы хотите быстро разобраться))
Да, конечно хочу)), так как ГОСТ уже вступил в силу и проектировщики требуют от меня шаблоны оформления ПД (уже сегодня). А диспут начался за полгода до вступления ГОСТа в силу. Может, на данный момент уже кто то на практике что то применяет?

Цитата:
П.8.1.5 распространяется на ДВА и более документов (между строк - основных, содержание таковым не является)
Как я писала выше, графическая часть у нас оформляется ОТДЕЛЬНЫМИ графическими документами, имеющими индивидуальное обозначение. Поэтому никогда не получится так, что в том только с графической частью входит ОДИН документ.
Цитата:
По логике - нет, в графической части роль содержания тома берет на себя ведомость, будет дублирование по сути.
Логику я конечно же понимаю, что видно из моих вопросов, но если формально, то придется дублировать...
Цитата:
В каждый том - свою ведомость, с перечислением только тех чертежей, которые в томе. С припиской, что есть другие книги с графической частью (как в случае с текстовой частью)
В случае, когда текстовая часть у нас делится на два тома (по объему), в первом томе на первом листе ТЧ мы приводим содержание обеих частей ТЧ с указанием частей в виде заголовков, в втором - содержание ТЧ только второго тома (ГОСТ 7.32-2017, на который ссылается ГОСТ 2.105).
В содержании же тома мы приводим перечень только тех документов, которые вошли в том. Поэтому для того, чтоб эта ведомость документов графической части несла хоть какой то смысл, отличный от содержания тома, есть мысль приводить там ВСЕ графические документы раздела и просто вкладывать ее в каждый том (при этом работы меньше - ведомость выполняется отдельным файлом и вкладывается в общий ПДФ-файл каждого тома).

Короче, нет у меня понимания необходимости этой ведомости, а для того, чтоб объяснить проектировщикам, для чего теперь они должны выполнять еще один документ, дублирующий содержание тома - я сама должна все это понять
Lil377 вне форума  
 
Непрочитано 03.02.2021, 16:58
#189
temich


 
Регистрация: 10.12.2010
Санкт-Петербург
Сообщений: 35


Цитата:
Сообщение от superkot007 Посмотреть сообщение
Сергей812, не, фишка в другом, прошиваться томик будет по длинной стороне ВСЕХ листов А4) И, соответственно, основная надпись будет то снизу, то сбоку)))
Я так думаю, горизонтальные А4 - это если какие-то табличные формы документов, типа технологических карт, где ВСЕ листы - горизонтальной ориентации, в том числе - титульный.
я рад, что разработчики ГОСТ просто разрешили то, что все и так делают из-за особенностей программного обеспечения.

возьмём например специфику в самой программе WORD
допустим в программе WORD нужно сделать одну страницу - альбомной. остальные - книжные.
по факту проектировщикам настолько муторно сидеть и переделывать "коллонтитул" на одной единственной странице... штамп разворачивать на 90 градусов... (в некоторых шаблонах это вообще нереально)

кому совестно нарушить ГОСТ - делают лист А3.

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

----- добавлено через ~2 мин. -----
то, что штамп "пляшет" - не страшно. главное чтобы время оставалось на само проектирование и расчёты.
temich вне форума  
 
Непрочитано 03.02.2021, 21:54
#190
belikov


 
Регистрация: 22.05.2004
Смоленск
Сообщений: 229


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

Итак, xml-документ начинается с пролога с указанием версии, кодировки и зависимости от схемы. Обязателен только параметр «версия». Кодировка по умолчанию UTF-8, но указать её в явном виде не будет лишним в мире кириллицы. Соответствующей XSL-схемы на сайте Минстроя нет, самостоятельно описывать её нет смысла (да и не корректно — это должен сделать регулятор), поэтому эта часть опущена. Затем я использовал только необходимые элементы по ГОСТ 21.101-2020 и получил минимальную реквизитную часть:
Код:
[Выделить все]
<?xml version="1.0" encoding="utf-8"?>
<!-- Информация о ПДЭ -->
<Package Created="2020-01-01T00:00:00" Organization="Жилбылпроект">
  <!-- Объект строительства -->
  <Project Id="394f8ca5-fb2e-486e-90ec-61dba30a3206">
    <!-- Контейнер для атрибутов объекта строительства -->
    <Attributes>
      <!-- Атрибуты объекта строительства: -->
      <Attribute Name="ProjectName" Value="Многоквартирный жилой дом"/>
      <Attribute Name="Code" Value="2345"/>
    </Attributes>
    <!-- Контейнер для папок и документов -->
    <Children>
      <!-- Здесь может быть описание структуры документов, но оно необязательно -->
    </Children>
  </Project>
</Package>
ГОСТ требует называть этот файл: info.xml

Жирным шрифтом выделены переменные данные. Кажется, всё понятно интуитивно, поэтому расписывать подробно нет нужды. Эта минимальная реквизитная часть не описывает структуру файлов и папок. Зачем она может быть нужна? Возможно, для фиксации [начальной стадии] проекта в различных ведомствах для последующего добавления проектных материалов.

Добавляю в эту структуру один раздел проектной документации — АР, состоящий из двух документов: пояснительной записки АР.ПЗ (исчерпывающей текстовую часть) и планов АР1 (из графической части), выпущенных одним документом.
Код:
[Выделить все]
<?xml version="1.0" encoding="utf-8"?>
<!-- Информация о ПДЭ -->
<Package Created="2020-01-01T00:00:00" Organization="Жилбылпроект">
  <!-- Объект строительства -->
  <Project Id="394f8ca5-fb2e-486e-90ec-61dba30a3206">
    <!-- Контейнер для атрибутов объекта строительства -->
    <Attributes>
      <!-- Атрибуты объекта строительства: -->
      <Attribute Name="ProjectName" Value="Многоквартирный жилой дом"/>
      <Attribute Name="Code" Value="2345"/>
    </Attributes>
    <!-- Контейнер для папок и документов -->
    <Children>
      <!-- Папка (раздел, подраздел, ОКРД) -->
      <Folder Id="4180b6de-7f2a-4259-87d4-79fac425d7ae" Type="Section">
        <!-- Контейнер для атрибутов папки -->
        <Attributes>
          <!-- Атрибуты папки: -->
          <Attribute Name="Number" Value="3"/>
          <Attribute Name="Code" Value="АР"/>
          <Attribute Name="Title" Value="Архитектурные решения"/>
        </Attributes>
        <!-- Контейнер для папок и документов -->
        <Children>
          <!-- Документ -->
          <Document Id="cdb89572-bbe2-4096-a15a-452ce984af06" Created="2020-01-01T00:00:00" FileName="2345-АР.ПЗ.pdf">
            <!-- Контейнер для атрибутов документа -->
            <Attributes>
              <!-- Атрибуты документа: -->
              <Attribute Name="Code" Value="2345-АР.ПЗ"/>
              <Attribute Name="DocumentName" Value="Пояснительная записка"/>
              <Attribute Name="Sheet" Value="5"/>
            </Attributes>
          </Document>
          <!-- Документ -->
          <Document Id="3ee70899-ffe1-41f0-904b-7fd6b4ce3e2e" Created="2020-01-01T00:00:00" FileName="2345-АР1.pdf">
            <!-- Контейнер для атрибутов документа -->
            <Attributes>
              <!-- Атрибуты документа: -->
              <Attribute Name="Code" Value="2345-АР1"/>
              <Attribute Name="DocumentName" Value="Планы этажей"/>
              <Attribute Name="Sheet" Value="10"/>
            </Attributes>
          </Document>
        </Children>
      </Folder>
    </Children>
  </Project>
</Package>
По этой аналогии нужно описать и остальные разделы. Приводить длинный листинг, полагаю, нет нужды. Параметр Sheet, описанный в ГОСТ как «номер листа» оставил меня в недоумении: полагаю, подразумевается количество листов документа, а не порядковый номер. Обоснование: порядковый номер из количества вычисляется однозначно, а наоборот — нет.

Длинные числа — это т.н. GUID, уникальный идентификатор, который вполне можно присвоить вручную, а не только автоматизированным способом, как предписывает ГОСТ. Это просто большое число, вероятность повторения которого кем-либо ещё крайне мала. Его можно выдумать или заставить выдумать Windows набрав в командной строке:

powershell -Command "[guid]::NewGuid().ToString()"

Эти идентификаторы нужно проставить в рамках одного проекта один раз и больше не трогать. Правда, это мои домыслы, т.к. в ГОСТ нигде прямо об этом не говорится. Полагаю, что в противном случае регулятор потребовал бы от нас вычислять хэш; а так это просто якорь, который связывает версии одних и тех же элементов.

Отмечу неожиданный побочный эффект: ручной разбор добавил ясности в понимании структуры технической документации. По крайней мере в том, какой её хочет от нас видеть регулятор.

P.S. Жилбылпроект — это не только заполнитель, но и вполне реальное ООО.

P.P.S. Добавлено спустя 10 дней: кажется, я догадался про назначение параметра Sheet. По всей вероятности он рассчитан на то, что документ может быть представлен не единым файлом, а полистно. Тогда каждому такому файлу понадобится идентификатор листа. Если же документ содержится в файле целиком, то этот параметр, полагаю, нужно опускать (я зачеркнул его вхождение в листинге).

P.P.S. Добавлено спустя ещё 10 дней: появилась схема (см. ниже пост #216), благодаря которой отловил несколько ошибок в своём примере. Пример откорректирован и теперь валидацию проходит.

Последний раз редактировалось belikov, 24.02.2021 в 11:43.
belikov вне форума  
 
Непрочитано 03.02.2021, 23:34
#191
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


belikov, все это подразумевает наличие в фирме системы электронного документооборота - потому что заполнение вручную xml-разметки мягко говоря... И тогда можно бы действительно упростить этот ГОСТ Р 21.101-2020 с переводом части явной визуальной составляющей (например, тех же отображений изменений в проекте) в содержимое БД с выгрузкой в xml при необходимости. Но пока еще для большинства фирм даже системы электронного документа в проектировании - далекая экзотика, не говоря уже об комплексных системах проектирования типа того же информационного моделирования.
Сергей812 вне форума  
 
Непрочитано 04.02.2021, 08:09
#192
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от belikov Посмотреть сообщение
Изложу свои соображения по реализации реквизитной части в виде XML-документа. Примеров отгуглить не удалось, лишь косвенные (кадастровые инженеры, органы экспертизы уже сдают что-то подобное)
А кому они нужны, эти "свои соображения", как бы правильны они не были? Думаете этот форум кто-то из "лиц, принимающих решение" читает?
Читает Сорокин, но и он к этим деталям по XML не имеет отношения. А вообще-то "все уже украдено задумано до нас".

В этой теме в постах #7...#11 я уже делился опытом работы с XML в Минэнерго при работе с энергетическими паспортами. То, что Вы предполагаете "уже сдают что-то подобное". Сдают уже 11 лет.

Сама идея сопровождения любой информации в XML совершенно правильная. Но "дьявол прячется в деталях". Подробнее в #7.

Но работа уже кипит. Новость от 26.10.2020
Цитата:
На официальном сайте Министерства строительства и жилищно-коммунального хозяйства Российской Федерации 21 октября 2020 года размещена XML-схема формата представления локальных сметных расчетов для проведения государственной экспертизы проектной документации и (или) результатов инженерных изысканий и проверки достоверности определения сметной стоимости строительства, реконструкции, капитального ремонта объектов капитального строительства.
При этом документ, названный "Описание XML-схемы" на сайте Минстроя открыть удалось с 5-й попытки. Но там только словесное описание в "бюрократической" форме на 79 страницах. Я ее прилагаю, чтоб другим не мучиться.

И это уже совсем не те жалкие таблицы Ф1...Ф9 в ГОСТ. В ГОСТ это так, для вида, чтобы "застолбить". А кто эти "неизвестные отцы", которые это "изобрели"? Конечно это не чиновники Минстроя и не АО «ЦНС» (как бы автор ГОСТ).

Это явно "компьютерная" фирма которой достался этот жирный кусок. Возможно та же, что окучивает Минэнерго. И правильно делает, если все министерства обработает.

Вот только для того, чтобы "чисто конкретно" реализовать идею с XML, нужны две "маленький, но нужный вещь":

1. XSD-схема, т.е. то же "описание", но само написанное на XML, лежащая на быстром общедоступном ресурсе, и неизменная на определенный жизненный срок.

2. Программа или несколько программ, с помощью которой все проектировщики смогут создавать этот info-xml, а экспертизы и все прочие его читать, проверять и преобразовывать в какие-то необходимые им документы.

Ни пункта 1, ни 2 пока нет, но над ними конечно работают. По прежнему опыту - это будет тянуться долго, хотя наверняка первые версии должны появиться "вот-вот". Ну, как пандемия кончится, так сразу.

А всем проектировщикам, а также негосударственным экспертизам, и государственным, но "областным" следует копить деньги на покупку программы. А будет она сетевой, с ограниченным сроком действия и часто обновляющейся.
Вложения
Тип файла: pdf Prilozhenie-1.-Opisanie-XML_skhemy-zaklyucheniya-ekspertizy-_1_.pdf (1.08 Мб, 100 просмотров)
ShaggyDoc вне форума  
 
Непрочитано 04.02.2021, 09:22
#193
belikov


 
Регистрация: 22.05.2004
Смоленск
Сообщений: 229


Сергей812, специализированные системы документооборота для проектных организаций уже долгое время не покидают стадию сферического коня в вакууме. Где-то у них есть свои пользователи, как есть и те, кто «уже проектируют в BIM». Но на практике о них в основном приходится читать в журналах, а не от коллег слышать. Я бы не очень на всё это рассчитывал, тем более, что строительное проектирование — не единственная сфера с подобными потребностями. Многое уже придумано «до нас» и, самое главное, работает. Миллионы разработчиков софта, технической документации и прочего прямо сейчас используют в качестве точки хранения своих проектов хостинг git-репозиториев, а в качестве взаимодействия — пулл-реквест и мерджи. Это тоже нетривиальные процедуры, но не сложнее постижения предлагаемых на рынке систем документооборота. При этом «шарящих в git» на рынке больше на три-четыре порядка. Рукопашное заполнение xml-схемы — это крайности, конечно. Её может обслуживать нехитрый питонячий скрипт, натравленный на репозиторий, а ещё лучше — встроенный в пайплайн процесса, при котором любой пулл-реквест в мастер-ветку будет актуализировать info.xml, после чего можно просто забыть об этом.

ShaggyDoc, у меня довольно простая задача: приложить что-то в архив проектов, стартующих в этом году. Мы «рожаем» подлинники документов в электронном виде и это офигенно как удобно. Стадию П уже перестали печатать вообще, печать рабочки перенесли в договор об авторском надзоре и печатаем по необходимости с каждым проектом всё меньше и меньше. Вчера я убедился, что можно даже врукопашную обслужить небольшие объёмы, если не будет ресурсов на автоматизацию. Разделяю опасения, что этот момент можно искусственно усложнить: потребовать какие-нибудь хэши по ГОСТ 34.11-2018 (претендует на самый упоротый из всех гостов!) и всякое такое. С другой стороны, даже если всё будет просто и ясно, 8 из 10 всё равно прикупят подходящий софт даже не ничего анализируя. Я надеюсь, что «неизвестным отцам» этого будет достаточно.
belikov вне форума  
 
Непрочитано 04.02.2021, 10:05
#194
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от belikov Посмотреть сообщение
Вчера я убедился, что можно даже врукопашную обслужить небольшие объёмы, если не будет ресурсов на автоматизацию.
Уж не собираетесь ли "сочинять" info.xml вручную? Конечно, теоретически это можно сделать и в "Блокноте", а лучше в Notepad++, в котором и подсветка синтаксиса, и сворачивание элементов. Но и это только при наличии XSD-схемы, да какого-нибудь реального, прошедшего "валидацию" примера. Ну, попробуйте, не допустить ошибки ни в одном символе и ни в одном коде.

Проще написать собственную программу генерации XML по данным, введенным в "человеческом" виде. Это не так уж трудно.

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

А принимать все наши труды будут даже не люди, а программа, которая будет постоянно "совершенствоваться". Мы присылаем, "девочка" загружает в программу, а в ее форме красным высвечиваются ошибки. Извольте переделывать. Исправите эти, а тас найдутся новые.

Как уже происходило - и я, и несколько других фирм делали генераторы XML, и они хорошо работали. А потом разработчики "единственно верной" вносили изменения и в программу, и в схему, но нигде официально изменения схемы не публикуя (а им это и не заказывали). В результате и на приходилось покупать их программу.

Цитата:
Сообщение от belikov Посмотреть сообщение
Я надеюсь, что «неизвестным отцам» этого будет достаточно
Зря надеетесь. "Прикупать" придется много раз. И еще неизвестно, как эти "отцы" будут справляться с потоком info.xml, которых будут десятки тысяч. Столько "негров" даже для черновой работы у них нет. Но покупать придется, даже если все это никак не будет обрабатываться.
ShaggyDoc вне форума  
 
Непрочитано 04.02.2021, 10:58
#195
belikov


 
Регистрация: 22.05.2004
Смоленск
Сообщений: 229


Цитата:
Сообщение от ShaggyDoc Посмотреть сообщение
Уж не собираетесь ли "сочинять" info.xml вручную? Конечно, теоретически это можно сделать и в "Блокноте", а лучше в Notepad++, в котором и подсветка синтаксиса, и сворачивание элементов. Но и это только при наличии XSD-схемы, да какого-нибудь реального, прошедшего "валидацию" примера. Ну, попробуйте, не допустить ошибки ни в одном символе и ни в одном коде.

Проще написать собственную программу генерации XML по данным, введенным в "человеческом" виде. Это не так уж трудно.
Не вижу проблем генерировать реквизитную часть по ГОСТ 21.101-2020 «на своей кухне». В вашей практике схема была существенно сложнее, но здесь же она совершенно тривиальная и я просто не представляю, где бы её можно было замудохать регулярными изменениями в XSD. Для малой автоматизации путей много, самый простой, что приходит в голову это воспользоваться Asciidoc: у него есть макросы, включения и условия — всё, что нужно. Тогда код минимальной реквизитной части будет таким:
Код:
[Выделить все]
// Переменные данные
:Organization: Жилбылпроект
:ProjectData: 2020-01-01T00:00:00
:ProjectName: Многоквартирный жилой дом
:ProjectCode: 2345
:ProjectGUID: 394f8ca5-fb2e-486e-90ec-61dba30a3206

// Сама разметка, никогда не трогаем
<?xml version="1.0" encoding="utf-8"?>
<Package Created="{ProjectData}" Organization="{Organization}">
  <Project Id="{ProjectGUID}">
    <Attributes>
      <Attribute Name="ProjectName" Value="{ProjectName}"/>
      <Attribute Name="Code" Value="{ProjectCode}"/>
    </Attributes>
    <Children>
    </Children>
  </Project>
</Package>
И проблема «случайно что-то изменить» устраняется. Быстро попробовать онлайн можно на asciidoclive.com, вставив приведённый здесь код и сразу получить результат.
belikov вне форума  
 
Непрочитано 04.02.2021, 11:37
#196
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от belikov Посмотреть сообщение
Не вижу проблем генерировать реквизитную часть
Ну, так попробуйте и сдайте свой проект. Не с 5 реквизитами, а все, что полагается.
ShaggyDoc вне форума  
 
Непрочитано 04.02.2021, 12:03
#197
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Цитата:
Сообщение от belikov Посмотреть сообщение
Для малой автоматизации
малая автоматизация - это что "крутится" внутри фирмы либо у отдельных продвинутых сотрудников.. А заставить не подчиненные вам хотя бы по договору подряда фирмы принять вашу xml-схему в качестве рабочей - изначально тупиковая задача. Про госорганизации уже выше вам писали. А так было - что и в экселе писали сопроводительную информацию по заданным шаблонам для файлов проекта заказчика.. ну так там фирма прислала стандарт оформления, да и серьезные штрафы за каждый день просрочки сдачи проекта с 5 нулями прописала в договоре - все по взрослому)
Сергей812 вне форума  
 
Непрочитано 04.02.2021, 12:36
#198
Петр-и-Алекс


 
Регистрация: 18.01.2021
Сообщений: 404


№192

"А всем проектировщикам, а также негосударственным экспертизам, и государственным, но "областным" следует копить деньги на покупку программы. А будет она сетевой, с ограниченным сроком действия и часто обновляющейся."
маленькое уточнение:
в приличном обществе уже нет "покупки программы". Современность в "подписке".
То есть, в помесячной оплате на условиях "предоставителя услуг".
Сегодня даже чернила к принтерам не продаются, а подписываются. Типа: нет подписки на февраль - притер не печатает, будь тебя хоть бочка чернил в кладовке...
так не всегда пока что, но "уже"
Петр-и-Алекс вне форума  
 
Непрочитано 04.02.2021, 14:34
#199
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


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

А мы-то, дураки, двадцать лет торгуем и ничего не знаем... Да что с нас возьмешь - мы "с Урала"... У нас, дураков, даже принтеры печатают...
ShaggyDoc вне форума  
 
Непрочитано 04.02.2021, 14:47
| 1 #200
Петр-и-Алекс


 
Регистрация: 18.01.2021
Сообщений: 404


как вы однако озлоблены и самоуверены
дураки, мы с урала - сидит в вашем сознании, и представить себе не в состоянии, что собеседник вообще может не думать об этом
жаль
Петр-и-Алекс вне форума  
Ответ
Вернуться   Форум DWG.RU > Сообщество > Организация проектирования и оформление документации > ГОСТ Р 21.101-2020 Основные требования к проектной и рабочей документации

Размещение рекламы
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Требования к проектной документации при реконструкции производственного здания (ТЭЦ) VZK Организация проектирования и оформление документации 24 28.01.2018 08:01
Несоответствие рабочей документации проектной GAS101 Организация проектирования и оформление документации 28 02.12.2015 17:56
Правомерно ли в проекте перерисовывать серийные узлы Mitya Прочее. Архитектура и строительство 28 16.07.2014 17:57
Отличие проектной документации от рабочей (раздел 4 и другие тоже) Aragorn Архитектура 64 02.06.2014 13:16