Круто. Правда я не зрозумів, як воно працює. Взагалі що означають функції String(x) Char(x) Ascii(s) Eval(f) ? Буду вдячний, якщо скажете, де можна знайти їх опис.
Про деякі функції там написано і я цим давно користуюся, але про вище згадані практично опису немає. Очевидно для цього треба вже бути програмістом в Delfi. І шукати, що означає boolean (1/0): Logic(x) numeric: Numeric(s) string: String(x) char: Char(x) integer: Ascii(s)
Чом зразу в Delphi, можна й тут 
Зрозумів. Дякую.
Правда, при роботі цього скрипту виникла одна проблемка. Якщо у файлі замість коду 100 стоїть 200 чи 300, або взагалі вже видалений код, тоді функція летить у безмежність нашого неосяжного всесвіту, забираючи з собою ресурси моєї оперативки)). Як би поставити на такі випадки обмеження?
В циклі поставте лічильник, обмеження його числом,.припустимо 100. Якщо 100 - рядка не знайдено, вихід зі скрипта.
Обробка цих подій додана розробниками у версії 15.10.14. Чемно дякую.
Міцного здоров’я всім!
Повертаючись до проблеми ствОрових точок, та втрати дочірніх елементів XML-файлу XML - #238 від user228 хотів би висловити наступне прохання до розробників.
На даний момент часу користуємось “Выравнивание”->“Перемещать только ближайшие точки”, не забуваючи виставити “Свойства карты”->“Точность координат”->“Макс”. Та в ручному режимі послідовно вказуючи створи між точками шару XML-Ділянки.
Прохання полягає в тому, аби автоматизувати дану процедуру через застосування скриптів. Тобто, нова функція (нехай OrderingChildElements ObjectName Accuracy) починаючи з початкової точки об’єкту послідовно проводило операції “Выравнивание”->“Перемещать только ближайшие точки” із заданою точністю, наприклад 5 мм. (Точність - максимальне значення відхилення від створу).
Дякую за увагу.
UPD. Панове розробники, напишіть, чи хоча б будете пробувати вирішити вищеописане прохання. Оскільки виникає потреба певної масової обробки XML, шляхом послідовного відкриття та перезбереження файлів.
Аналогічна проблема, коли буде вирішення?
Дане питання постійно актуальне в Digitals. По реакції розробників на це повідомлення, видно, що або форум не читають, або не можуть це зробити.
Щось таке)
Дістало переробляти xml-файли (наприклад, лісгосп) підтягуючи до межі декілька сотень угідь!
Чому не використати Правка-Совместить с соседними? Помітити усі об’єкти та сумістити.
Це все добре, але воно таке там робить!!!
Чуть пізніше скину файлик.
Міцного здоров’я всім!
Дякую розробникам за відповідь, а користувачам за підтримку.
Щодо “ПРАВКА-Совместить с соседними” надсилаю файл, спробуйте. Можливо ми щось не так робимо.
Приложите тогда еще исправленный файл для сравнения и обведите кружком, где возникают проблемы при использовании команды Правка>Совместить с соседними. Выкладывайте файл в DMF формате.
Міцного здоров’я!
Вирішив прикласти відео, на ньому чітко видно зміну конфігурації XML-обмеження, при застосуванні “Правка-Совместить с соседними”.
Дякую.
Також й dmf-файл.
Команда Правка>Совместить с соседними в качестве допуска использует настройку Сервис>Настройки>Правка>Точность карты на бумаге. Значение этого допуска пересчитывается в метры на местности с учетом масштаба карты.
Дякую за відповідь, цей аспект був для нас невідомий. Та біда у тому, що після використання “Правка-совместить с соседними” у шар ХМL-Ділянка примусово додаються точки перетинів дочірніх об’єктів. Тобто була ХМL-Ділянка з чотирьох точок, стала з 4+n точок. Що категорично не підходить для вирішення проблеми.
Вопрос добавления лишних точек в контуры при их совмещении уже где-то на форуме обсуждался. С математической точки зрения эти точки обязательны, иначе при округлении координат точки сползут с отрезков прямых. Поэтому если контуры совпадают, они обязательно должны совпадать точка в точку.
Дякую Вам красно Bondarets Alexander за Ваше терпіння, а саме головне - за бажання допомогти.
Так, питання піднімав особисто Ваш покірний дописувач. Того разу отримано вичерпну відповідь від Вас же. XML - #240 від Bondarets_Alexander
Цілком розумію, що без наявних точок - цілісність топології забезпечити не є можливим.
Та все ж необхідне рішення, що забезпечить альтернативу ручному процесу “Выравнивание-Перемещать только ближайшие точки” та послідовного вказування створів…
ХМL зберігає координати з точністю до трьох знаків після коми. При повторному відкриванні щойно збереженого ХМL (при наявності ствОрових точок) відповідно цілісність топології вже порушено - і, як наслідок, втрата дочірніх елементів при перезбереженні вищезазначеного XML гарантована.
Рішення проблеми, шляхом додавання точок у ділянку - не припустиме, оскільки є не доцільним та таким, що захаращує кадастровий план (через додавання “лишніх” промірів та збільшення каталогу координат). На прикладі того файлу, що Вам пересилав, це досить яскраво ілюструється.
Отже, вихід бачу (особисто,та скоріше за все досить суб’єктивно) у автоматизації процесу “Выравнивание-Перемещать только ближайшие точки” при значенні “Точность координат” = “Макс”. Принаймні тоді, всі дочірні елементи лишаються на місці. Альтернативи ми з Вами, здається, перебрали всі?
Чтобы пользоваться командой Правка - Совместить с соседями необязательн опомечать сразу все объекты, помечать нужно только те, которые подлежат изменению. Остальные, имеющие статус слоя Правка служат в качестве линий к которым будут пристыковываться помеченные.
Например:
- Мы открываем XML в котором нет створных на участке. Допустим просто хотим изменить что-то в Инфо. Естественно, что ошибки округления приводят к тому, что угодия “выпадают” из участка.
- Скрываем все слои, которые не хотим нарушить, например, обмеження.
- Помечаем только угодия. Выполняем совмещение с соседями (т.е. с участком, ну и между собой, разумеется, но с этим и так все должно быть в порядке, поэтому мы ничего не нарушим).
- Скрываем угодия, оюмеження включаем. Опять совмещаем. Проблема может быть только с пересекающимися обмеженнями. Тут уж придется совмещать по одному в новом файле.
- Все слои возвращаем в статус Правка. проверяемся в Списке. Сохраняем.