Удалено

К сожалению, разговор скатился до ситуации "что лучше 50 копеек или 2 по 25 копеек?".



Выбор XML был сделан по тем (и некоторым другим) причинам, которые я отмечал в предыдущих постах. Если Вы считаете что с XML работать умели, а с DXF не умели, то смею Вас заверить - вы ошибаетесь. Имея хорошую библиотеку (парсер), работать можно, как Вам хорошо известно, с чем угодно.



Мне даже иногда кажется, что если бы случилось так, что мы взяли в качестве основы для ОФ-ТД формат DXF, то кто-то бы сейчас писал что-то типа "а почему не XML??? DXF - ерунда! XML - более общий! SVG - поддерживается кучей браузеров, да он даже читаем лучше! ...."


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


---
зам. рук НТЦ-САПР ПГУПС, Зуев Денис Владимирович.

Удалено

Увязка с АСУШ-2.
Работа с АС-СТД.
Работы по моделированию пропускной способностью участков ЖД.
Были еще перспективные наработки с Радиоавионикой и еще парой организаций, но по ряду причин приостановленные.

Сейчас у КАСПРа больше использование, так как узаконили его использование внутри РЖДП.
а так да, доработки - бесконечный механизм :lol:

Dmitriy_S добавил 20.08.2013 в 13:53
исчерпали уже давно :lol:
каждый останется при своем мнении!

Ну картинку так то можно хранить внутри ОФ-ТД хоть в растре, заключил в CDATA и поехали. Картинка строится по данным которые хранятся в оф-тд. И кстати.. это вполне верно. Ведь в dxf хранится графика, на которую навешаны атрибуты. А в офтд хранятся именно данные и картинка - лишь визульная часть. Т.е. подход в офтд- декларативное описание документа. Описываются именно данные. что по мне так - верно.
И еще. Вы говорили, что хмл-формат для передачи данных в интернете(?). ну дык! он и будет вращаться между различными системами. Он и служит для этого, он разработан был для этого!

Удалено

не согласен!!!!
есть куча полноценных форматов на основе XML, и графические и офисные и много чего.
но в САПРах, да сейчас он имеет меньшее распостранение по историческим причинам

Dmitriy_S добавил 20.08.2013 в 15:43
Такой режим использования имеет место быть, но это не значит что только в таком режиме его и используют :sm496:

ик. Вы еще предложите web-сервисы поднять на дороге.. по мне так уж проще ОФ-ТД, куда понятнее. Всеж какой-то тупик выходит с Вами. Не воспринимайте офтд как что-то что кого-то куда-то должно вытеснить, кому-то связать руки, обречь на что-то)
Это просто формат в котором говорится. Что есть элемент положим стрелка, который соотвествует стрелке. И если вы хотите сказать что эта стрелка спаренна с вот той, то сделать это надо так: Добавить элемент "Стрелка" и поставить атрибут "Спаренность". и этот атрибут согласно формату должен называться именно "Спаренность", а не "СпаренаСТой", "ОнаСпарена" и т.д.

Видите ли в чем дело.
Использование dxf позволило бы юзать схемы во множестве существующих приложений (с использованием дополнительных библиотек arx безусловно). Но разработчикам ведь это не нужно :-).
Им нужно продать продукт. Весьма сырой и глючный продукт :-)

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

спорный вопрос, для ВТД выгодно наличие схем которые будут совместимы с ОФТД и могут без проблем потом эксплуатироваться на дороге, если появится САПР, описание элементов которого будет совместимо с ОФТД, то это очень хорошо!
Конкуренция конечно станет сильнее, но это тоже плюс :laduh:

тут не поспоришь ))))

Вопрос в чем рисовать чертежи, какой САПР для этого использовать, этот вопрос поймите, не стоИт. Хоть в визио, хоть в экселе (видел тут в экселе, был обескуражен, всё внутри прям перевернулось). Вам удобно, вы рисуете. Другое дело, программное обеспечение, которое позволяет вам получать удовольствие от рисования схем, является ли оно "прозрачным", поймите, дороге не нужна простая картинка, дороге нужна документация, нужна информация, а не просто распечатал и пошел. Так вот, формат ОФТД открытый, синтезировать его можно на любой оси, есть не глючные отточенные библиотеки для работы с XML. Дык вот, если ваш САПР такой замечательный он должен иметь информацию об элементах. ObjectARX это или дополнительные какие-нибудь метаданные, не суть важно. Так вот. Вы знаете как у вас называется атрибут, вы знаете чему он соотвествует в формате офтд. В чем проблема вам самим написать конвертор из вашего замечательного формата. Мне действительно всё равно какой САПР вы используете для работы. Но извините, ваш САПР должен содержать информацию об элементах. Если не содержит, тогда стОит подумать, а хорош ли ваш САПР? К примеру, КАСПР хорош.. Об этом говорит и тот факт, что написаны и развиваются конверторы. Т.е. пожалуйста рисуйте в чистом КАСПР. И не волнуйтесь, не ваша забота потом из него получить ОФ-ТД. Но чистый КАСПР! Автокад позволяет ВСЁ! но вы должны работать в рамках КАСПР. Не хотите АРМы от ИМСАТА, не хотите КАСПР. Не кто не заставляет используйте другой САПР, но он должен быть не просто средством для рисования картинок, а быть САПРом.

Удалено

Вообще-то это проблема того, кто начинает думать о "своем" САПРе...

ОФТД предусматривает хранение произвольных атрибутов в документе, важны только два момента:
1. Конверторы должны их перевести в ОФТД (сохранить в документе), а потом восстановить обратно.
2. Правки в документе со стороны ВТД должны не влиять на дополнительные атрибуты. Абстрактный пример небольшой: у реле есть атрибут замедление и еще атрибут атрибут Вашего сапра величина замедления. После правки в ВТД реле сделали без замедления, но атрибут величина замедления остался - будет расинхронизация в атрибутах. Привет придуман с головы, но смысл надеюсь понятен.
Если параметры данные важны, то логично их вынести на обсуждение и включить в новую редакцию ОФТД иначе проверку их корректности придется делать САПРу, который знает эти атрибуты.

Я несколько другое имел ввиду.
Формат dxf тем и хорош, что может быть дополнен новыми объектами, которые обладают заданным набором методов и свойств.
А то, что библиотеки для обработки свои - ну это тоже не совсем так.
Вполне возможно писать универсальные библиотеки (скажем .NET), которые смогут работать в разных приложениях. Объектная модель ведь одна.