Привязка плана в ПДФ к координатам

Добрый день! Подскажите как можно план из проекта в ПДФ привязать к координатам плана в DWG файле. Пробовал использовать команду "выровнять", по либо план не масштабируется. если привязываться к 3 точкам, либо ложиться с отклонением, если к 2. Прилагаю ссылку на архив с файлами: ПОС - план из ПДФ. Чертеж 1 - Уже сидит в координатах.
https://disk.yandex.ru/d/Cth-GihuRh3lDg

 

Можете скинуть исходник ПДФ?

 

Да, вот он

 

Как то привязал по 4-ем точкам.

 

Спасибо большое за помощь! Но вот здесь проблема: Когда из ГП копирю трупопроводи вставляю в ваш файл он ложится в другое место. На скрине слева от дороги ваш, справа тот, что вставил из ГП. И подскажите как вы сделали привязку по 4 точкам
Alexeynico,
Alexeynico,

 

Собственно красный блок из трёх линий и семи кругов остался.

Рассказываю:

На чертежах "Чертеж_1.dwg" и "1ПОС_из_ПДФ.dwg" нашёл 4 хорошо различимых угла контуров. Выделил их красными кругами.
Попарно объединил эти точки двумя (горизонтальными) линиями. Центры этих линий выделил красными кругами.
Соединил центры линий красной центральной (вертикальной) линией. Выделил середину линии красным кругом.
На чертеже "Чертеж_1.dwg" скопировал данную "конструкцию" по центру центрального круга и вставил как блок туда же.
Скопировал полученный блок и вставил в "1ПОС_из_ПДФ.dwg" с исходными координатами.
Подтащил исходное содержимое "1ПОС_из_ПДФ.dwg" к вставленному блоку и увеличил в 20 раз.
Использовал команду _ALIGN для наложения исходного содержимого на блок с "Чертеж_1.dwg" по двум точкам - концам центральной (вертикальной) линии с указанием масштабировать [Да].

Кругами же я выделял все середины линий для удобства их "цепляния" с помощью указания в привязке "Привязка к центру".

PS: Так то можно и по 8-ми, и по 16-ти точкам привязку сделать, попарно объединяя ближайшие друг к другу точки линиями и соединяя центры этих линий до тех пор пока не останется одна центральная линия.

 

О, спасибо большое! Сам не догадался бы) А с несовпадением Трубы на на ГП и на ПДФе все оказалось просто. Ошибка в размерах, несоответствие ГП с рабочей документацией. Так и строим)

 

С lisp-ом от @sokkol : PointStar.lsp рецепт становится значительно проще и нет необходимости в том, чтобы контурных точек было не просто чётное количество, а 2^N.
Рецепт с lisp-ом: Визуально делим набор точек на две половины. Для каждой половины lisp-ом находим среднюю точку (центр). Делаем это на обоих чертежах одинаковым образом. Соединяем средние точки (центры) линией. По полученной линии производим _ALIGN.

 

Кроме верного советованного выше _ALIGN:
1. Команда Map/Civil для трансформирования по точкам - ADERSHEET.
2. Проверенный lisp helmert.lsp - приложил.

 

Туплю наверное. Привык, что Хельмерт ворочает по трём осям. А в этом лиспе пользуются только X и Y. Есть ещё какое то преобразование Хельмерта, кроме {X,Y,Z}' = s*{R}*{X,Y,Z}+{T}?

PS: Так то это наверное всё-таки конформное преобразование первой степени и должно обзываться C:conformal1p().

 

Мопед не мой.
Этот лисп для растров, т.е. третья координата не нужна.

 

Нужна... Не нужна... Хельмерт без третьей не работает. Даже ежели 0, всё равно должно присутствовать. Иначе и не указанное преобразование вовсе.

 

По сути - нет. Это просто другой способ того, что раньше делалось переносом и поворотом. Но (как и в исходном варианте) никаких методов, средств и методик нахождения этих сдвигов и угла поворота не представлено.

PS: Уже давал ссылку на лисп от доброго человека, позволяющий находить среднюю точку. Но вот как реализовать удобным способом нахождение средневзвешанной точки (когда некоторые точки - базовые, а остальные - вспомогательные, различной степени паршивости)? На ум приходит только дублирование "надёжных" точек. Но это никак визуально не отображается (дубль накладывается на исходную точку), поэтому можно встрять с (внезапно!) разным количеством дублей.

 

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

 

Не спорю. Только где эти самые простые средства-инструменты?

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

 

Накидал по быстрому, команда CenterFromCircles. Строит блок из линий от кругов к вычисленному центру, вес зависит от радиуса.

 

Не понимаю я как пользоваться dll, в отличие от лиспа.
Но! Есть 2 но! Независимо от понимания / непонимания:
1) В случае простых инструментов "чёрный ящик" и "вещь в себе" - ненужны.
2) Независимо от способа реализации должно явным образом читаться, как происходит назначение веса и суммирование.

 

Вот собственно реализация, средняя координата считается как сумма координат центров кругов умноженных на их радиус и деленых на сумму всех радиусов.

Ну а уж как запускать dll это к гуглу или почти в любую тему в разделе программ форума, там половина в виде dll и в каждой написано как запускать.

Ну если уж такая принципиальность на лиспе, то ждите того, кто на нем реализует)

 

Так и будет.

PS: Радиус как вес негож - отсутствует физичность (физическая интерпретация).

 

А чем принципиально радиус от диаметра или площади отличается? Я бы еще понял если бы эллипсы использовались (кстати, ничего не мешает их использовать), а для круга то это 3 взаимосвязанных параметра.