Не зачем, а почему. В лесоустройстве использовались оба подхода еще во времена СССР. Причем в разных предприятиях по-разному.
Корни "северо-западного" варианта зиждятся в "ОСТ 56-44 80 Знаки натурные лесоустроительные..." (и, кажется, более ранних):
"3.1.2. Квартальные столбы на проезжих просеках должны устанавливаться в стороне от осевой линии просеки в северо-западном углу."
То есть, линия границы просеки проходит между столбами как раз по серверным и западным ее сторонам. Таким образом, площади именно северо-западных просек попадают в квартал, а юго-восточные попадают уже в соседние кварталы.
Однако не все просеки были и есть "проезжие", не все были в виде "прямолинейной полосы шириной 4 метра", да и столбы часто ставились там где полевик смог срубить подходящее дерево на требуемой высоте, т.к. закопать столб в СЗ углу было нереально из-за вечной мерзлоты, скального грунта или вообще отсутствия "ширины" и, соответственно, СЗ угла у пересечения двух линий, отбитых просто затесками на деревьях.
Отсюда родился подход 1/2 ширины просеки (границы), который распространяли и на 4м просеки для единообразия. Кроме того, уменьшался объем аналитики куда относить - все что граничит с кварталом делится пополам. И это легче формализовать.
В конкретном предприятии или на конкретном объекте приживался тот вариант, который встречался чаще. Почему сейчас один остался? В отрасли все как обычно с 1991 года - кто раньше встал пишет инструкцию того и тапки "мысли"... )))
Раньше ни один документ не доходил до стадии утверждения пока не получали заключения от ВСЕХ заинтересованных структур. Сейчас складывается впечатления, что нормативы готовят в очень узком кругу авторов. 
Что производительнее, видимо, тебе виднее, т.к. непосредственно тебе и твоим коллегам предстоит воплощать это в картах. Но мне кажется, что состав работ будет близким - все равно из трех линий одну "убирать" придется. Может и нет разницы - среднюю если отбить по 2м в обе стороны, или одну из крайних если отбить по 4м в обе стороны!?
У меня больше вопросов по категоричности утверждения, что все просеки 4м... Что... реально разрубать все будут? )) Я правда детально инструкцию не читал, может есть где то оговорка по просекам, не имеющим ширины...  Может завтра на свежую голову найду... ))

Прямой ответ в моей цитате на п.3.1.2 ОСТ 56-44 80. Автор соответствующего пункта инструкции считает, что раз столб поставлен в СЗ части перекрестка просек, то просеку нужно откладывать от соответствующей ей линии в одну сторону на 4 метра и относить ее принадлежность к кварталу, расположенному юго-восточнее ее. В общем, как на твоем первом рисунке. О существовании второго подхода он, возможно, не подозревал.

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

Не уверен... ))) И чем больше читаю наши НПА тем меньше уверенности. Они, по-моему, не обсуждаются профессиональным сообществом.

Ну это тоже чистка. Понятно, что я не о ручном тюканьи в каждую линию. Мне кажется если посидеть и подумать то можно что то похожее и для СЗ варианта придумать, пусть и затратнее.
Сергей, я не спорю, что подход "от середины" проще. Просто по опыту прошлых лет вероятность изменения НПА под учет реальной ситуации ничтожна. Я про ошибки  алгебраического характера в расчете сплошных спелых с 94 года регулярно писал и говорил, в т.ч. авторам. Всем пофигу - теперь молчу. ))
Я к тому, что по-любому вариант СЗ уже реально существует на многих объектах и решать эту проблему все равно придется. Давай лучше над этим подумаем.

Тут нужно понимать, что речь идет не о том "как делать всем", а о том как делать при обоих подходах, т.к. есть объекты где считались просеки и по всей окружности кварталов и по северо-западу. Это реальность.
На мой взгляд, то, как делает Сергей Николаевич, можно применить и для варианта северо-запад, но тогда для обоих вариантов придется придумывать как разделять просеки между северо-западом и юго-востоком. И если этот вопрос решим, то тогда его можно применить и к варианту Сергея Николаевича.
Для наглядности:

И мне кажется, что как раз разделение между СЗ и ЮВ можно сделать автоматом.

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


Удалились именно паразитные линии (сравнивал "на просвет"), таким образом, ошибка равна нулю. И полигон создался сразу для всего перекрестия.
Возможно есть и другие варианты использования этого или подобных механизмов - это вопросы технологии, в которые мы не можем слишком углубляться. Тут у тебя больше опыта. Но суть в том, что в БД нужно избавляться от такого мусора "до того".

И, кстати, демообъект нужно, видимо, почистить... или другой вставить. Сейчас нашел там накопившиеся топологические ошибки, даже двойные просеки...

Да, Сергей Николаевич передал нам Вашу нормативку по этому вопросу. Но сначала нужно решить вопрос в принципе. А приспособить его к приоритетам будет проще.

Не совсем. Так как первый вариант предполагается для просек, которые ТЕОРЕТИЧЕСКИ проводились по их центру (2м в обе стороны), а второй вариант - для просек, которые изначально и также ТЕОРЕТИЧЕСКИ проводились по из северо-западным сторонам. Т.е. они одинаковы если каждый из способов применяется к соответствующему им способу учета ранее.
Третий вариант - полный аналог второго, т.к. никаких ЮВ пустот там не будет, т.к. эти линии будут удаляться перед встраиванием в основной блок. А возможно их вовсе не будет если Дмитрий Александрович сможет построить вместо линейного буфера эквидистанту. Пока он только упомянул о такой вероятной возможности, поэтому я этот вариант пока и не упоминал. Точнее это способ реализации второго варианта для тех кто изначально учитывал просеки по их СЗ стороне.
А ПРАКТИЧЕСКИ в графической части это значения вообще не имеет, т.к. при проведении просек на картматериалах физически не возможно достоверно провести просеку по СЗ или по центру, т.к. это за пределами точности работы с исходными данными, которыми располагает (располагал) таксатор в натуре.
Так что, когда Дмитрий Александрович освободится и мы займемся реализацией, то пойдем по пути наименьших затрат для исполнителей с учетом обоих вариантов учета просек. Если это получится сделать то замечательно.

И... поскольку я детально не изучал вашу феерическую инструкцию... я надеюсь, что этот норматив коснется только новых объектов? Или Вам придется переделывать материалы прошлого лесоустройства? Ибо во втором случае Вам придется переувязывать площади на половине территории лесного фонда... И соответственно вносить в ГЛР изменения в установленном законом заморочном порядке... )

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

Выигрыш у кадастровиков, под которых нынешнее лесоустройство "легло". Для лесоустройства главное в линейниках - как раз их "линейность", как мат-основа расчетов затрат на проведение мероприятий в конкретных участках ЛФ вместо устаревших и абстрактных "такс".
Но само лесоустройство было уничтожено когда наши отраслевые "писсатели" уничтожили непрерывное лесоустройство и я уже не знаю как назвать то, что Вы сейчас делаете, но лесоустройством это назвать точно нельзя.
Для нас это сейчас - геморрой на тему "как спасти линейники". Иначе бы мы этой хренью вообще не занимались бы. Детский сад. Средняя группа. Книжки-раскраски. ))))) Нужно лесоустроителей к геодезистам посылать на стажировку, чтобы посмотрели как выглядит профессиональная картография. Может тогда и инструкции внятные Вам писать начнут... )))

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

Нет. Это не вопрос оформления. Это юридически значимый объект. И векторизовать его нужно тем типом линии, которую поставил таксатор в лесу. Где то это будет:

То есть, инструментально снятая граница. То, на что есть или были геожурналы. Границы - это начальный, основополагающий элемент первичного лесоустройства, проводились когда еще не было просек для разделения территории между собственниками... ведомствами... хозяйствующими субъектами. Уровень полномочий на установления и изменение границ всегда был у государства. Эти исторические данные нельзя терять если мы не хотим стать "иванами без родства". Если старая граница, 50 - 70 летней давности - то снятая теодолитом, пропаханная отвальным плугом, с установленными и давно сгнившими или проржавевшими столбиками на курганах в углах поворота. В 80-е и даже в 0-е  я такие еще находил. Если это поздний СССР - могла быть уже буссоль и без курганов. Такие уже не найти обывателю если они не подновлялись. Но такие границы грамотный и ответственные таксатор всегда мог восстановить, если это стояло у него в задании, хотя иногда и приходилось быть для этого Шерлок Холмсами.  И ширину ставили 0.5м - лишь бы прошел геодезист. 
А квартальная просека появлялась уже как вторичный объект, сугубо логистический, обеспечивающий хозяйственные задачи, юридическая значимость которого намного ниже - таксатор мог в целях спрямления, экономии на прорубке, если она шла рядом с дорогой, поменять заросшую просеку на имеющийся линейный объект, отвечающий параметрам просеки для данного разряда лесоустройства.
Просеки становились границами лесничеств, например, после их реорганизации, когда кварталами передавали лес из лесничества в лесничество. В этом случае не было смысла делать из них "границы", но грамотные лесоустроители всегда старались сохранять исходные геоходы (пунктирными линиями как при съемке непроходимых естественных линий) для сохранения преемственности данных.
Так что, вопрос какой линией проводить границы - это вопрос ЛУ совещаний, начпартии и таксатора, но никак не тех кто камерально "полигонизирует" (прости меня, господи...) эти объекты.
И ширину нужно ставить реальную!!! Ту, которую поставил таксатор!  Если 0.5м - то 0.5. Когда государство даст денег на превращение всех просек и границ в 4м - тогда и будете ставить 4м. У этого тоже есть экономическое обоснование. Поставив 4м на просеке в 0.5м Вам придется ставить в мероприятии уже не "расчистку" просек, а разрубку, т.к. это не заросшая просека, а не разрубленная, со стволами по 20-40 см в диаметре. Что кратно дороже для бюджета и малорентабельно для исполнителей.
Когда же Ваши аФтАры НПА думать то начнут???

Посмотрим. Нам придется восстановить Вашу ситуацию, т.к. мы в своих базах уже идентифицировали все линейники 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, а потом округлять до целых чисел - дурдом полный. )))

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

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

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

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

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

Выше я прокомментировал, что на момент разработки модуля:

Мы подумаем как обойти "автомат", а пока могу порекомендовать изначально заложенный принцип: разовое создание линейников - разовая увязка - ручное редактирование конкретных проблем.

Могу лишь повториться - мы не ясновидящие. Нормативно значимая информация на регулярной основе до нас никем не доводится, вами поставляется нам пост-фактум, когда все уже разработано, а сами мы анализировать технические последствия очередных изменений отраслевых НПА уже не можем, т.к. не занимаемся производством. Теоретически такое не делается при разработках. Граница между формированием  изменений во внешнем проекте на основе анализа НПА и собственно ТЗ после 2012г сместилась на вашу территорию. Пишите своевременно о реальных изменениях, требующих корректировки ПО.

Дмитрий Александрович уже восстанавливает утерянное. Выложим в ближайшей версии.