Импортируем DXF чертеж в программе на Java, наступая на все грабли этого простого формата Хабрахабр. Auto. CAD и подобные ему САПР давно уже стали стандартом в области проектирования, и неудивительно что таким же стандартом стали широко используемые в них форматы файлов DWGDXF. Так что если вы разрабатываете какое то решение для архитекторов и проектировщиков, то умение работать с этими форматами ну или хотя бы с одним из них must have фича вашего продукта. В рамках своего вебсервиса для симуляции движения пешеходов пришлось и мне озаботиться импортом генпланов в этих форматах. Раньше с САПР я дела не имел, поэтому наивно думал да что там, подумаешь еще один формат чертежей, линии и многоугольники, что там может быть сложного. Но в процессе работы выяснилось что сложного там может быть достаточно, некоторые нюансы вполне похожи на древние костыли, тянущиеся из глубин веков, при этом многие вещи толком не документированы в спецификациях самого формата например работа с блоками или с кривыми. Interoperability.13.54.2.png' alt='Dxf Чертежи Для Лазерной Резки' title='Dxf Чертежи Для Лазерной Резки' />Видимо они считаются очевидными для любого чертежника, но что делать если вы родом из другой области, и таких знаний не имеете В общем под катом перечисление граблей и решений, которые не удалось нагуглить и пришлось добывать полуночными бдениями над чертежами. Решаемая задача. Мне для моего приложения на Java нужно было настроить импорт генпланов районов и конвертацию его во внутреннее упрощенное Geo. JSON представление. При этом мне не нужна была полная информация и все виды сущностей, лишь некоторая их часть, которая бы использовалась в симуляции. Так что данный материал не охватывает все возможности и Нетривиальные Технические Решения DXF. А почему именно DXF, а не DWG А про это ниже. Выбор формата. Итак, что в первую очередь ассоциируется со словами автокад и формат файла Бинарный закрытый формат, который изначально был создан Auto. Импорт чертежа в формате DXF. Задача построения геометрии исследуемого объекта в ELCUT может решаться двумя путями Построение геометрии. Deskом и его спецификации не раскрывались, однако в свое время он был удачно реверснут Open Design Alliance. И вот тут следует разочарование. Есть библиотека по работе с ним от Auto. Desk. Есть популярная библиотека Teigha, созданная ODA. Обе они платные, причем хорошо платные речь о сотнях и тысячах долларов. Не подходит. Есть некоторое количество попыток реализовать стандарт в виде бесплатного Open source решения. Например jdwglib. Но все они давно мертвы, обновлялись последний раз 5 1. А прогресс не стоит на месте, новые версии автокада добавляют новые фичи и в DWG, в итоге с мечтой читать файлы современных версий можете попрощаться, как и с поддержкой и надеждой на фикс багов. Альтернативой является DXF. Несколько менее популярный, но в то же время поддерживаемый всеми САПР, изначально открытый и поэтому, по идее, более распространенный. Поиск библиотек поначалу тоже обескураживает конкретно для Java нет ни одного живого проекта, везде та же картина последние релизы 5 летней давности, заброшенные репозитории, грустно глядящие в вечность последние новости, полные неоправдавшегося оптимима и обещаний. Но сам по себе формат в отличие от DWG не так активно развивается, поэтому даже довольно старой библиотекой вполне можно открыть актуальные чертежи. В итоге была выбрана библиотека Kabeja, последний релиз которой был в 2. С помощью идущего в комплекте сэмпла конвертация DXF в SVG было проверено что все актуальные файлы чертежей корректно открываются, после чего я приступил к импорту. Чертежи, проектируемые в Автокаде обычно имеют формат AutoCAD DXF или AutoCAD DWG. Процесс конвертации файлов Автокада в Компасе. Формат AutoCAD DXFDWG, вероятно, является наиболее популярным в качестве обменного среди геодезистов, архитекторов и проектантов, особенно. DXF и DXB это два типа файлов обмена данными чертежей, с помощью которых можно переносить данные между различными приложениями. Слегка правда насторожил меня один комментарий к вопросу про парсинг DXF от некоего CAD гуру на Stackoverflow что, мол, DXF выглядит простым но на деле ты запаришься с ним работать. Слои. DXF чертеж содержит в себе набор слоев layer и блоков block. Там есть и другие сущности, но для того чтобы выдрать координаты геометрии в простейшем случае они не нужны. Со слоями все очевидно, работают они так же как и в каком нибудь Photoshop. Слои можно включать выключать и можно задавать дефолтные параметры графики для слоя то есть например все линии по умолчанию на данном слое будут иметь такую то толщину. Поскольку моей задачей была только выжимка координат, вопросами отображения я не занимался. Окей, все кажется просто бежим по списку слоев, для каждого слоя по списку объектов, преобразуем координаты. Впрочем уже тут я наступил на первые грабли набор слоев который вы видите в CAD и который есть в файле это не одно и то же. Я себе голову сломал, почему у меня вдруг пропадали куски дорог. В Nano. CAD они есть, в моем экспорте нет. Полез в отладчик их и в возвращаемых Kabeja структурах нет. Зато если проэкспортировать файл целиком их семплом они есть. В общем выяснилось что один слой из редактора в файле может представляться несколькими слоями, с именами вида layer. Name, layer. Name 1. Зачем это сделано и откуда оно берется черт его знает, но факт поиск на точное совпадение имени слоя на который намекает даже структура кода библиотеки, хранящая слои в Map с ключом именем не работает. Блоки. Блоки представляют собой шаблоны, которые единожды нарисовав можно многократно вставлять. При этом изменение базового блока изменит и все его вставки. Еще круче то, что блок может содержать в себе объекты с нескольких слоев. При этом вставка тоже принадлежит какому то слою. При этом блок может содержать в себе вставки других блоков. Бланк Акта Испытание Кран Балки. То есть можно сделать блоки секция дома, затем составить из них блок дом, который затем несколько раз вставить на карту. При этом итоговый объект будет иметь несколько слоев отдельно заливка, отдельно контуры, отдельно специальные пометки, так же как исходные блоки. Все это очень круто с точки зрения пользователя, но добавляет работы программисту. Более того, блок может вставляться не просто разово, а многократно в виде прямоугольной матрицы. Для этого у объекта вставки есть параметры с количеством рядов, столбцов и с расстоянием между ними. В итоге пока что код обработки вставки выглядит как то так for int row 0 row lt insert. Rows row. В итоге получаем реальное положение дома на плане. Feature inserted clone. Feature. With. Transformf, transform. То есть поочередно обрабатывая блоки можно наткнуться в нем на вставку из другого блока, который еще не был обработан. Честно говоря не знаю, можно ли умудриться сделать цикл и что в таком случае будет. Линии Напомню, что моя задача преобразовать DXF в Geo. JSON, который из всех видов геометрии признает лишь ломаную и многоугольник, никаких дуг и кривых. DXF поддерживает кучу разных вариантов линий Аж 2 типа ломаных Polyline и LWPolyline. В моем случае простых 2д чертежей разницы между ними никакой Дуги, причем аж двух видов эллиптические и круговые. К счастью в классах Kabeja уже есть готовые методы для получения координат точек на них, так что преобразовать дугу в ломаную с нужной точностью несложно. Сплайны опять же Kabeja сама умеет их преобразовывать в Polyline Просто линейные отрезки Казалось бы все просто, но нет. Даже простой на первый взгляд тип Polyline может использоваться для отображения кривых второго порядка а не просто ломаных. Для этого у вершины может быть задан параметр bulge. Если он указан то две вершины соединяются не прямой линией, а дугой окружности, проходящей через эти вершины и центр которой можно выразить через них и этот параметр. Вот такой вот код позволяет определить центр окружности private Point get. Center. By. Vertices. And. BulgeDXFVertex a, DXFVertex b, double bulge. Так как в генпланах такие дуги обычно используют для закруглений на углах перекрестков, я мог на них вполне забить разница с точки зрения симуляции невелика.