Есть. Некоторые держат арендаторов в 004. 002 исторически был, кажется за Минлеспромом или Минобороной. Но, вообще, это Ваш функционал. У нас нет систематизированных данных.

Разделы мы предполагаем использовать для ведения БД по годам актуализации.

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

А вообще, коллеги, такие вопросы нужно было поднимать года 4 назад и обсуждать, когда первые версии выходили. На законченных продуктах букву А алфавита, обычно, не пересматривают. )

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

слева на право* (опечатка)

Не понял, это как по "координатам окна из каталога"?

Сформировать данные отчётности по годам можно и без разделов по годам. Для этого есть инструменты для выборки и формирования всех необходимых данных через поле базы данных "Год лесоустройства".

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

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

Если проблема в модуле Лесосек, то и писать нужно про неё. А не про весь интерфейс.

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

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

По поводу F001, F002, ... : как это предполагалось - здесь описали, избавиться от этого уровня можно, а если где-то будут у разных владельцев (арендаторов, военлеса) совпадающие по остальным идентификаторам объекты, то использовать верхнюю цифру номера или разнести базы в разные разделы. Разделы придумывались не строго, как годовые, их можно трактовать более широко.

Перейти на систему имен типа D:\LesIS\2011\R019\L021U009_Vyd.blk, то есть без дублирования идентификаторов в пути к файлам, мы можем, в целом понятно, как с этим работать (но длина группы R019 для универсальности алгоритма должна быть везде одинаковой).  Но сразу возникает необходимость изменения дерева блоков - отсутствующий идентификатор региона придется внести в дерево карты, иначе обязательно когда-нибудь появятся одинаковые по имени блоки из двух регионов.
Буква из идентификатора в программном коде активно используется, от нее мы уходить не будем.

Меня, как разработчика, волнует еще проблема организации системной части данных, которые в каталогах _Les и __Sis, мне не очень нравится, как в итоге получилось. Жду предложений по усовершенствованию.
Много проблем создает восстановление пользователями архивных баз со старыми параметрами, например, запросов, отчего потом идут ошибки у пользователя.  Сейчас я постепенно переношу запросы из ParametryR.mdb в другие места, чтобы нивелировать эту проблему (и запросов, и мест, много). Но это лишь частное решение по конкретной проблеме.

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

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

Оказывается, Вы тоже ещё не всё знаете. В меню TopoL-я:
"Проект / Свойства проекта", в диалоге в дереве "Другие настройки", там справа есть "Каталог с растрами".
Настраиваете на каталог, где лежат растры к этому объекту, региону.

Далее уже во время работы нажимаете кнопочку "Растры из каталога с учетом вида карты" или Ctrl-U - TopoL берет параметры текущего окна карты, определяет, какие растры из настроенного Вами каталога попадают в окно и загружает / подключает только их. Останется только перерисовать карту.

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

Простите, что ответ выпадает из тематики раздела.

Отредактировано Дмитрий Александрович (03.05.2017 14:29:14)

Юра,  Дмитрий Александрович, всё в порядке. Думал, пропустил какую-то новую функцию, а то последнее время не успеваю следить за всеми нововведения... Я в курсе такой функции. Инструкцию "as is" юзаю на чешском. Не применял на производстве ввиду ввода системы каталогов для объекта таксации.

Мы немного отклонились от темы.
Но растры, тем более разного типа, в одной папке хранить не буду, не убедите. Только диск D или E для работы: КС отдельно, АФС отдельно (если будут), топокарты отдельно, планы земель отдельно.
Если бы я делал полностью весь объём работ по нескольким объектам ЛУ, то возможно рассмотрел бы такой вариант - всё вместе в одной папке. А так как это просто физически невозможно, то работу раздаю инженерам. Для этого необходимо  подобрать базовый объём данных: vd, vdL, КС и т.д. И выдернуть эти данные легче именно из разных папок. И систематизацию пришлось организовывать под это. Основной каталог  - 02 или 25 (по номеру лесхоза), а остальное всё внутри.

А кнопкой Page Down не пробовали пользоваться?  Или Ctrl-F - поиск по странице? Где то в ее середине сможете найти.

Согласен. Я с одним проектом работать просто не могу а раскладывать их надо по структуре. Так же надо разложить по полкам планы и планшеты и схемы. Растры.

Тут не согласен. Опыт показывает лучше называть хотя бы Vd-01. Открываем несколько Vd на лесничество и никакого пути мы не видим. Копировать блок - не понятно. Копировать линии - непонятно т.д. И главное короче имя самого блока. Это моё мнение.
А таксаторам вообще не важно как он называется. Он сидит в своем блоке который открывает по названию. Главное чтобы программа работала правильно.