А вот марка это IndependentTag.

Получить тип IndependentTag.GetTypeId()

Изменить тип:
IndependentTag.ChangeTypeId(Id)

Мы говорим о марках или о самих трубах?
Труба это не семейство (не Фемели инстанс).
Очевидно, нет у трубы FamilyInstance.Type

Зато у трубы есть PypeType
В динамо есть даже нод GetPypeType

Возможно, подтолкнет на какие-то идеи по замене трубы.

А вот и пример скрипта который соединяет 2 любые трубы и вставляет фитинги по умолчанию.
Проверил. У…[Читать далее]

Вариант 1 – использовать формулы в обычном параметре.
Вариант 2 – использовать параметры отчета.

Библиотека насколько я понял, самая обычная – ревит АПИ.
А вот метод лежит в классе BooleanOperationsUtils
Сначала обращаемся к классу, а потом через точку уже и к самому методу
BooleanOperationsUtils.ExecuteBooleanOperationModifyingOriginalSolid – должно отработать.

можно попробовать…[Читать далее]

Копнул поглубже, но объяснить ЭТО я тольком не могу.
Вот ссылка на то, что дало подсказку

https://stackoverflow.com/questions/41350056/calling-specific-property-overload-in-c-sharp-from-python

Теперь код:

unwElem = UnwrapElement(elem)
elemPhase = doc.GetElement(UnwrapElement(x).CreatedPhaseId)
elemSpace = unwElem.Space[elemP…[Читать далее]

Задача элементарно решается если есть ревит Лукап.
Высоту пространства Меп-комнаты по элементу можно считать в одну строчку.
Результат в футах!
h = element.Space.limitOffset

В питон-коде будет выглядеть примерно так:
elements = IN[0]
OUT = map(lambda x: UnwrapElement(x).Space.limitOffset, elements)

http://prorubim.com/ru/tools/r-one-line-diagrams/

Вот, кстати, ссылка на коммерческий скрипт по работе с электрикой.
Как по мне, имеет место быть.
Если предприятие толькло внедряет технологии БИМ, то можно взять за основу.
К сожалению, фактически бесполезен или требует больших трудозатрат при внедрении в уже работающую несколько лет систему.
Лич…[Читать далее]

Предлагаю искать пересечения через Баундинг-бокс и фильтры.
http://thebuildingcoder.typepad.com/blog/2010/12/find-intersecting-elements.html

Единственный недостаток – баундинг бокс ортогонален. Если сильно захочется вращать примечания под углом – будут сложности. Но для ортогонально располагаемых примечаний – быстро и эффективно.

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

Это почему это? для практической работы достаточно 6-10 типов. Я пользуюсь типами 5,7,10,15,20,25,35 мм. Хватает на все. Делать округлением в 5 мм. Норм будет отрабатывать.

Каким образом вы бы реализовали это вручную?
Я бы добавил доп-параметр, по которому таки можно фильровать. Записал бы в этот параметр значение уровня и только потом фильтровал по этому параметру.

Тогда алгоритм по скрипту:
1. Добавить в проект нужный параметр к нужным категориям.
2. найти все семейства.
3. Считать уровень семейства…[Читать далее]

Николай, хорошо, что вы проработали свой вариант.Мне кажется, что этот вариант не самый эффективный. Ваша фраза о невозможности изменять семейства не совсем корректна.
Я предложу свой вариант.
Ранее вы писали:

семейство марок невозможно изменять, задавая параметры.

Мне не нравится слово “семейство”, потому, что мы меняем не семейство а “т…[Читать далее]

в коде строчки 14 и 15 не нужны.
Цикл не надо организовывать вообще.
Вся магия сделана в генераторе списков.

Проверил – удаляет все.

цикл с for надо переписать предлагаю так:
———————————-

SetList = [f for f in fec]
#Получаем все id
IdList = map(lambda x:x.Id, SetList)

#Удаляем все id, естественно, в тразнакции
TransactionManager.Instance.EnsureInTransaction(doc)
for i in IdList:
doc.Delete(i)
TransactionManager.Instance.TransactionTaskDone()

#OUT…[Читать далее]

Но всё же, мне кажется, дело не в отображении геометрии.

К сожалению, большая растрата памяти на прорисовку геометрии – это не мои догадки, а официальное заявление от создателей.
Вот статья на эту тему
https://github.com/DynamoDS/Dynamo/wiki/Efficiently-Working-With-Large-Data-Sets-In-Dynamo

Geometry nodes in Dynamo are always tessellated*…

[Читать далее]

Если речь идет о скрипте из прошлой темы, то я сразу видел проблемы с оптимизацией.
Самое простое решение – отказаться от построения “красивой” геометрии в Динамо. Т.е. Динамо тратит очень большую часть памяти на просчет и рендер графики. От этой фигни можно уйти и пользоваться для отрисовки не нодом Line.ByStartPointEndPoint, а методами…[Читать далее]

Динамо таки плох для обработки больших массивов данных. Постоянно приходится думать об оптимизации алгоритмов и облегчении способов фильрации. Особенно плохо Ревит (а не динамо) работает с большим количеством транзакций.

Вывод: если надо что-то действительно серьезное – ситуацию немножко ускорит python for revit, revitpythonshell, или любая дру…[Читать далее]

Я считаю, что все ответы по теме даны. Я смогу реализовать алгоритм за неделю максимум. Однако у меня нет желания писать за вас диплом, хотя с удовольствием могу помочь в некоторых нюансах.
Денвер 22 предоставил адекватный алгоритм для задачи,
в блоге thebuildingcoder, по ссылке которую я вам привел, решена задача
– Определяете длину полк…[Читать далее]