[Мансур]

Доброго дня! Есть задачка в AutoCAD объединить огромную кучу отрезков в полилинии в автоматическом режиме (чистка большого файла съемки). Средства типа pedit, pljoin банально вешают AutoCAD из-за слишком большого количества элементов. Гугл облазил вдоль и поперек, но может пропустил что-то готовое? Прежде чем писать велосипед, хотелось бы узнать, нет ли еще чего-то подходящего.

P.S. Написал утилиту на лиспе, качать здесь, здесь, исходники
Команда MTMDJOIN:
1) выбрать объекты (условие - выбираемые объекты должны быть в пределах экрана)
2) указать допустимое отклонение
Функция (mtmdjoin sset tolerance) -> возвращает список (plines_created lines_converted)

В отличие от существующих программ моя утилита объединяет отрезки более интеллектуально (если несколько линий сходятся в одной точке, то объединяются линии, находящиеся под бОльшим углом друг к другу, формируя более длинные полилинии.
Скорость работы достаточная - на Core i5 3.3Ггц, Win7x64, AutoCAD 2012, 20 тысяч отрезков обрабатываются около 15 секунд.

[Boxa]

1. Насколько большая куча?
2. Это http://www.debalance.com/optimization/polyline.html пробовали?

[Мансур]

например, на одном из слоев 21412 отрезка.
superpurge уже попробовал - зависает.

[Sleekka]

overkill с опцией end_to_end ?
а иначе фильтровать по x, по 100 штук соединять по отдельности и т.д. т.е. разбить задачу - сделать рекурсивный pljoin чтобы в одной итерации было не более 100 шт. например.

[Дима_]

Сообщение от Мансур например, на одном из слоев 21412 отрезка.

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

[Мансур]

Выдрал один слой, если кому интересно попробовать порешать задачку: http://bit.ly/144AEkt
Многие линии между собой не стыкуются. Думаю, что особенно короткие сегменты есть смысл подтягивать к более длинным, а примерно одинаковые - двигать друг к другу.

P.S. Только сейчас дошло, что еще надо учитывать минимальный угол между отрезками - т.к. в силу специфики задачи есть куча линий штриховки откосов, которые надо игнорировать.

[Boxa]

Сообщение от Мансур Выдрал один слой, если кому интересно попробовать порешать задачку

А Ваши наработки можно посмотреть?

[nolte]

хотелось бы увидеть решение, ну, если это вообще осуществимо.

[Мансур]

Сообщение от Boxa А Ваши наработки можно посмотреть?

Конкретно за эту задачу я только сейчас взялся - пока прикидываю прототип на лиспе.
Если вообще - то мой сайт mtmlab.ru, там конечно мало, но тем не менее, *welcome*

[Дима_]

Ихмо на Автолиспе быстро не получиться, и тут даже не в том беда, что сам лисп медленней, а то что он умеет работать только со списками (ни хешей, ни деревьев он не знает), а в данной задаче это критично (не беда в том, что допустим, он читает данные в 10 раз медленне - 1 и 10 секунд разница конечно есть, но не смертельная - а вот перебрать какие примитивы есть в списке - это последовательный перебор "пока не совпало" (а если не совпало - то весь список) и на каждую полилинию весь список отрезков прогонять - долго) - можно ограничиться фильтром поиска из координат примитива - будет быстрее, но все равно эта операция (фильтрация) очень долгая, а ее надо опять-таки прогнать к каждому примитиву. Я вижу только 1 вариант - создавать индексированную или "двоичную" коллекцию (Dictionary<>,Hashtable<>,Map<>,Set<>... - не суть кому что привычней) - типо ключевая_точка*список_точек (причем на каждую точку будет как ключевое поле, так и она 100% будет входить в какой(ие),либо значения), настраиваешь интерфес используемый для быстрого поиска (сортировки или хеширования) на учет допуска (то есть, чтоб при занесении он 0.999:0.999 и 1.0:1.0 за одно и тоже считал), либо предварительно "подгоняешь" близкие точки под существующие, либо - самый простой вариант - просто округляешь их и вот в такой коллекции уже можно поискать контуры за разумное время - а по ним уже соответственно и построить примитивы.

[Do$]

Похоже на экспорт из Civil3D. То есть, там взрываем, потом в простом Автокаде снова собираем... Если есть исходный чертеж в Civil 3D (ну и сама программа, разумеется), задачу можно сильно упростить.

[Мансур]

после двухдневного ковыряния и отлавливания багов в трех соснах вышло следующее:
150 строк лиспа (всё еще сырой прототип), (без никаких ActiveX-ов, если что)
время выполнения (вместе с отрисовкой 1619ти получившихся полилиний) - 35 сек.
Машинка - Core2Duo 2.6Гц, Win7x64, AutoCAD 2012, ядро задействуется только одно, я так понимаю, раз автокад
Наверно можно еще немного побаловаться оптимизацией
Код пока не выкладываю

[Дима_]

Сообщение от Мансур время выполнения (вместе с отрисовкой 1619ти получившихся полилиний) - 35 сек.

Ну уже не "колом встает", подумал тут на досуге - а ведь и в автолиспе ничего не мешает реализовать структуру двоичного дерева поиска - типо список '(ключ-значение все_ключи_меньше все_больше). И при правильной предварительной "рассортировки" время доступа к элементу по ключу будет логарифмическое.

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

Сообщение от Мансур Доброго дня! Есть задачка в AutoCAD объединить огромную кучу отрезков в полилинии в автоматическом режиме (чистка большого файла съемки). Средства типа pedit, pljoin банально вешают AutoCAD из-за слишком большого количества элементов. Гугл облазил вдоль и поперек, но может пропустил что-то готовое? Прежде чем писать велосипед, хотелось бы узнать, нет ли еще чего-то подходящего.

В Map 3D (Civil 3D) c 2004 г., минимум, есть Drawing cleanup (Корректировка), а в нем Snap clustered nodes (Сводить узлы в один) - для убирания разрывов или перелетов, если они есть, и Dissolve pseudo nodes (Удалять псевдоузлы) - собственно сшивание.

Есть еще одна частная программка. Она сшивает только соответствующие друг другу свойствами элементы. Синий отрезок из одного слоя с красным из другого не сошьет - как все остальные программы. Если хотите, то давайте файл, я попробую запустить.
У Вас чертежи из какой сферы деятельности?

[Мансур]

Сообщение от АлексЮстасу Есть еще одна частная программка. Она сшивает только соответствующие друг другу свойствами элементы. Синий отрезок из одного слоя с красным из другого не сошьет - как все остальные программы. Если хотите, то давайте файл, я попробую запустить. У Вас чертежи из какой сферы деятельности?

Нефтянка. Слой из съемки, это от каких-то левых изыскателей. Ссылка на файл была выше, дублирую: http://bit.ly/144AEkt
Очень сомневаюсь, что экспорт из Civil-a, как предположил Do$, уж очень коряво стыкуются отдельные отрезки.

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

Больше похоже совсем не на Civil, а на отечественного производителя - Геоникс. После него все рассыпается.
И там есть сплайны, штриховки и т.п.
Есть ряд элементов на какой-то высоте.
Я на всякий случай вынес надписи из слоя Съемка в слой Съемка_текст.
Взял на себя смелость поставить рабочие единицы метры вместо миллиметров.
Но пока та частная программа вышибает Автокад ))

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

[Do$]

Offtop: В чертеже только от Civil "следы", вот поэтому и предположил. В чертежах после Геоникса, которые ко мне попадали, сложно было не заметить его "следов".

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

Offtop: Почему-то никто не вспомнил про PlTools с его PL-JOIN.

Как мог посшивал с разными допусками.
Красные круги - места противоречивые, где не сшивалось. Но эти маркеры остались только от последнего запуска, и их много больше.
И там видно, что многое сшилось неправильно по сути. Но слой-цвет и пр. один, и автомату не объяснишь.

Offtop: Если не оч. большой секрет, то шепните, кто такие шедевры топографического черчения выдает? Я сам топограф.

[Do$]

Сообщение от АлексЮстасу Offtop: Почему-то никто не вспомнил про PlTools с его PL-JOIN.

Offtop: Есть в первом сообщении.

[Кочетков Андрей]

Сообщение от Мансур Прежде чем писать велосипед, хотелось бы узнать, нет ли еще чего-то подходящего

PJS by Toolpac ?

[Мансур]

Вот что в итоге получилось, тестируем, отписываемся, кому интересно.
http://mtmlab.ru/files/arx/mtmdjoin.zip

Команда MTMDJOIN
Из-за особенностей функции ssget необходимо чтобы область с объектами была видима,
т.е. если увеличить какой-то участок и затем выбрать все объекты опцией _all, будут обработаны только участки, видимые на экране.
Пока что никаких опций, максимальное расстояние между соседними сегментами 0.03 и максимальный угол "расхождения" сегментов 1 радиан

[Дима_]

Сообщение от Мансур Вот что в итоге получилось, тестируем, отписываемся, кому интересно.

Я б может и посмотрел - но смотреть не на что.

[Мансур]

Обновил программу, добавил запрос допустимого расстояния и функцию для неинтерактивного вызова:
(mtmdjoin sset tolerance) -> возвращает список (plines_created lines_converted)

[Мансур]

Кто там говорил, что отдельные штрихи не сшить?
Прототип, сшивающий штрихи в полилинии, уже работает, осталось причесать...
Во вложении получившийся файл, слой "Съемка_dash" - получившиеся линии, "Съемка_dashold" - исходные штрихи
Ну и до кучи - результат сшивания непрерывных линий. Никакой ручной доводки, кроме разве что выбора типа линии и масштаба LTSCALE

[Meat_12237]

Здравствуйте.

Работаю в Bricscad-е. Файлы *.vlx моя версия не читает.
Пробовал загрузить исходник. Пишет следующее:

Загрузка /u/emdunilina_inet/download/mtmdjoin.lsp
: (LOAD "/u/emdunilina_inet/download/mtmdjoin.lsp")
; ----- Error around expression -----
(LOAD "/u/emdunilina_inet/download/mtmdjoin.lsp")
;
; error : syntax-error <".loader_config={xpid:"> at [READ]

Подскажите, пожалуйста, что делаю не так ?

[gomer]

Не вижу никаких проблем с загрузкой исходника, скорей всего у вашего админа паранойя..