Лесной форум Гринпис

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

А что мы?

За последние несколько лет за счет небольших усилий в преимущественно свободное от работы время (привет, энтузиазм!) появилось очень много "наработок" (данные, лесоустроительная статистика, компоненты программного обеспечения, иногда почти что готовые сервисы), которые могли бы начать менять ландшафт автоматизации в области лесоустройства и работы с лесоустроительными данными после лесоустройства (НЛУ или его "разновидности"). При этом естественное желание начать выводить эти наработки на рынок и монетизировать граничат с большим желанием отдать какую-то часть результатов бесплатно, довольствуясь удовлетворением профессиональных амбиций. Усиленно ищу баланс между необходимостью и желанием зарабатывать (что естественно, с этим как-нибудь справлюсь) и удовлетворением амбиций (сделать что-то полезное просто так). Для второго - необходимы помощники, по сути "соратники по энтузиазму".

Предвижу мешок скепсиса и смешков, на что в качестве ответа у меня "резистанс" 80-го уровня, как говорится.

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

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

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

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

Но есть огромный пласт данных, лежащих в основе автоматизации и лесоустройства и других процессов отраслевых (арендаторских, ОИВовских и т.д.):
- простые справочники (породы... порядка 50-ти штук для базовых потребностей автоматизации отрасли)
- параметрические данные (таблица бонитетов, таблица запасов, таблица возраста спелости, таблица хода роста, сортиментные таблицы и десятки других)
- всевозможные реестры и "таблицы соответствия сущностей" (список лес-в, уч. лес-в, урочищ, их соответствие мун. округам, лесным районам, перечни кварталов, десятки других кейсов)

А также алгоритмов, которые реализуются поверх данных и НСИ: это почти все расчеты, что делаются при лесоустройстве, а также актуализация, логистика, анализ данных..

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

Для многих таких типов данных уже разработана модель хранения (и в виде реляционной модели данных для БД и в виде документной - XML, JSON).

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

Частично набиты:
- перечень урочищ/дач по участковым
- соответствие участковых/урочищ/дач муниципальным районам/лесным районам
- перечень кварталов для участковых/урочищ/дач

Ну и так далее. Привел лишь первые базовые наборы данных. Большую часть данных надо просто открыть для всех с удобным web интерфейсом для поиска, просмотра, скачивания.

Геоданные уже подтянутся к нужным сущностям по мере появления этих открытых геоданных (или уже существующих), как например квартальные сетки, границы участковых лесничеств и так далее (пока что плохо с "инфраструктурой пространственных данных" в России).

Можно назвать это путем к отраслевому "банку" НСИ, приведением в порядок которого отраслевое руководство заниматься не хочет (впрочем вообще ничем оно заниматься не хочет).

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

Это, собственно, об энтузиазме и амбициях "сделать что-то хорошее просто так".

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

Остались ли энтузиасты в отрасли? Для начала нужно хотя бы 2-3 человека. Больше информации - по ходу дискуссии. Если интереса данная идея среди местных читателей не найдет, просто я сам буду делать это неспеша и гораздо медленнее, чем хотелось бы.

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

Более подробный список конкретных задач отдельно напишу, список, безусловно, открыт. За что могу взять сам - это поднятие и поддержание независимого сервера (т.е. не на чьей-то площадке типа Гис-Лаба, а физически арендованная машина по схеме Virtual Private Server или что-нибудь такое), заточенного только на лесоустройство и все, что из него проистекает. Там нужна будет и БД и CMS и прочие сервисы, просто форум - недостаточно. Конечно же скорее всего эта работа должна идти в связке с форестфорумом, поскольку цель - это открытые вспомогательные данные (нормативные, отраслевые) для работы с любой первичной или производной информацией о лесе.

В планах на будущее - открытые алгоритмы расчетов лесосеки и так далее, и открытый обменный формат ЛУ данными (XML). Все это может быть создано на основе отраслевых НСИ , работа над которыми отраслью и чиновниками провалена.

Для первого поста хватит :)

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Идея интересна но не до конца понятна роль личности. Типа у меня есть сортиментные таблицы для северо запада. В эксцеле, и что...? Есть старые данные по лесничеству участковому где проживаю(Л/У в том году прошло, новых данных взять не откуда) чем эта инфа может быть полезна? Я тупо не знаю чем могу быть вам полезен... Вот и весь разговор... к огромному моему сожалению.

_________________
С уважением alek.cotov@yandex.ru

Да, займусь более детальным разъяснением :)

Сразу скажу, что конкретно Вам многие рутинные задачи, которые я предлагаю, могут быть не очень интересны в силу того, что потребуют определенно времени и усидчивости. Т.е. я предполагаю, что это впервую очередь могут быть студенты или достаточно молодые люди, молодые отраслевые специалисты с незамутненным "лесными" стереотипами сознанием, которые могут легко убить несколько вечеров (на волне того самого энтузиазма). Но это совсем не обязательно! :) Участвовать может кто угодно.

Теперь очень конкретно, берем задачу формализации одной из основ "отраслевой НСИ" - административное деление и иерархия уровней (регион - лесничество - участковое лесничество - урочище/дача/часть (опционально) - перечень кварталов - ну а тут уже выдела). Для того, чтобы в какой-бы то ни было (гео)информационной системе работать с повыдельной информацией корректно и наиболее эффективно (с точки зрения автоматизации различных задач) и глобально (это значит в том числе за пределами "локальной однопользовательской системы"), нужно чтобы все повыдельные данные были правильно "посажены" на свой уровень (т.е. выдел "сидит" в квартале, который "сидит" в уч. лес-ве или урочище, урочище также в уч. лесничестве, а уч. лесничество в лесничестве, которое уже "сидит" в регионе).

Как решается такая задача в локальных системах: иерархия объектов строится вручную каждый раз. Нет никакой корреляции между одними и теми же объектами в двух разных локальных системах. Потому что не существует глобально и иерархически организованного перечня всех уровней, уникальной глобальной системы идентификации и так далее. Отсюда в каждой новой системе разработчикам приходится вводить свою собственную систему идентификации для объектов/уровней административного деления в ЛХ... Короче сыр-бор. То же самое что и со справочниками - отсутствие какой-либо стандартизации.

Но вернемся в баранам: мы решаем первую задачу по созданию иерархии уровней административного деления ЛХ (ну не знаю как ее еще назвать по-научному или "по-лесниковскому").

Т.е. нам нужен перечень регионов РФ на первом уровне иерархии. Эти данные простые и уже набиты, кодификации взята "де-факто" общеиспользуемая - так называемые традиционные ГАИшные коды регионов.


Далее у нас идут лесничества. Возьмем Хабаровский край для примера. Лесничеств - 40 штук. Вообще в любом регионе не более чем 99 лесничеств, т.е. нам достаточно взять две цифры для кодификации лесничеств внутри региона. С учетом кода региона получаем следующие уникальные коды для лесничеств Хабаровского края:

Я сейчас не рассматриваю алгоритм нумерации (географический или по алфавиту или по ЛХРу).

Далее то же самое делаем с участковыми лесничествами, для них выделям три цифры (можно две, но подход с тремя уже устаканился, в том числе на "геопортале" РЛИ, только там коды регионов другие):
Т.е. в Аванском лесничестве у нас уч. лесничества:




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

Пример для наглядности:


Т.е. в Ульчском лесничестве квартала сидят напрямую в Воскресенском уч. лесничестве, а в Хорском, в Лазовском - есть уровень урочищ (Часть 1 и Часть 2). В разных урочищах одного и того же участкового лесничества могут быть квартала с одинаковым перечнем номеров.

Таким образом, чтобы сформировать уникальный глобальный идентификатор квартала, нам нужно взять регион, лесничество, участковое лес-во, а также урочище (есть оно или нет - всеравно уровень нужен глобально).

Т.е. Квартал 1 в Воскресенском участковом из примера выше будет иметь базу "273400300" и полный идентификатор квартала будет "273400300001". Т.е. на сами номера квартала в уровне резервируем 3 цифры (1 будет "001", 143 будет "143") и добавляем их к "базе".

В Лазовском "Часть 1" (это уровень урочища) будет иметь идентификатор "273800501", в Часть 2 - "273800502".

Т.е. квартал 331 в Части 2 Лазовского уч. лес-ва будет иметь идентификатор "273800502331".


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

На сами выдела выделены 4 цифры (при этом выдел 22 будет иметь код "0220", где последняя значащая цифра - "на всякий пожарный" зарезервирована). Т.е. полный идентификатор некоего выдела будет "2738005023310220".

Выдел 22 в квартале 331 Части 2 Лазовского участкового лес-ва из Хорского лесничества Хабаровского края.

Вот это является фундаментом , чтобы можно было начинать думать о каких то региональных базах данных, обмене повыдельными данными между системами вплоть до БД консолидирующих произвольный объем повыдельных данных из любого места РФ.

Если все уровни иерархии интегрированы в конкретное ПО, то легко можно работать с "древовидным" интерфейсом вида:


Регионы, лесничества и участковые лесничества полностью организованы, а вот урочища/дачи и перечень кварталов, а также соответствие уч. лесничеств (или их частей) муниципальным районам - надо бы набить в Excel. Нужно просто взять соотв. информацию из ЛХРов, которые в большинстве висят на региональных сайтах.

Вот как в Excel выглядят исходные данные.

Затем эти данные обрабатываются через SQL и отправляются в единую БД НСИ, где уже раскиданы по таблицам реляционной модели данных.

Или урочища:


А вот соответствие муниципальных районов лесным районам (т.е. есть отдельный кодифицированный перечень лесных районов, есть перечень муниципальных районов из ОКТМО, а это соответствие):


А это формализованный приказ о возрастах рубки:

Тут у нас код лесного района, регион, бонитеты, целевое назначение и , собственно, возраст рубки.

Для удобства работы с табличными данными используется Excel в основном. Далее весь контент идет уже в нормализованную БД, откуда я планирую организовать раздачу этих данных через web интерфейс с иерерахическим поиском, просмотром.


Пример , как все это может быть использовано для автоматизации.
Например, приходит у нас выдел "2738005023310220" - Хабаровский, Хорское, Лазовское, Часть 2, кварта 331, выдел 22.

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



Т.е. получаем полную цепочку расчетов, вообщем-то, без необходимости "локально" поднимать "доморощенную" систему НСИ в каком-либо ПО.

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

Роль личности на данном этапе - это вооружиться Excel-ем и взяться за ЛХРы под моим чутким руководством:P


Если все-таки возникнет более широкий интерес, я попробую скоординировать всю работу, раздать шаблоны, инструкции, агрегировать данные от разных людей. А поиск подходящего сервера уже в процессе, как и разработка "механизма" работы с данными (на основе какой-нибудь CMS-ки).
Каждый сможет пользоваться данными, скачивать и держать у себя "на всякий случай".

Я надеюсь и знакомые лесоустроители поддержат это начинание:))

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Мне интересно. "Кидайте" шаблон \"рыбу" таблицы в ексцель на почту. Попробую данные по Новгородской обл набить. Правда до квартала. По выдельно только старые данные по МясноБорскому уч лесничеству. Что будет не понятно спрошу.
Считаю дело стоящее... от верхушки лесников ждать ни чего не приходится, да и пересажают их скоро...

_________________
С уважением alek.cotov@yandex.ru

И ещё... по табличным данным понятно... ну более менее, а с графикой(гео данными) как поступать собираетесь? Что то типа шейпов из под того же кугиса? Или есть более продвинутые решения?

_________________
С уважением alek.cotov@yandex.ru

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

Первейшая задача - это поднять по ЛХРам перечни урочищ/дач и квартала (в нотации "1-10,34,56, 67-78" - мы ее потом преобразуем в нормальный конечный список целых чисел автоматизированно), а также соответствие участковых/урочищ - муниципальным районам.

Задача простая, но нудная. http://wiki.gis-lab.info/w/%D0%9E%D1%82%D0%BA%D1%80%D1%8B%D1%82%D0%BE%D0%B5_%D0%BB%D0%B5%D1%81%D0%BE%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE - это для ускорения поиска ЛХРов, но могут быть много битых ссылок, так как ресурс старый.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Будем двигаться от простейшего базового к продвинутому и менее тривиальному:)

Работу с пространственными данными (в том числе с геометриями сущностей нашей отраслевой модели данных) - нужно будет вести в ГИС, выбор которой - решение конечного пользователя.

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

Какие у нас существуют препятствия на пути построения (чего уж, инфраструктуры пространственных данных лесного хозяйства)? Да до хрена!
- цифровые БД попрятаны в подвалах РЛИ, даже ОИВы имеют максимум таксушки в формате Ворда последнего лесоустройства 90-х годов..
- доступные "спертые с места бывшей работы" кварталки - грубые и неофициальные, в любом случае границы квартала есть смысл всегда получать объединением границ выделов после их уточнения
- непонятная ситуация с секретностью на всевозможную картографию... тема большая, надо обсуждать отдельно, информации противоречивой много - одна из самых мутных вещей в ЛУ. Т.е. публичной карты повыдельной в ближайшее время не построить. Надо разбираться в вопросе

Что мы можем реально делать? Ну,собирать ту же кварталку шейпфайлами и сажать геометрии на правильный уровень иерархии. Т.е. интегрировать в нашу БД и раздавать "посаженные" объекты через тот же web интерфейс - показывать на карте и выдавать для скачивания в разных открытых форматах.

Границы различных прочих объектов - ООПТ и так далее... Есть много таких данных раскиданных по интернету. А вот нормализованной отраслевой НСИ "табличной" - нет:) Надо создавать "табличную" НСИ и сажать на нее геопространственные данные. И раздавать это - в связке. Приводить отраслевой обмен геоданными "к общему знаменателю".

Так что, если у кого валяется повыделка - придержите ее до лучших времен.

Большой объем работы может быть в области оцифровки параметрических данных:
- Таблица бонитетов
- Возраст рубки (сделано)
- Таблица хода роста (ТХР)
- Таблица запасов
- Сортиментная таблица
- Товарная таблица
- Таблица разрядов высот
....

Это региональные данные, в масштабе страны - плохо систематизированные, надо поднимать разные справочники..
Есть несколько платно-бесплатных МДОЛ программ, там вот коллеги уже оцифровали необходимые региональные таблицы сортиментов. Надо и здесь выходить на какой-то общий формат/модель данных.

Если дойдем до этого - перебивать самим заново или вместе со сторонними разработчиками привести их "цифру" в общему формату? Посмотрим.

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

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Где взять ЛХР я знаю. С сайта нашего "управления лесами" возьму. От вас нужна "рыба" таблицы с наименованием столбцов. Как не крути а писать эти наименования придётся не на русском языке. Я конечно могу "обозвать" сам но вам придётся переписывать... зачем лишняя работа. "Киньте" пока запал не пропал:-))))

_________________
С уважением alek.cotov@yandex.ru

Сделал очень базовый шаблон, чтобы начать.
https://drive.google.com/file/d/1e6QJ88iH98i0Xb-hBEA_v2Cx1o-ld6hY/view?usp=sharing

Три вкладки.

Первая вкладка ЛЕСНИЧЕСТВА содержит одновременно лесничества и участковые лесничества региона.
Вторая владка - для урочищ, дач, частей участкового лесничества (если этот уровень есть).
Третья владка - соответствие участкового лесничества/урочища муниципальному району.

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

Однозначность мы можем придать через перечень кварталов, но в ЛХРах перечни кварталов даются именно на участковое лесничество или урочище, а не на соответствие этих объектов чему то еще (муниципальным , например).


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


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

Вот два человека вызвались поковыряться, давайте сделаем Новгородскую и Коми.
Нужны перечни кварталов, перечни урочищ (если есть) и соответствие муниципальным районам (справочник ОКТМО прилагается).


А что мы можем из ЛХРов еще собрать на следующих этапах? Расчетные лесосеки, площади (причем разные) - предлагайте варианты.

Было бы неплохо также собрать нормальную кварталку (и геометрии и атрибуты, как плошадь и так далее), но это уже не из ЛХРов.

Как определимся какие еще показатели из ЛХРов "оцифруем" я подтяну структуру Excel-я (и соотв. структуру модели данных для БД, куда вся информация будет помещена для централизованной раздачи).

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

https://share.getcloudapp.com/jkuJy4by

Накидал прототип web интерфейса за вечер для работы с иерархией объектов. Вся информация уже будет цепляться к участковому/урочищу, в дальнейшем можно будет задействовать уровень кварталов (особенно если удасться насобирать каких-нибудь полезных данных вроде кварталок на целые регионы).

Как только нужный уровень выбран, справа за кучей разных табов будет интерфейс дял просмотра общей и ЛХРовской информации, если будет геометрия объекта - просмотр на карте, линки для скачивания информации в разных форматах цифровых, а также более продвинутый функционал, возможно какие-нибудь расчеты.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

А откуда Вы взяли это соответствие? Из Приказа МПР? А если в одном муниципальном районе не один лесной район? А лесные зоны Вы никак не учитываете? И зачем Вам такой справочник соответствия лесного района муниципальному?
А если выдела в дальнейшем будут делиться? А квартала (урочища, дачи и т.п.) будут переезжать из одного из одного лесничества (участкового) в другое? Или о динамике пока не думаем?
Коды для субъектов у Вас ГАИ-шные? При этом коды муниципальных образований у Вас Росреестра?

1) Лесные зоны и лесные районы набиты и учтены.


нумерация своя, потому что отраслевой кодификации нет

2) Лесной район - в муниципальный, потому, что первичная привязка возрастов рубок идет к комбинации лесного района и муниципального района (а не лесничеств или участковых лесничеств). Приказ о возрасте рубок. Его "оцифровывали" как он есть - т.е. в привязке к муниципальным.

Далее нам как бы нужно знать однозначный переход от участкового лесничества или урочища к муниципальному району, и там где это один-к-одному - мы знаем из ЛХРа однозначно. А где на участковое или урочище идет два муниципальных района (или больше) тут у нас , к сожалению, неоднозначность (временная), посколько перечня кварталов в ЛХР не дается, какие квартала в каком муниципальном. Просто придется привязывать несколько муниципальных к участковому(или урочищу), в этом случае пока не будет известно точного перечня кварталов - автоматизированные вычисления пока на таких объектах будут требовать ручного "доуказания" (на уровне квартала или выдела), в каком муниципальном районе тот расположен. Но кол-во таких случаев невелико, может процентов 5-10 максимум.

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

Короче, неоднозначность у нас как между лесничествами и муниципальными районами, так и между лесными районами и муниципальными районами.
К сожалению, ЛХРы точного перечня кварталов не дают, это надо будет со временем каким-то образом уточнять. Собственно пространственные границы и урочища и участкового могут быть "отнаследованы" пространственно с уровня кварталов (которые в свою очередь получаются объединением геометрий выделов). Поэтому перечень кварталов - где кто в каком районе лежит - необходим. Именно как перечень.
Тут мы забегаем слишком далеко на данном этапе, эти неоднозначности и "пробелы" будут потихоньку устраняться.


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

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

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

Собственно сейчас идет внесение только перечня кварталов на уровне участкового или урочища. Сами квартала (с геометриями) как объекты удут по мере необходимости создаваться (с геометрией или без, с другими атрибутами). Т.е. прямо сейчас создаются (набиваются) 4 уровня (регион - лесничество - участковое лесничество - урочище/дача).


Да, можно было позаимствовать первые две цифры из ОКТМО для регионов. Я за полчаса все Excel-и могу перевести в новую нотацию за счет автоматизации работы с Excel-ями (из них вся загрузка в БД управляется скриптами и затем SQL в БД). Но взяты гаишные коды, как простое и привычное и широкоиспользуемое.

Сильного противоречия не вижу, было бы неплохо, если бы РЛХ сам как-то это стандартизировал. У него же (в том же геопортале) вообще своя кодификация была (не гаишные и не ОКТМО), а какая-то своя кодификация. Я оставил локальные коды лесничеств и участковых лесничеств, но поменял код региона на гаишный. Ну, такое вот решение принял. Пока так.
А урочища вообще никак нигде не кодифицировались, их просто сами уже кодифицируем внутри участкового лесничества.

Кто осилит мою писанину - тот молодец.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

На геопортале РЛИ, если помните, с самого начала был уровень выбора участкового леничества, и его границы (где-то чуть ли не точные границы лесного фонда из объединения кварталов в виде сумасшедшего мультиполигона с тысячами островков, а где-то просто внешняя граница объекта со всеми категориями земель). И эти границы можно было увидеть в векторном виде на карте (подгружался мультиполигон в виде GeoJSON). Сейчас этот уровень убран - только лесничество.

Но геометрии в векторном виде выкачаны скриптом и сохранены:)

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

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


Ну и подождем, когда повыдельные базы пойдут в массы как основа для автоматизации всех процессов :) У меня лет 25, надеюсь, в запасе есть.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Пара вопросов... если вы говорите FORESTREGIONID это ваши произвольный цифры, то мне то их где взять? Пока столбец пустой будет. И ещё появились планы лесонасаждений правда не на все лесничества. НО их можно в вектор перевести. Да и выдела можно в таблицах набить. Раз открыли данные...
И ещё... вот эти три столбца, из листа урочище дача, что такое

_________________
С уважением alek.cotov@yandex.ru

Думаете, за 25 лет лесоустройство не перейдет от статичных лесохозяйственных выделов к GRID и динамическим выделам?

Простите за тупость, а что такое - ???

_________________
С уважением alek.cotov@yandex.ru

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

Почему я думаю, что в России есть большие шансы на то, что традиционный подход к лесохозяйственным выделам может загнуться даже быстрее, чем в остальной Европе? Потому, что этот традиционный подход был и остается удобным упрощением, чем и ценен; но в нагрузку к этому упрощению в России идут такие отягчающие обстоятельства, как Рослесинфорг с его монополизмом, новая лесоустроительная инструкция с ее идиотизмом, и т.д. - и эти отягощения уже явно перевешивают все возможные упрощения. Поэтому есть мотивы к тому, чтобы лесоустроительную классику забросить (пусть с ней возится государство и наполняет с ее помощью всякие ГЛРы и ЕГАИСы), и выстроить что-то совсем новое, параллельное, никак не связанное с классическим лесоустройством и потому исходно не замороченное государством. Но, опять же, я не ГИСовец и не лесоустроитель, и в этой тематике разбираюсь не очень сильно, так что это только мои "мысли стороннего наблюдателя".

Я думаю за 25 лет какие-то перемены определенно настанут.

Вот в РЛИ в кои-то веки выслушали детальный доклад от пермяков:
ФГБУ «Рослесинфорг» внедряет цифровые методы таксации лесов

При этом еще в 2010 году (если не ошибаюсь), я присутствовал на встрече в том числе рослесинфорговцев в Финляндии в "Метле" с местой "лесной наукой" и "лесным бизнесом", где мы в том числе давали презентацию промышленных методов таксации через лазерное сканирование (LIDAR). Тогда еще это стоило значительно больше, чем сейчас, для россиян ценник был неподъемным и кроме вопросов о цене других вопросов не было :)

При этом в России пилотные проекты случились. Несмотря на кучу не зависящих от нас обстоятельств, повлиявших на результаты, эти результаты даже РЛИ вынужден был принять (скрепя всеми пружинами).

Других более точных методов пока нет. Можно делать "упрощенку" без LIDAR-а чисто по ландсату или сентинелу или более точной съемке, тогда значительно уменьшается точность, до 30% погрешность.

Я не рассматриваю локальные методы связанные с суперподробной аэрофотосъемкой беспилотниками, это не работает на сотнях тысяч гектар.

Вообщем отставание по лазеру в плане промышленного использования - 15 лет у России. ЛУИ придется перетряхивать значительно. При этом распознавание пород требует дополнительной работы с многоспектральной съемкой и потребует значительной доработки для многопородных лесов (типа Приморья), чтобы обучить алгоритмы (да, machine learning в чистом виде).

GRID - это регулярная "сетка". Уже устоялся де-факто для ЛУ размер ячейки 16 метров на 16 метров. Т.е. земля поделена на сетку с таким размером ячейки и алгоритмы обрабатывая "облако точек" собранное лазерным сканированием вычисляет достаточно точно для каждой ячейки базовые показатели древостоя (первичная - высоты/у, ну и все прочие которые в зависимости от высоты - диаметры, запасы и т.д.). Т.е. вместо выделов сетка, где важдая ячейка знает точно характеристики древостоя (очень точно!).

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

Т.е. это комбинация автоматизированных алгоритмов "сегментации" и ручной работы в ГИС конечными пользователями (лесными инженерами). При этом выдела создаются по мере необходимости. Правильнее их назвать "хозяйственными мероприятиями с привязкой к местности в виде полигональной геометрии". Т.е. традиционной повыдельной БД сплошной на всю территорию даже физически нет, вся первичка в "гриде".

Что такое "традиционные" выдела, которые имеют место быть в нашем российском лесоустройстве? Они откуда взялись? Были "нарисованы" (оцифрованы, векторизованы, и т.д.) поверх обычной аэрофотосъемки. Чисто глазомерно, глядя на контуры леса, на отличающиеся оттенки цвета леса и т.д. Сейчас, когда проводится лесоустройство - берется повыдельная БД (или цифруются планшеты предыдущего ЛУ) и распечатываются поверх аэрофотосъемки. Корректируются в ГИС визуально еще до распечатки на бумаге. А потом в лесу таксаторы "белым маркером" правят границы при необходимости. Потом изменения дооцифровываются. Т.е. есть некая преемственность в том, как выглядят выдела до и после ЛУ.

Эта преемственность должна быть сломана при переходе на грид. Там будет точность ЛУ более высокого порядка, но придется отбросить все существующие данные, по сути просто сложить их в архив (как и было сделано в Финляндии некоторыми лесными организациями, которые перешли на грид). Я не представляю сейчас, как РЛИ и РЛХ могут пойти на то, чтобы по сути признать "свою религию" - ересью. Это удел очень сильных реформаторов, коих в отрасли не наблюдается.

Так что не берусь сказать, будет ли полноценный переход на грид за следующие 25 лет или "запихнут" дешифровку по лазеру в косметически-отредактированную ЛУИ, чтобы сохранить все "традиции" советского ЛУ и выходные "форматы представления данных".

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

Есть еще "стереоскопические" методы, Владимир Архипов Вам расскажет :) Но это же по сути все та же ручная слабо автоматизированная работа, только за компьютером, вместо хождения по лесу при "глазомерной" таксации. Возможно она избавляет от необходимости кормить комаров в лесу, но вряд ли может быть значительно более дешевой технологией, чем нынешнаяя глазомерная. Лазер же в массовых масштабах просто обязательно "уронит" цену и даст более точные данные, что , вообщем-то, любому здравомыслящему государству должно быть выгодно!

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Я тоже не думаю, что в обозримом будущем в Рослесхозе-Рослесинфорге могут появиться сильные реформаторы, и что нынешний подход к лесоучетным работам может быть признан ересью. Мне кажется более вероятным другой сценарий: нынешнее "лесоустройство" сохранится "для государственных нужд", и выродится в еще одну лесоучетную систему, не имеющую никакого отношения к реальности - просто жрущую деньги и производящую какие-то циферьки и бумажки (как ГИЛ, ГЛР, госмониторинг воспроизводства лесов и т.д.). А для практических нужд тех, кто будет пытаться реально хозяйствовать в лесах - будть то арендаторы или спецучреждения - будет развиваться какая-то полностью новая система лесохозяйственного планирования. Ее, видимо, придется назвать как-то иначе, чтобы она отличалась от государственной лесоучетной бессмыслицы и не попадала под соответствующее псевдо-регулирование, но по сути это будет именно лесоустройство в классическом понимании этого слова.

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

vitalus табла по Новгородской области готова. Куда скинуть? И ещё шаблон по выделам\кварталам скинте. Что есть заполню.

_________________
С уважением alek.cotov@yandex.ru

С задержкой, но отвечаю. Лесные районы и зоны набиты, кодифицированы просто мной, можно эти коды увидеть на скриншоте.

Я этот Excel выложу, как и другие данные, "вскорости" (выйду из отпуска в понедельник и замусь поднятием сервера). В шаблоне для лесничеств/уч.лесничеств колонки сделаны для соответствия между участковым лесничеством (это одна уникальная строчка в первой вкладке) и лесным районом напрямую (еще такое соответствие можно делать по цепочке уч.лесничество -> муниципальный район -> лесной район). Но пока что напрямую я сам не набивал. В большинстве случаев у нас будет однозначное соответствие , т.е. уч. лес-во полностью в лесном районе. Но в некоторых случаях может быть больше чем один лесной район. Я писал об этом выше. Так что пока предлагаю прямое соответствие уч. лес-ва лесному району не задавать. До тех пор пока я не разберусь с подходом, как мы неоднозначные случаи обработаем (может через доп. вкладку).

Вообщем пока что все сводится к вводу перечней кварталов, набитию урочищ/дач (если они есть в уч. лесничествах) и заданию соответствия между уч. лесничеством и муниципальным районом.

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

При внесении урочища нужно сформировать его уникальный идентификатор (составной). Я уже писал выше, вкратце: берем идентификатор участкового лесничества (а они уже все есть), он имеет формат

РРЛЛУУУ
РР - регион
ЛЛ - лесничество (РРЛЛ - глобальный для лес-ва)
УУУ - уч. лес-во

и для урочища/дачи две цифры зарезервировано. Т.е. если есть 3 урочища в участковом, то мы их как в ЛХРе они указаны пронумеруем
01
02
03

Т.е. получим для них TRACTID= РРЛЛУУУ01, РРЛЛУУУ02, РРЛЛУУ03

TYP (тип):
1 - урочище
2 - дача
3 - часть

просто справочник типа объекта на этом уровне (на западе страны - дачи, на востоке - урочища, где-то части после реформ 2000-х).

Т.е. это вручную присваемый уникальный глобальный составной идентификатор уровня урочища.

Будет вся иерархия на Россию - сможем нормально "сажать" данные и обмениваться универсально. Посмотрим , сможем ли продвинуть сие дело на официальный уровень...

По выделам - давайте разбираться отдельно. В каком виде повыделка? Пока набивать ее не надо. Таксационное описание можно автоматизированно прочитать - оно есть?

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

:-)) в виде плана лесонасаждений. Естественно таксационки нет. Просто Планы л\н выложены( не на все лесничества, но хоть что-то!) … я скачал. Растр естественно. Таксационки от лесников вряд ли дождёшься… правда не пробывал просить... не хочу!. И куда вам сбросить... на почту отсигнальте… типа "Это я. Виталус!" и... FORESTREGIONID со скана и взял. Урочищ; дач; нет. Есть участковые лесничества в разных районах. Но это трудностей не вызывает.

_________________
С уважением alek.cotov@yandex.ru

Интересное решение, но возник вопрос, какую цель вы перед собой ставите? Что хотите получить в итоге? Чем это будет лучше существующих решений?

Сама система сильно напоминает те программы, что родились в 90 в разных концах страны. Те же плоские таблицы, справочники НСИ на каждое значение, классификаторы лесничеств, регионов и т. д. Вот зачем вам сквозные идентификаторы для каждого выдела?

Я думаю, что от всего этого наследия СОЛИ пора отходить. Если у вас нет заказчика, который ставит сроки и требования, вам и карты в руки. Можно использовать современные решения в системе. Уже давно пора ИТ лесного хозяйства из девяностых шагнуть в двухтысячные)

Вы в целом или про что-то конкретное?


Какие существующие решения (и чего?) Вы имеете ввиду? Я прям задумался:))


Какую программу и где Вы разгдядели?

Сквозной - не сзвозной, а главное - уникальный глобальный идентификатор, составной "бизнес-ключ" и так далее. Зная это значение можно поностью восстановить положение выдела в иерархии. С точки зрения обмена есоустроительными данными (любого обмена - автоматизированного между сервисами и ручного в виде файлов XML) такой бизнес-ключ необходим.

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


Где наследие СОЛИ - конкретно уточняйте? Я сам тут СОЛИ (как устаревшую программу) критиковал, только причем тут СОЛИ сейчас в контексте данного начинания?


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

Как видите, я не трогаю на данный момент именно российскую модель данных для ЛУ, а подготавливаю основу НСИ (ну это должно быть очевидно тем, кто внимательно прочитает ветку), в которую впишется и текущая модель данных, и будущая (повыдельная ли, на основе ГРИДа ли, и так далее) :)

Насчет выделов и номеров... Там я просто не упомянул, что последняя цифра, которая по умочанию "0" зарезервирована для тех случаев, когда в контексте НЛУ происходит деление выдела на два, тогда можно ввести нумерацию вида "10.1" для новой части (в межревизионный период). В этом случае глобальный идентификатор будет вида "....0101"
Поэтому без дробной части получаются номера для выделов 1, 2 вида "...0010", "0020",...
Т.е. такая "псевдосквозная" нумерация. Что называется, by design. Нолик с конца - это как раз для случая с делением.

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

Готов отвечать на любой вопрос развернуто и аргументированно, если вопросы будут конкретные и понятные:) А то иногда приходится додумывать, что там имелось ввиду.

Ну и как всегда одна из целей - пошевелить палкой в муравейнике. Как хотите - так и понимайте :)

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Зачем вам этот бизнес ключ? Получается, что у вас основа информации - выдел. А если он исчез, или если лесничество разделилось? Получается нужно менять адреса у всех выделов в иерархии? Понятно, зачем это было нужно в СОЛИ - когда нет геоинформации, это единственный способ понять к чему относится выдел. Но сейчас-то зачем эту нумерацию тащить?


Не хочет? Или вы просто не в курсе?)) Лет 6 назад в Рослесинфорге ходили разговоры про проект самого лучшего НСИ, но что-то ничего с тех пор не увидели. Можно, конечно, считать, что они все глупы и не могут сообразить, как это сделать. А может задача сложнее чем кажется? Да и непонятно, что даст ее решение? Можно будет сделать СОЛИ-3? )


Вы все-таки сформулируйте цель проекта. Тогда можно будет сравнивать.


Так вы на свою схему БД посмотрите - то же что и у СОЛИ, только названия другие) Вся эта идея - разложить текстовые описания леса на кучу классификаторов и есть основной принцип СОЛИ. Единые НСИ - тоже оттуда.
А что, по-вашему, не так с СОЛИ? Ее уши торчат во всех приложениях для лесоустройства (ЛесГИС, Лес ИС, Тополь, Лесинфорг, Есаул ). Вот бы кто-то прервал эту традицию и предложил что-то принципиально новое.


У вас не хватает разрядов? Или длинна поля ограничена? :) А потом говорите, что СОЛИ - ужас, ужас.

Чего-чего? Выдел исчез - что не так?

Давайте не будем называть это "адресами" - это ж не проспект Жукова, дом двадцать пять. Отсылка к СОЛИ вообще непонятна, она тут вообще ни при чем. Я ниже аргументирую и объясню.

Лесничество разделилось - значит одной кнопкой в любой информационной системе, где реализована простейшая логика - в необходимых объектах обновим уникальные глобальные ключи. Это простейшая манипуляция данными, либо напрямую в БД через SQL, либо в бизнес-логике ПО.

Тащить какую нумерацию и куда?:) Конкретнее, ваш use case, который вас озадачил в связи с какой-то нумерацией, которую тащат? Я же написал в посте выше для чего необходимо и полезно иметь составной бизнес ключ, который строится таким образом. Там исчерпывающе несколько кейсов описаны.



Ну вот, "ходили разговоры" :) Я вообще "слабо понимаю" процессы РЛИ (с точки зрения адекватности и эффективности). В 2019 году организация использует целый огород из программных средств для своей работы и много чего не имеет, что должна бы.
Задача , которую решаем мы - очень простая. Она не имеет никакого отношения ни к СОЛИ, ни к СОЛИ-3 ни к РЛИ, а универсальна и основополагающа для любой современной ГИС системы (или не ГИС , но системы) для работы с ЛУ данными.
Я надеюсь, здесь мы спорить не будем? Или все-таки этот момент для Вас непонятен?


Прочитайте ветку внимательно, все написано по нескольку раз и очень подробно. Ну честное слово! Если сравнивать - главное чтобы не рябчики с ананасами. То, что потихоньку возникает у нас - не существует ни в каком виде у кого бы то ни было. А если какие-то зачатки существуют, но спрятаны "в подвалах РЛИ" - значит не существуют. Потому что речь идет о результатах, доступных всему сообществу профессионалов автоматизации лесного хозяйства.
Ключи составные есть и в Тополе и много где-еще. А полного реестра объектов и системного подхода, чтобы в том числе и поддерживать эти данные - нет ни у кого.

Даже чтобы поднять БД на регион - уже надо постараться посадить ЛУ данные на общую основу. Мы это сделали и четко знаем, какие проблемы и как их решать.



Где Вы схему БД увидели? Я лично нигде никакие свои схемы БД не публиковал какие-бы то ни было.

Текстовые описания леса? О боже :) Давайте по порядку. У нас явно - "трудности терминологии".

В отрасли никогда не было единых НСИ. Ни из СОЛИ, ни откуда. Иначе показывайте стандарт в виде отраслевых схем XML (или чего бы то ни было), или хотя бы НПА, где необходимые классификаторы или справочники или что-то еще официально зафиксированы, упоминаются в ЛУИ и все других нормативно правовых актах.
Более смешной "единой НСИ" еще поискать надо... чем в нашей "лесной отрасли". И СОЛИ - в хвост и в гриву там эти НСИ редактировались, менялись и чего только с ними не делали "наши лесоустроители". Достаточно собрать таксационные описания на один регион, чтобы увидеть весь позор "единых НСИ". Не было никаких единых НСИ в СОЛИ. Тем более такая попытка провалилась во время создания АИС ГЛР.

Я вообще не очень понимаю, что Вы хотите мне рассказать... Про то, что все существующие "локальные ГИС" типа Тополя и его клонов/конкурентов - имеют СОЛИшную структуру данных (модель данных) - это так и есть, разве это секрет?. Потому что эта модель была взята из , собственно, требований ЛУИ (которые слабо поменялись с тех пор, а потому актуальны и сейчас) и реализованы именно в той досовской СОЛИ. Все эти макеты, доп. макеты и так далее. Это и есть де-факто отраслевая модель данных.
Если гос-во переработает требования на то, что называется лесоустроительными данными и лесоустройством - будут и новые модели данных и новое ПО для этого. В чем пафос

?

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

Просто чтобы читателей не вводить в заблуждение. Я очень точно отделяю то, что мы делаем (читать ветку сверху) от прочего "повыдельного атрибутивного наполнения", уходящего корнями в СОЛИ, как Вы и упомянули.


Я вообще не понял, при чем тут какие-то разряды или длина поля? Уникальный идентификатор должен быть целым числом (я так хочу), это наиболее эффективный тип данных для БД для атрибутов - Primary key / foreign key. Он и есть целое число согласно выбранному подходу, когда в числе спрятана вся информация об уровнях иерархии, даже с учетом "дробной части" выдела (если она появится когда-либо в каком-либо процессе).

СОЛИ - ужас, ужас! В том смысле, что пора в 2019 уже прекратить на нее ссылаться или использовать как программный продукт. Пусть останется неким носителем "традиций" и "народной памяти", и как эталон отраслевой лесоустроительной модели данных в доисторические времена. А это означает, что и текущее лесоустройство, слабо изменившееся с тех пор - "доисторическое". И мы - автоматизаторы - все в какой-то мере конформисты (как признавался коллега А. Серов из "Техкарты" ).


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



У нас учтено 146 процентов возможных use cases. ID объектов из "отраслевой" иерархии как раз есть составные уникальные глобальные ключи (регион, лес-во, уч. лес-во, урочище). На уровне квартала и выдела - тоже составные глобальные уникальные ключи , но у них уже "вспомогательная роль" - при обмене данными и так далее, а primary key в БД для квартала и выдела - суррогатные ключи для удобства.
Короче, я уже сильно вышел за пределы топика - это внутренние нюансы , которые Вы не знаете, поэтому столько вопросов "почему". Пишите мне в скайп, созвонимся и я наглядно расскажу и покажу что к чему. А если хотите - присоединяйтесь и влияйте на наши решения (аргументированной дискуссией).

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

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

_________________
С уважением alek.cotov@yandex.ru

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

Я позволю себе немного порассуждать на эту тему.

Конкретно новое в ПО и автоматизации можно ждать по мере модернизации отраслевых процессов, начиная с лесоустройства. Уже обсуждался подход (который успешно реализован в Финляндии) по переходу к таксации леса методами ДЗЗ (лазер, как пример), в этом случае повыдельная БД - не является базовыми первичными данными для хозяйственной деятельности, хотя может быть побочным продуктом лесоустройства "на гриде". Конечно, тогда все локальные ГИС, которые сейчас востребованы и заточены под ЛУИ уйдут "на покой" либо на глубокую переделку.

У нас в России слишком сильны традиции очень подробного описания лесотаксационных выделов, значительную часть информации (в виде того, что называется со времен СОЛИ или ранее "дополнительными макетами" в модели данных) нельзя собрать методами ДЗЗ. При этом глядя на современные ТО не могу сказать, что и при глазомерной таксации лесоустроители так уж усердствуют описывая травы, почвы и прочую информацию. 90% дополнительных макетов просто отсутствуют в ТО. Но по ЛУИ это требуется. При переходе на ДЗЗ-таксацию, наверное , разумно разделить процесс лесоустройства на сбор базовых первичных атрибутов древостоя по данным ДЗЗ и переход на грид, и более подробное описание "динамических выделов" при планировании лесосечных работ или иных мероприятий. Т.е. не выдел, а "хозяйственное мероприятие" будет основным полигональным объектом в БД "хозяйствующей организации". Это значительный слом традиций, устоев, всего-всего на чем стоит лесное хозяйство и все процессы сейчас. Я даже затрудняюсь сказать - было бы ли это оправданным в реалиях России... Это ж такая огромная страна, столько людей, столько законов и НПА, столько инерции заложено вот в этом всём...

Что нового можно увидеть тогда оставаясь в рамках "повыдельной модели данных времен СОЛИ" ?

Переход на работу в клиент-серверном окружении с "вытекающими" преимуществами.

Лесоустройство делается на локальных ГИС, но работающих с сервисами, откуда централизованно берутся НСИ,параметрические данные для вычислений, когда происходит автоматизированный обмен данными и накопление данных на сервере, в центральной БД лесоустроительной организации. Это применимо как к РЛИ так и любой коммерческой ОООшке (при желании повысить эффективность).

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

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

Все эти три стороны могут быть состыкованы с высокой долей автоматизации за счет обмена данными в стандартных форматах и формах.

МДОЛы, Абрисы, турботаксаторы, румбы, лесгисы, тополи, ясени, клёны - вынуждены будут ускоренными темпами переходить на стандарты отраслевые обмена данными.

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

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

1) Первый сценарий - апокалиптический для РЛХ - это переход на грид и "точное" лесоустройство методами ДЗЗ разбитое на два этапа (этапность раскрыта постами Владимира Архипова - только в контексте "стереоскопической" таксации, второй этап - это уточнение нужных хар-к "выделов" в момент отвода, а также использование этих достаточно точных данных отвода - ведь чуть ли не перечет делается всегда - для уточнения ЛУ данных, как то так). Понадобится новое ПО в категории ГИС, реально новое, с новыми процессами и цепочкой работ для ЛУ и так далее.

2) Второй сценарий - традиционное ЛУ как сейчас, возможно с применением и лазера и других методов ДЗЗ, но все та же модель данных и процессы. Только больше автоматизации отраслевой, обмена данными между всеми участниками отраслевых отношений, больше автоматизированной отчетности и гораздо меньше "бумажной" отчетной рутины, гораздо проще для арендаторов применение технологий в их процессах (через облачные сервисы с их арендаторскими данными и web-интерфейсом, мобильным интерфейсом), меньше времени в ОИВах для "поднятия" ада отчетности в егаисы и так далее.

Второй сценарий можно ковырять прямо сейчас.

Прогнозист из меня плохой, но на заданный вопрос, думаю, как-то ответил:)

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Это ещё можно было сделать 10 лет назад, имея политическую волю. Сейчас, по большому счету, от органов государственной власти требуется только одно- структура обменного формата. У Рослесинфорга самая большая электронаая база данных, обменный формат (насколько я осведомлён) между филиалами ведется только при необходимости в СОЛИ, так как некоторые филиалы до сих пор на них работают. В принципе и в соли можно делать импорт из любой системы (мотивация для разработчков сейчас слабая в этом вопросе), вот только сервер на Солях не реализуем(если смотреть в будущее), по причине текстовой структуры базы данных, нужна конСОЛИдация или политическая воля в этом вопросе. Этот вопрос реализуем для разработчиков систем в очень быстрые сроки, про ГИСы даже думать не надо, любые форматы между собой конвертируются. Берем одну систему (Топол, Соли, АИС_пол, Forest DB, Есаул и т.п. ) определяемся с единым обменным форматом, сдаем в ГЛР при лесоустройстве в обязательном порядке и вопрос решен.
Может выглядеть примерно так: берешь разрешение на таксацию лесов в аренде, или контракт на полноценное лесоустройство всего лесничества-ГЛР тебе в едином формате базу предоставляет на безвозмездной основе- на условиях, что получит новую базу данных безвозмездно. Органам гос власти минимум телодвижений...
Все отчеты есть, расчитать ЛХР, лесной план- будет легким занятием, тем более там не нужна полная база, хватит какой-нибудь обрезанной Структуры (для облегчения расчетов больших данных). ГЛР ведется на субъект, в более широкую её объединять для конкретных целей пока не требуется, ГИСы объединяются на раз с атрибутивной инф.
А вот утвержденную нормативку привести в доступный вид должно входить в компетенцию того же Реестра, а сейчас они не могут даже посчитать ни товарную структуру, ни проверить определение бонитетов, запасов, площадей...мрак в реестре... а по большому счету, для Просвета нужна просто политическая воля...
Переход на ДЗЗ- утопия, у нас все законодательство заточено под классическую модель ТО, где лесовосстановление назначаешь по количеству подроста под пологом леса, умноженного на коэффициент его сохранения (вообще не реализуемо даже теоретически при дистанционке), при таксации определяешь второй ярус, его относительную полноту, По относительной полноте назначаешь рубки ухода, Выборочные рубки и т.д. и т.п.
Обменный формат просто необходим уже давно и пока сверху не спустят- никому ничего не надо, автор исключение из правил... Какие то субъекты до сих пор вообще не заморачиваются по собиранию хоть какой-то электронной информации по итогам лесоустройства, а потом пишут в госконтракте на лесной план объединить базу данных и принимают карты в фотошопе соединённые (так, лирическое отступление).
По итогу, новую структуру придумывать- всем жизнь усложнять (новые коды, NSI и т.д.), может быть взять уже любую существующую?

Ну вот, очень полезный и грамотный комментарий.

По формату. Модель данных лесоустроительная - по-сути СОЛИшная до сих пор (в смысле сущностей, атрибутов и их взаимоотношений, а не типов данных - тут уже ориентироваться на СОЛИ не нужно), она же используется в немногочисленных продуктах типа Тополя, обменный формат - к бабке не ходи - имеет смысл просто реализовать на основе XML.
Вот , по-моему, в четвертый раз делаю ссылку на финский стандарт обмена лесными данными(не только лесоустроительными, а для всех возможных лесных процессов):
- таблица документации и схем: https://bitcomp.com/forest-information-standards/
- повыделка: https://extra.bitcomp.fi/metsastandardi_ehdotus/V11/MV/doc/index.html

Дело в том, что вся НСИ также является частью стандарта (справочники с кодами также описаны на уровне XML схем). Т.е. вся НСИ - стандартная (там порядка 6000 или 9000 кодов из разных справочников - не помню, много). Значительная часть атрибутов - это атрибуты со значениями из справочников. Нам же (в России) предстоит еще работа по этой части (унификация, стандартизация, приведение данных к этой НСИ и т.д.)

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

Когда говорят о ГИС - думают в большинстве случаев о простейших сценариях: открыл Shapefile, отредактировал геометрии, поправил атрибутик, сохранил, закрыл, отправил... Но это очень далеко от работы с пусть и достаточно простой, но все же иерархической моделью данных лесоустройства с кучей справочников, которые ну просто каждый настраивает исходя из каких-то своих местных традиций и обрядов.

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


Поэтому, не соглашусь. Имею реальный многолетний опыт работы по этой теме. Отраслевой стандарт обмена данными - это в 10 раз больше, чем просто генерация какого-то XML в приложении из данных, лежащих, там, в БД (которая, собственно, и "понимается" чаще всего под работой по созданию обменного формата).


Да, сдача всех материалов ЛУ (атрибутивно-пространственных) должна быть "в векторе", в виде XML документа(ов) согласно отраслевому стандарту обмена ЛУ данными (согласно соответствующим XML схемам).



Да это вообще должно быть как само собой разумеющееся. Данные текущие из ГЛР выплевываются в виде того же документа согласно схемам XML обменного отраслевого формата на ЛУ. И новое ЛУ приходит в таком же виде.
Будет стандарт - все приложения подтянутся под эти требования (с облегчением вздохнув).


Согласен, пока можно консолидировать ЛУ данные на уровне региона. Смысла собирать федеральную ЛУ БД не вижу на данном этапе, пока не осилят региональный уровень (или даже вообще без нее).


Очень много воли и хорошая команда. Я бы поучаствовал.


Все так, поэтому лазер официально (кроме пилотов) не применим. Нужно понимать, что он даст точные базовые показатели древостоя (высоту и производные от нее) на гриде (про который писал).
Но другие страны как то обходятся без такой глазомерной таксации как в России. Мое видение - "либерализация" процесса лесоустройства, осовременивание. Вкратце где-то раскрывал тему, и не только я так считаю.


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

Самый главный бузетер - сам же РЛИ. Кого ни спросишь - мало довольных. Чего уж тут говорить, если большая часть ЛХРов - это PDF-ы, сканированные с бумаги (т.е. вместо текста - картинки растровые, текст не скопировать).


Так , тут вообщем-то все есть , модель данных то СОЛИшная. Только обернуть ее в формат - дело нифига не плевое (если мы претендуем называться отраслевым стандартным форматом обмена данных, да еще и со стандартной НСИ).
В Финляндии я бы оценил сроки перехода к отраслевому стандарту обмена лесной информацией лет в 8-10 (вообщем-то на моих глазах и произошел, я и сам создавал интерфейсы для импорта-экспорта в одной большой ГИС системе).

Вот пример задачи "натягивания совы на глобус" (т.е. попытки перевода текущих ЛУ данных на "стандартную" НСИ):

Допустим, завели мы стандартный справочник ОЗУ,со значениями согласно последним НПА. А вот Вам, что называется, legacy - т.е. данные из 215 таксационных описаний на регион. Это таблица соответствия старых текстовых значений в коды единого справочника. И ведь сделано ЛУ по сути в одном филиале РЛИ , только в разные года. Посмотрите, какие замечательные справочники у них там! Обратите внимание на расположение запятых, пробелов, сокращений. Это же просто творчество какое-то, песня!

Еще попробуй определить , как переклассифицировать "берегозащитные, почвозащитные..." в два разных значения , как это требуется сейчас. Это не всегда и возможно, потребуется может даже пространственное редактирование. Ну мы решили пока так, как на скриншоте, а по сути, нужно же серьезно задачу решать, тут страшная неоднозначность, тупой перекодировкой не обойдешься механической!
Вот еще:


Так что задача это будет для отрасли колоссальная. И формат, и НСИ, и перевод ЛУ на современный лад.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

Несколько ложечек дёгтя в два последних комента... Вы бы господа чуть к земле прижались.... бы. Мысли интересные, НО ... задайте себе вопрос что такое Рослесинфорг? Эта шарага которая (будь у неё возможности) засекретила бы всё, вплоть до времени восхода солнца. Ни каких обменов данными оно не допустит. Соответственно и ни о каких общих баз данных, обменных форматов делать НЕ будет. И ещё ... крайний низкий уровень профессионализма. Не знаю почему так получилось, в лесоустройстве всегда наиболее квалифицированные кадры были. Возможно из - за малых зарплат работать люди стали "на от..сь". У этого ведомства если есть 2га выдел; с запасом на га=200 кубов то общий запас на выделе(Пл=2га не забыть!!) равен 1047кубов.
Работать с этой конторой(в сейчашнем виде) НЕВОЗМОЖНО! Не обольщайтесь!

_________________
С уважением alek.cotov@yandex.ru

Кадровое обеспечение у РЛИ конечно хромает, но старую школу со счетов списывать не надо, лучше специалистов не найдёшь, но к сожалению это не означает априори качество их работы, да им и не нужно... учитывая их административный ресурс...РЛИ=РЛХ=Министерство=ГЛР=Лесничество и т.д... И я не думаю что это их вина, мне кажется что это система ущербна, точнее её нет, все выживают в своем микроклимате, общей цели нет, воообще ни у кого, её просто нет, есть конкретные задачи, не структурированные, разрозненные... Но в общем обменном формате, который свою актуальность потдерживает сам просто уже напросился, и для этого никому ничего делать не надо, просто приказ сверху, всё само на место встанет (жизнь заставит), только может всё испортить, если на этой саморегулируемой идее кто-то захочет делать деньги...
Мы расковыривали базы данных СОЛИ, ТОПОЛ, Forest DB справочники везде отличаются, разные базы данных отличаются- факт и собирать их в одну систему-ад, НО, что касается основных справочников - все однотипное, отличается структурой самой базы данных, а это вопрос, который разработчик может решить за один раз. Так что, кому как: А коды основных справочников- более менее имеют жесткую структуру, плавают в основном МДС, так что отрослевую Урезанную NSI на уровень Страны можно принять хоть сейчас солевую, тополёвую, какую угодно. И в этом должны быть заинтересованы органы гос. власти, повторюсь, им и делать, по большому счету, ничего для этого не надо. Просто табличку из 50 столбиков в EXEL, где каждый столбик что-то значит в кодах, и к ним прикреплены справочники по субъекту, для разработчиков выгрузка в такую структуру решается раз, Картография привязывается по соответствии 3 столбиков (Уч лесн, КВ, ВД), все благополучно объединяется на субъект по одному столбику(Лесн) и выкатывается любая информация для органов Гос власти. Почему 50 столбиков вы меня спросите, если пород на выделе может быть много? Отвечу так: Всё равно все ЛХР и планы и проекты, считаются по преобладающей породе, об этом никто не говорит, но так оно есть. Даже в ЛУи записано, что определение ПП критическая ошибка, потому что остальные породы можно вообще не определять, во многих системах в расчет они не попадут. Спрашивали у всех, зачем тогда таксация: все разводят руками, по другому мы считать не умеем... В этом контексте ДЗЗ звучит крайне разумно, но систему нельзя переводить на дистанционку, специалист лесного хозяйства, который создаёт материалы ЛУ, должен проводить время в лесу, должен там работать, понимать закономерности, знать законодательство, общаться с лесниками и принимать модель лесопользования на месте, а не сидя в кабинете, и меня в обратном не убедить...
С многоуровневой системой сложно работать, нужен один уровень, вообще один, с массивом данных в одной таблице, где справочники подключаются для конкретного столбца, где хранится геоинформация в последнем столбце и подключается к SQL. Системы уже есть такие, разработанные на ряд субъектов, с полными (основными, 50 столбцов )справочниками на субъект. Эта работа может включаться в лесной план(Политическая воля хотя бы субъекта), один раз сделать и раздать материалы ЛУ и НСИ всем исполнителям в обязательном порядке, левым людям эта информация и не нужна, а они все сикретят да секретят...

Несколько, очевидно, очень упрощенных и ошибочных тезисов. Разберем.

Во-первых, как то в кучу все: и справочники (т.е. НСИ), и модель данных. Нужно четко эти понятия разделить на техническом уровне. Модель данных содержит в том числе атрибуты, значения из которых берутся из справочников. Конкретный такой атрибут работает с конкретным справочником для него.


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

Давайте далеко ходить не будем, а попробуем просто на всю страну хотя бы универсальный справочник по породам составить?:)

Или Вы просто предлагаете взять какой-нибудь Тополь, оттуда пород штук 40 из конкретной тополевской БД (проекта) и назвать это единым справочником пород для стандартной отраслевой НСИ? Это и упрощенный взгляд и ошибочный план, считаю. Для пород все-таки надо работу определенную проделать, хоть и отталкиваясь от чего-то - будь то СССРовский справочник 1984 года или еще какой...


Конечно, принять так, как Вы предлагаете нельзя и просто невозможно. Мне кажется уже было достаточное количество попыток в отрасли (и в той же АИС ГЛР) решить этот вопрос вот таким вот нахрапом.


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

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


Прочитайте, пожалуйста, внимательно эту ветку сначала. Есть "отраслевая иерархия" объектов (уровней), в которой те же квартала и выдела "сидят". Так что трех столбиков будет недостаточно :)
Далее, в современных ГИС системах картографию не надо никуда "привязывать". Что такое картография (не берем растровые данные)? Раскрашенные геометрические "примитивы" - точки , линии, полигоны. Геометрия - это просто такой же атрибут в модели данных как и все прочие (числа, текстовые поля и так далее) в современных ГИС технологиях, форматах, базах данных.

Ну и, конечно же, уровень урочища (она же дача, она же часть) - как всегда пропущена :)))))) Будет у нас к участковом лесничестве два квартала с номером 1 (которые суть есть разные квартала в разных урочищах данного участкового лесничества). Ну что сказать - зато привязались!



Да нет никакой сложности в модели данных лесоустроительной. Конечно же, она иерархическая. Конечно же, при реализации ее в реляционной БД - модель данных потребует многих таблиц и реляционных связей. Конечно же, нужно никогда не делать так, как Вы предлагаете (ну если только целью не является выгрузка какого-то множества атрибутов в Shapefile, чтобы кто-то его смог открыть в QGIS и посмотреть что-то, может даже распечатать). Я категорически не согласен с данным упрощением о "плоскости" отраслевых данных. Ну тут даже говорить не о чем.

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

И разворачивать естественную иерархическую модель данных в 50 колонок Excel-я сегодня (а сегодня не 1985 год технологически) - это какое-то недоразумение, простите.

Одно другому не мешает. Та же главная порода (атрибут на уровне выдела) является просто простым расчетным показателем (расчитываемым по ЛУ инструкции из данных яруса - т.е. пород, глядя на коэффициенты или ценность породы при равых кэфах).

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


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

В целом я и не утверждаю, что ДЗЗ - это должен быть только офис, конечно нет:)


Да ничего не сложно. Просто Вы не сможете сделать из, условно, QGIS-а, систему, заточенную под ЛУ чисто какими-то макросами, питоном и скриптами за неделю. Нужно всеравно вложиться в разработку и модели данных и UI и бизнес-логики.

Но да, многие пытаются работать просто взяв QGIS и запихнув базовые атрибуты в том числе из вложенных сущностей повыдельной модели данных в "плоскую структуру" из 150-ти колонок.. Я тоже так могу. Только это полная какая-то фигня, серьезной работы с данными так не организовать. Если бы было все так просто в этой жизни...


Вот да - одноразовое, как пластиковая посуда. Мы пойдем другим путем. А в отрасли еще долго будет востребована псевдоавтоматизация и разные поделки на коленке.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

а почему бы и нет? в Тополе не так уж и мало кодов от Солей, а структура базы приводится в те же 150 , точнее 250 столбцов.
зачем составлять какой-то новый, если он уже есть? и не а вполне себе обширный список и это всего лишь список... Коды это инструмент, и каким пользоваться особой роли не играет.

Нужно четко понимать какая информация нужна и для каких целей. Урезаная база нужна для ЛХР, Плана, её можно собирать без особых усилий из разных систем вполне быстро(если вести её перманентно, а не собирать базу с 500 арендаторов за 3 дня для ЛП и ЛХР), полную базу в любом случае не получится соединить на субъект, даже на районное лесничество может не получится из за большого количества данных и справочников. А на лесные участки базу хранить в исходном состоянии, в исходном ПО, с исходными справочниками, ведь она нужна для материалов таксации, ПОЛ и последующего лесоустройства, что возложили на лесопользователя.
АИС ГЛР ведут лесники, она вообще непонятно для чего создана, её делали по госконтракту для галочки, ГИЛ, АИС_ГЛР это всё аппендиксы, непрерывку на них не построишь, а вот рабочие системы, связанные в перспективе с картографией на русских ГИС движках (кои в зачаточном состоянии, но впрочем эта другая тема) могут упростить жизнь всем.
урочища, лесные участки сделанные из уч. лесничеств, такой бадак конечно понатворили при объединении... но если есть такое деление в лесничествах, органы гос власти все равно требуют по ним считать отдельно, как по участковому лесничеству, так что будем дальше пропускать и называть урочище- участковым лесничеством, деваться некуда!
Ещё раз, нужно понимать какой массив данных для чего нужен, мы же не будем по нему нумерацию переделывать, или проектировать ОЗУ Защитки, площади считать не будем, это всё делается по контрактной системе, на арендный участок или лесничество по госконтрактам...

Финляндия, Финляндия, ДЗЗ, ДЗЗ, во первых у нас чуть чуть побольше лесов, во вторых чуть чуть поменьше денег на все это, в третьих лазер имеет слишком большой объем неструктурированных данных, в купе с первым и вторым мы получаем просто пустые красивые слова, когда речь идёт о миллионах га.
С одноразовой пластиковой посудой лучше чем без неё, а альтернатив нет. Могу только пожелать удачи и не превратить задумку в что-то подобное, надеюсь наш диалог оказался продуктивным для размышления по очень актуальной теме для нашей отрасли.

Далеко не пропадайте, пишите. Я чувствую, Вас направить в правильную сторону, годик, другой и будет очень ценный кадр для автоматизации лесоустройства будущего :)


Ну какие еще столбцы. Даже в старом тополе на DBF-ах было какое-то подобие "реляционности", правда ярусы и породы как раз были "плоско" представлены, но их бизнес-логика правильно "делила" на двух-уровневую иерархию.

Вы в курсе, думаю, что у выдела:
0..* ярусов, у каждого из которых
1..* пород
0..* хоз. мероприятий (хоть и не больше трех обычно)
0..* доп. макетов (в болшинстве случаев 1, иногда несколько)

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


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

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

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


Да нет же! Урочище есть урочище, оно в участковом. Ну зачем эта путаница. Ну и чем лучше такая "информатизация" лесоустройства , предлагаемая Вами , чем то, что делается периодически государством со своими АИСами?

Я как раз здесь пытаюсь расставить точки над i и начать вытягивать автоматизацию лесоустройства из болота, в котором оно находится на современный уровень технологического развития. Хватит упрощений и костылей. Локальный уровень тоже больше не катит, у него очень ограниченное применение (тупо лесоустройство, сделанное в условном Тополе). И как только лесоустройство сделано - данные должны в цифровом формате отправляться как минимум в региональную БД, откуда идет их раздача кому нужно.


Очень хорошо! Чем больше миллионов Га, тем дешевле лесоустройство. Лазер дает облако точек, которые обрабатываются и получается вполне себе традиционные базовые характеристики древостоя. Никакой проблемы с этим нет, это не пустые слова, а промышленная технология, которой таксируются десятки миллионов Га ежегодно в разных странах. А "жесткие диски" - теперь не ограничение для хранения больших объемов промежуточных данных при обработке.


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


Это по справочнику с породами? Ну покажите, где он есть (выдирать из Тополя не надо, я как раз писал выше, почему этого недостаточно).

Несколько выводов.

1) Ничего упрощать в плане модели данных, чтобы можно было работать типа на коленке, не надо. Нет противоречия в том, что есть полноценная иерархическая модель данных для лесоустройства, и при необходимости данные из нее можно произвольным образом вытягивать и трансформировать в какие-то промежуточные (плоские, например) форматы и представления.

2) Аргументация по НСИ и обменным форматам - не убедила от слова совсем. Много воды, неподкрепленной анализом. Попробуйте подробнее раскрыть тему, может я не до конца Вас понимаю :)

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

4) Давайте попробуем составить универсальный справочник пород, попробуем его "применить" к каким-нибудь реальным кейсам. Сразу даю подсказку: попробуйте хотя бы собрать наименования пород из приказа по возрасту рубки. А еще есть много других приказов. Там вот липа медоносная, липа товарная. Это породы такие? Ну, если мы будем породы собирать по научному принципу. Сказали - полезайте в кузов!

Ну вот так вот. Надеюсь наша полезная дискуссия только началась :)

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

vitalus ваш оппонент не даёт себе за труд ознакомится просто с инструкцией по современным БД. Я себя тоже знатоком данного предмета не считаю...но с инструкцией того же постгрея можно ознакомится.
Лен обл сделал сброшу вечером. Пояснения хочу по векторизации кварталок. То что выложенная по квартальная схема далека от понятия точности думаю у вас не вызывает сомнения. Да я ещё при накладке на стандартную подложку накасячу(в пределах метров)… Вот и вопрос стоит такое делать? Работы до фига, а результат "мало точный" :-)))

_________________
С уважением alek.cotov@yandex.ru

Итак, первое, что мы можем подцепить к уровню участковое лесничество/урочище - это перечни кварталов из ЛХРов. В Интернете есть на некоторые регионы и объекты кварталки в векторном виде (как официальные, так и неофициальные, видимо, оцифрованные "волонтерами").

Собственно после выкладки на сервер иерархии начну наполнять уровни участкового лесничества /урочища кварталами (как сущностями со своими атрибутами и геометрией, если найдется shapefile в интернете).

Отдельно попробую выяснить у ребят из http://hcvf.wwf.ru/ru о возможностях "тянуть" из лесегаиса данные по аренде (вроде они чего-то сделали недавно по этой части).

По дальнейшим идеям - после завершения первого этапа и появления сервера. Может даже запустим голосовалку для приоритизации разработки.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

На пять регионов собрана и интегрирована в "общий котел" (uber-Excel) общая информация по ЛХРам:
- перечни кварталов
- перечни урочищ
- соответствие (участкового или урочища) муниципальным округам (в том числе множественное, до поры до времени без возможности точной связи перечнем кварталов, так как в ЛХРах не указано)
- соответствие лесным районам (через муниципальные и приказ о возрасте рубок или напрямую).

Ну и кроме того полный перечень лесничеств и участковых лесничеств уже был.

Сейчас идет доработка "landing page" (т.е. мордолица сервера - web интерфейса, через который иерархию и информацию можно просматривать).

Предлагаю пять регионов превратить в 15 в течение сентября (не торопясь). 4 человека подключились и помогли с "пилотными" регионами.

"Отрасль" постаралась затруднить работу с первичной лесоустроительной информацией по-максимуму. Из публичных ЛХРов практически нельзя однозначно восстановить ситуацию с границами (целевого, категории земель, ОЗУ и так далее), поскольку и границ-то нет. Перечни "частей квартала" не помогут.

Еще важно на данном этапе - начать анализ доступных кварталок. Кое-что все-таки можно будет взять и использовать - тогда появятся дополнительные возможности работы с картой (соединения "атрибутивки" и места на карте).

Ну а вот сервис для автоматической конвертации текстовых СОЛИшных таксационных описаний - идея уже на стадии пилотной реализации, парсер-то есть. Лесоустроители из государственных компаний (да и некоторые частники, к сожалению) думают, что придерживая оригинальные базы данных у себя и передавая только Word-ы, PDF-ы с таксационными атрибутами заказчиками они как бы "играют" на себя "вдолгую", создавая себе в будущем конкуретное преимущество в виде обладания БД без необходимости переводить ЛУ с бумаги в цифру (как пришлось бы следующим сторонним лесоустроителям). А мы попробуем поддержать автоматизированную конвертацию ТО из "этих форматов" в электронную БД с нормализованной отраслевой лесоустроительной моделью данных. Сломаем стратегию "удержальщиков электронных лесоустроительных БД", которые в обязательном порядке должны передаваться.

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

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

vitalus- наложил схему из ЛХР- кварталки на OSM -Standart. Но … не точно всё это... В некоторых местах до 15-20 метров отклонения. Можно конечно где то чуть растянуть, где то ужать... НО не лежит душа! А точных материалов нет. Что скажите?
PS: пока дело стало. Времени совсем нет...

_________________
С уважением alek.cotov@yandex.ru

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

Пока быстрый ответ.

У меня двойственное отношение к доступным Shapefile-ам с квартальными границами, разбросанными "по интернетам".

С одной стороны - любые данные пойдут при нынешнем голоде на лесные геопространственные данные.

С другой стороны - накладывал я эти кварталки и на точную ортофотооснову, и на Google Earth, сравнивал с последними лесоустроительными данными. Значительная часть этих кварталок - просто мусор, который настолько "поехал" от реальных границ официального ЛУ.. Ну не представляю, как можно это использовать. Может даже вреда больше будет. Особенно это бросается в глаза когда открываешь какой-нибудь геопортал приличный, типа WWF-ных хотя бы, а там еще и куча информации привязана к кварталам, которых уже и не существует после лесоустройства..

Раньше я был ЗА использование любых данных, теперь по поводу "любительских" кварталок - много сомнений. Мы же хотим привязывать к ним информацию, данные.

Можно цифровать стараться самим аккуратно, но это труд, который легко "устареет" после очередного ЛУ.


А из того , что есть, нужно каждый Shapefile отсмотреть и проанализировать - стоит ли. Индицидуально.

_________________
специалист на стыке IT, GIS и ЛХ
"лечу маразм, демагогию и очковтирательство"

вот и я о том же... Схема из ЛХР это из той же оперы что и любительский шейп-файл. Как пример - накладываю лесничество. ОНО в границах мун., района. Границы НЕ совпадают... не согласовывались они лесо устроителями с земле устроителями. Нужны точные данные. Не знаю как быть. Думаю это принципиальный вопрос. Плодить туфту на основе туфты лесоустройства категорически не хочется. Пытался (у себя и для себя, как учёба!) квартальную сеть части кварталов привязать\состыковать с кадастровыми границами З/У стоящих на кад учёте. Тупо менял границы земель лесного фонда... но тогда вся геометрия лесная... искажается. Нужна новая идея...

_________________
С уважением alek.cotov@yandex.ru

Это так. Но ведь и с данными о границах районов - такая же хрень, как с данными о границах лесничеств: в разных источниках они разные, а часто даже в одном официальном источнике (например, Публичной кадастровой карте) данные о границах соседних районов - тоже разные. Они просто расходятся, иногда на сотни метров или даже на километры. Так что и согласование лесоустроительных границ с землеустроительными во многих случаях ничего не даст - они, данные, могут быть сделаны под разные глобусы.

Это так… НО так не должно быть! :-((( Нужно за что то «заякарится»! Что бы геометрию к таксушкам привязывать. Или что то абсолютно другое нужно, те же гирды как пример. НЕ ЗНАЮ...А на счёт вот этого бардака с землями лесфонда… что делают «хитрые землеустраители» - продают участок. Покупатель ставит его на кад учёт. Со всеми сопутствующими расходами. А в кад паспорте ставится особая отметка: - ! Чел ни чего не подозревая, собирается строить дом, подаёт просьбу на получения градостраительного плана и получает отказ! Потому что часть его участка : - Каково!!! То есть чел деньги заплатил, а сделка с землями категории лесной фонд не действительны ...Здорово!

_________________
С уважением alek.cotov@yandex.ru