Аналитика

Чому не використати Правка-Совместить с соседними? Помітити усі об'єкти та сумістити.

Це все добре, але воно таке там робить!!!
Чуть пізніше скину файлик.

Міцного здоров'я всім!

Дякую розробникам за відповідь, а користувачам за підтримку.

Щодо "ПРАВКА-Совместить с соседними" надсилаю файл, спробуйте. Можливо ми щось не так робимо.

Приложите тогда еще исправленный файл для сравнения и обведите кружком, где возникают проблемы при использовании команды Правка>Совместить с соседними. Выкладывайте файл в DMF формате.

Міцного здоров'я!

Вирішив прикласти відео, на ньому чітко видно зміну конфігурації XML-обмеження, при застосуванні "Правка-Совместить с соседними".

Дякую.

Також й dmf-файл.

Команда Правка>Совместить с соседними в качестве допуска использует настройку Сервис>Настройки>Правка>Точность карты на бумаге. Значение этого допуска пересчитывается в метры на местности с учетом масштаба карты.

Дякую за відповідь, цей аспект був для нас невідомий. Та біда у тому, що після використання "Правка-совместить с соседними" у шар ХМL-Ділянка примусово додаються точки перетинів дочірніх об'єктів. Тобто була ХМL-Ділянка з чотирьох точок, стала з 4+n точок. Що категорично не підходить для вирішення проблеми.

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

Дякую Вам красно Bondarets Alexander за Ваше терпіння, а саме головне - за бажання допомогти.

Так, питання піднімав особисто Ваш покірний дописувач. Того разу отримано вичерпну відповідь від Вас же. viewtopic.php?p=15607#15607
Цілком розумію, що без наявних точок - цілісність топології забезпечити не є можливим.
Та все ж необхідне рішення, що забезпечить альтернативу ручному процесу "Выравнивание-Перемещать только ближайшие точки" та послідовного вказування створів....
ХМL зберігає координати з точністю до трьох знаків після коми. При повторному відкриванні щойно збереженого ХМL (при наявності ствОрових точок) відповідно цілісність топології вже порушено - і, як наслідок, втрата дочірніх елементів при перезбереженні вищезазначеного XML гарантована.
Рішення проблеми, шляхом додавання точок у ділянку - не припустиме, оскільки є не доцільним та таким, що захаращує кадастровий план (через додавання "лишніх" промірів та збільшення каталогу координат). На прикладі того файлу, що Вам пересилав, це досить яскраво ілюструється.

Отже, вихід бачу (особисто,та скоріше за все досить суб'єктивно) у автоматизації процесу "Выравнивание-Перемещать только ближайшие точки" при значенні "Точность координат" = "Макс". Принаймні тоді, всі дочірні елементи лишаються на місці. Альтернативи ми з Вами, здається, перебрали всі?

Чтобы пользоваться командой Правка - Совместить с соседями необязательн опомечать сразу все объекты, помечать нужно только те, которые подлежат изменению. Остальные, имеющие статус слоя Правка служат в качестве линий к которым будут пристыковываться помеченные.

Например:
1. Мы открываем XML в котором нет створных на участке. Допустим просто хотим изменить что-то в Инфо. Естественно, что ошибки округления приводят к тому, что угодия "выпадают" из участка.
2. Скрываем все слои, которые не хотим нарушить, например, обмеження.
3. Помечаем только угодия. Выполняем совмещение с соседями (т.е. с участком, ну и между собой, разумеется, но с этим и так все должно быть в порядке, поэтому мы ничего не нарушим).
4. Скрываем угодия, оюмеження включаем. Опять совмещаем. Проблема может быть только с пересекающимися обмеженнями. Тут уж придется совмещать по одному в новом файле.
5. Все слои возвращаем в статус Правка. проверяемся в Списке. Сохраняем.

Ось і альтернатива знайшлася. Що ж, цілком прийнятна. Трохи більше часу займає поштучне копіювання та підтягування обмежень, та вже ж не руками. Нажаль вони (обмеження) як правило взаємоперетинаються (оскільки комунікації підводяться від дороги). Чи є спосіб, через скрипт, перевірити на цю ознаку (перетину один із одним) шар обмеження? Це дещо пришвидшить роботу основного скрипту, бо 7 000 файлів перебирав майже дві години, а їх ще є, перепрошую, достобіса.

П.С. Потужнішу залізяку керівництво поки не купить.

Панове Bondarets Alexander та Dmitriy Fedorov красно й міцно дякую вам за допомогу.

Прохання до розробників, переробіть функцію в скриптах, яка підтягує dmt-шаблони:

Треба, щоб вона підтягувала шаблон не по порядковому номеру, а по якійсь іншій прив'язці. А то, коли закидую в Digitals новий шаблон якийсь, чи видаляю старий, то в скрипті автоматично міняється на попередній чи наступний. Приходиться при кожній зміні кількості dmt шаблонів заходити у всі скрипти і міняти ці строки. Це трохи напрягає.

Вже не треба. Знайшов - @ExecuteDocument DMTTemplateName

Міцного здоров'я всім!

Панове розробники! Дай Боже вам творчої наснаги й успіхів у вашій нелегкій праці!
Прошу допомоги у наступному. Маючи довгий текстовий рядок, на зразок "804,11000,Нська область,Нський р-н,м.Місто,вул. Вулиця,1,2,3" (у якому, без жодних труднощів, впізнається дескриптор AU) - маю потребу взяти, наприклад, наступні частини: 1) "804,11000,Нська область"; 2)"Нський р-н,м.Місто,вул. Вулиця" ... тощо.
За допомогою функції @StringPart це можливо робити поштучно, потім з'єднуючи потрібні теги у ціле значення. Експериментував із функцією @Calc, а саме з її аргументами Length,Pos,Copy - не досяг результату, оскільки кількість символів у рядку не є сталою величиною.
Безпосередньо прохання:
Функція @StringGetPart з аргументами Begin Count Delimiter String, котра б повертала цілим рядком "Нська область,Нський р-н,м.Місто,вул. Вулиця,1,2,3" після вказання @StringGetPart 3 7 , "$String" .
Можливо є й альтернативне рішення.
Дякую.

Перепрошую, доки дістався додому - осяяла мене ще одна думка, можливо підійти до вичленення потрібних частинок рядка (тегів) на кшталт як реалізований вибір сторінок для друку? Тобто, взяти теги з N до N+1 у форматі 2-5, або взяти теги 6,9,4,2. При цьому - не "з'їдати" розподілювач (кому), як це робить @Concat.

Ще раз дякую за вашу увагу, панове розробники.

Добрий день! Питання до розробників програми, якщо тут ще такі є.

Чому функції @StringPart та @StringPartCount неправильно працюють із роздільником "|"?
Наприклад, пишу:



В результаті отримую "Іванов"

А коли пишу ось так:



то отримую результат:
"Іванов
Петров
Степанов
Василенко"

Це усе б не дуже суттєво, але є одна величезна проблема. Функція ж @StringPartCount працює навпаки.

Коли пишу:



отримую в результаті "1"

При



отримую "4"

Виправте, будь-ласка, щоб воно співпадало. А то неможливо працювати з цими функціями в купі.

Проблема в тому, що символ "|" використовується в редакторі скриптів, як заміна для символу переносу строк.
Вносити зміни в програму недоцільно, щоб не "зламати" ті скрипти, які використовують цю можливість

Тому пропоную варіант вирішення:
;отримуємо символ "Vertical bar"
$VBar=@Calc Char(124)
$VBar=@DequoteText $VBar
;використовуємо його
$NM=Іванов$VBarПетров$VBarСтепанов$VBarВасиленко
$result=@StringPart 1$VBar$NM
@Dialog.Message $result