Это злая проблема . Мы опробовали различные системы, которые все работали в разной степени в течение некоторого времени, и в конечном итоге стали громоздкими и начали разваливаться, поскольку встречаются все новые и крайние случаи, которые не совсем подходят. Тем не менее, каждая из систем, которые мы использовали, лучше, чем ничего, доказывая принцип, что любая система лучше, чем никакая система.
Вот краткий обзор нашей текущей практики:
Поместите все, кроме растров в файловую базу геоданных, чем меньше, тем лучше. Не вкладывайте классы объектов в наборы классов объектов, если они не связаны каким-либо образом (например, гидротоки, гидроузла, водно-болотные угодья и т. Д.). Это приводит к большому длинному списку наверху fgdb, но это приемлемое зло.
Создайте файлы слоев для всех классов объектов и упорядочите их, что дает большую свободу именования по мере необходимости, с использованием неподдерживаемых символов и т. Д. *, А также возможность перемещения и переименования при изменении обстоятельств. Это также позволяет дублирование без избыточности, например, один набор слоев, сгруппированных по номинальной шкале (50k, 250k ...), другой по регионам (AK, YT ...), третий по темам (карибу, землепользование, транспорт ...) и четвертый клиентом, а само хранилище данных остается неизменным.
Для дубликатов используйте ярлыки вместо самих файлов слоев, иначе будет слишком много вещей, которые нужно обновить, когда они изменятся. Настройте ArcCatalog для отображения ярлыков: * Инструменты> Параметры> типы файлов: .lnk (Ограничения: предварительный просмотр и метаданные не работают, вы не можете использовать ярлык к его источнику в ArcCatalog. Это можно исправить с помощью символических ссылок вместо ярлыков см. Расширение Link Shell )
* (совет: добавьте папку «Слои» в качестве панели инструментов меню «Пуск», чтобы они всегда были у вас под рукой.)
Z: \ Layers \
База\
Тематический \
Ссылка\
Все одеты базы (250k) .lyr
Администрация Границы (1000к) .лыр
...
Z: \ Raster \
Landsat \
Orthos \
Z: \ Data \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Композиции карты и выходные данные (файлы печати, PDF-файлы, экспорт и т. Д.), Которые по своей природе являются более динамичными и переменными, хранятся и организуются иначе в другом месте Это та часть, которая была для нас труднее. В настоящее время мы используем выделенный диск с папками, названными в соответствии с Job # (делая это снова, я бы использовал дату вместо '2010-10-26' ) и подпапками для конкретных данных проекта и результатов / обсуждений. Индекс электронной таблицы перечисляет все номера работ (имя папки), соответствующие им названия карт и клиентов. Пример:
W: \ Foo_0123 \
Foobarmap_001.mxd
Docs \
readme.doc
Данные\
buffers_2000m.shp
gps_tracks.csv
Выход\
Foobarmap_001.pdf
Практические результаты
Поддержание индекса в актуальном состоянии - это проблема, люди не любят это делать, избегают этого, не согласуются с именами и т. Д. (Использование базы данных вместо электронной таблицы поможет). Использование соглашения о числовых именах папок также очень затрудняет отображение проекта X без индекса, еще одного заметного источника трения. В идеале индекс должен быть HTML-страницей, которую можно нажимать, которая автоматически генерируется из приложения БД. Это целый другой проект.
Ключевые принципы:
- отделяйте медленно меняющиеся и часто используемые вещи от динамических и переменных и относитесь к ним по-разному
- Не дублируйте без необходимости, по возможности используйте файлы слоев и ярлыки / ссылки.
- не меняйте системы слишком часто, дайте каждому основательную попытку.
Я очень приветствую примеры других структур, поскольку я сказал, что мы не довольны тем, что имеем. :)