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

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

Это не так. Такие сложные модули никогда не разрабатываются без многочисленных правок по замечаниям пользователей.
Вы просто не там искали - модуль разрабатывался более 10 лет назад, правки вносились по замечаниям до 2015-2016гг. Поэтому обсуждение было на старом форуме. Именно отладке после увязки посвящено две темы, т.к. в одну не уместилось:
http://lesis.forum24.ru/?1-4-0-00000010-000-0-0
http://lesis.forum24.ru/?1-4-0-00000062-000-0-0
По линейникам там очень много информации, в т.ч. есть и замечания от пользователей и исправления. Вот навскидку буквально за пару минут нашел несколько замечаний и вопросов по линейникам, все от частных лесоустроителей:
http://lesis.forum24.ru/?1-4-1710999517 … 0001-0#022
http://lesis.forum24.ru/?1-4-1711000172 … 00-0-0#013
http://lesis.forum24.ru/?1-4-1711000172 … -0#014.001
Вы в этих темах  тоже участвовали, забыли, видимо.

Это не измерения линий. Это прямой вывод длины линии в качестве метки. Длина линий в БД Тополя - действительное число, поэтому после запятой идут все знаки в пределах отведенной под это системой памяти. Для вывода понятных значений нужно в качестве метки выводить вычисленное (округленное) значение, т.к. записать округленное значение во внутреннюю базу невозможно - дырки будут размером 0.000...001 м.

Выложена версия 899. Протечек просек на деморегионе у нас уже не было.

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

У кого нет номеров линейных выделов - Увязку также тщательно тестируйте!!!

БЕЗ ТЕСТИРОВАНИЯ В ПРОИЗВОДСТВО НЕ ЗАПУСКАТЬ!

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

Нет. Увязка и связывание линейников делаются как раз на блоках, где линии с кодами объектов, которые подлежат описанию в таксации уже есть. Но там может не быть номеров. А могут и быть. Также может не быть базы данных при линейниках. В обоих случаях инструмент можно применять как для создания БД в линейных, так и для их изменения. Создавать она будет только там где нет БД. Если ты создавал БД с нашими именами ключевых полей, то должна подхватить эту базу. "Лишние поля" она скорее всего игнорирует.

Здесь не понял. Видимо опять речь не об объектах, а о БД при них. Например, в таксации есть "дорога". В блоке в этом квартале должна быть линия с кодом "дорога". Иначе программа выдаст в протокол, что для "дороги" в этом квартале не найдена подходящая линия. И ее нужно создать. Или удалить выдел "дорога" в таксации если таксатор ошибся. Если линия есть, но БД пустая, то БД должна быть программой создана. Если она есть и ключевые поля совпадают - должна их принять.

Есть, она просто переименована и немного модифицирована. "Связать таксацию линейных выделов с картой"  ищет в каждом квартале все линейные выделы в таксации и по "Настройкам линейных" ищет соответствующие коды в блоке. Если нашла - "соединяет" их, т.е. ставит в соответствующей линии блока номер выдел из таксации. Если не находит или параметры сильно отличаются (% указан в "Настройки - для линейных") то она выводит инфу в протокол и исполнитель должен построчно просмотреть протокол и устранить все расхождения, т.к. понятно, что по таксации программа сама нарисовать линию не сможет и связать с линейным объектом, который не прописан в "Настройках линейных" тоже. Это возможно, например, в тех случаях, когда один вид линейника в таксации оцифрован разными кодами линий в блоке, а в настройках прописан только один и наоборот. Такие места нужно находить, рабираться и вносить поправки в "Настройки линейных". Затем повторять "Связать..."

Отредактировано Грешнов (05.06.2024 17:31:41)

Ну... что тут сказать... Работа любит... "особо одаренных людей"... Все обсуждалось на форуме. Было объявлено  в "версиях программы". Описано в доках. Кто хотел - использовал.

Эта функция встроена в "Связать таксацию линейных выделов с картой". Выше кратко обрисовал как работает.

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

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

И не требуются никакие долгие рассуждения... видеофильмы... даже картинки, т.к. тексты ошибок прекрасно копируются на активном окне сообщения через Ctrl-C.
Разработчик в таком виде понимает с полуслова без "допросов с пристрастием". ))
Я сейчас продолжаю тестировать, если наткнусь на твою ситуацию - решим и ее.

Да. И пока не пробуйте "Стереть - Сохранить...", там точно есть проблема, Д.А. ее сейчас обрабатывает и по результатам выложим обновление.

Спасибо, последовательность действий теперь вполне понятна даже если бы не было картинок. Посмотрим еще раз, хотя Дмитрий Александрович уже ищет места, где теоретически возможно задвоение.

Выложена, пробуйте.

Я не знаю как поведет БД с задвоенными полями, не проверил. Если будет выходить в ошибку - отпишись или удали БД таблиц блока из дерева объектов - по ПКМ "Изменить структуру БД - Удалить все". Поскольку "Стереть все линейники из таблицы" пришлось убрать - на данный момент слишком опасная для данных таксации функция. Осталось только повыдельное удаление. Пиши если все же нужна и для чего.

Выложена 901 версия.
Подробности тут

Спасибо, изучим что влияет в этих случаях.

Сталкивался с таким визуальным эффектом пару раз, пока не понял в результате чего. Посмотрим еще раз.

Пока есть только технологическое решение - сначала все увязать, затем исправить вручную и больше увязку ("Связать...") не запускать. Насколько возможно учесть такие ситуации автоматически без потерь производительности решать Дмитрию Александровичу, т.к. используемое ныне решение "принадлежности просеки кварталу с бОльшим номером" было принято как раз, чтобы сократить затраты времени на пространственный анализ положения каждого отрезка просеки относительно соседних выделов. Учитывая, что у нас были пользователи, которые присылали нам свои данные с количеством выделов до 500 тысяч на лесничество, это могут быть очень большие временные потери. Подумаем.
Хотя если пользоваться логикой, то если мы допускаем просеки под 45 градусов... номера кварталов справа-выше меньшей величины... то почему бы не допустить, что в каких то местах и просека может принадлежать северо-западному кварталу!? )) Это было бы хорошим тестом на уровень интеллекта тех, кто пишет Вам нормативы. Впрочем, возможно это уже есть в НПА если там по данному вопросу присутствует любимое выражение авторов НПА - "как правило".
И еще нужно учесть, что если Вы будете "полигонизировать" все просеки и переходите на 0.001м точность, то увязка станет разовой операцией. Мерять все до 0.001, а потом округлять до целых чисел - дурдом полный. )))

Кнопка "Добавить" будет доступна после заполнения всех полей формы. Учитывая, что это инструмент увязки, т.е. не полноценное средство синхронного редактирования, нужно, чтобы объекты существовали и были идентифицированы в карте. Иначе при сохранении возникнет зависание. Д.А. посмотрит как его обойти, но пока так.

"У нас" это еще не у всех. Поэтому нам приходится учитывать все варианты. БД приходят самые разные - в отрасли умерла стандартизация.

Не понял вопрос. Где отключить? Как это связано с округлением?

Перейти в "Увязка - Закладка Выдел" в этот квартал, ткнуть там в любой удобный выдел и потом "Меню - Линейные выделы - Добавить линейный выдел в текущий квартал". В этом случае как раз появится текущий квартал:

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