В те дни, когда я учился в университете, у меня была проблема «организация и порядок» - я был неорганизован и держал свои слои в разных папках без разных имен и, следовательно, имел несколько копий каждого слоя.
С тех пор, как я начал работать, я значительно улучшился - у меня есть специальные папки со специальными подпапками. Я называю свои слои в соответствии с системой, которая позволяет мне быть немного более аккуратной, но, поскольку мне все еще приходится управлять несколькими копиями слоев (поскольку Autocad и ArcGIS имеют свои различия при работе с нелатинскими языками, я должен сохранить копию с учетом каждой программы), я хотел бы услышать ваш опыт и, возможно, узнать несколько советов от вас:
- Как вы организуете свои слои? Как их назвать? По имени, дате, содержанию, клиенту?
- Как вы организовываете или имеете дело с несколькими копиями (более остро: как вы обновляете несколько копий одновременно)?
Примечание: я говорю от POV аналитика / DBA, а не от POV веб-разработчика / веб-менеджера (я говорю об организации слоев для себя и, возможно, еще двух сотрудников ГИС, не больше).
источник
Ответы:
Это злая проблема . Мы опробовали различные системы, которые все работали в разной степени в течение некоторого времени, и в конечном итоге стали громоздкими и начали разваливаться, поскольку встречаются все новые и крайние случаи, которые не совсем подходят. Тем не менее, каждая из систем, которые мы использовали, лучше, чем ничего, доказывая принцип, что любая система лучше, чем никакая система.
Вот краткий обзор нашей текущей практики:
Поместите все, кроме растров в файловую базу геоданных, чем меньше, тем лучше. Не вкладывайте классы объектов в наборы классов объектов, если они не связаны каким-либо образом (например, гидротоки, гидроузла, водно-болотные угодья и т. Д.). Это приводит к большому длинному списку наверху 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-страницей, которую можно нажимать, которая автоматически генерируется из приложения БД. Это целый другой проект.
Ключевые принципы:
Я очень приветствую примеры других структур, поскольку я сказал, что мы не довольны тем, что имеем. :)
источник
Если другие люди будут получать доступ к данным в вашей системе, вы не сможете сделать схему организации значимой только для себя; Вы должны помнить об их использовании системы. Если вы их не рассматриваете, вы будете тратить много времени на ответы на такие вопросы, как «где данные о землепользовании» и «почему я не могу найти [вставить набор данных здесь]?»
Поддерживая такую систему в течение многих лет, я обнаружил, что люди не могут найти данные, если они сначала организованы по источникам, например,
c:\CensusBureau\Roadsиc:\ESRI\Countries. Вместо этого я рекомендую сначала перечислить данные тематически, а затем по источникам, если у вас есть несколько источников, например,c:\Roads\CensusBureauиc:\Roads\LocalGovt.Точно так же я бы не разделял растры и векторы в разные каталоги. Однако может потребоваться разбить их на разные физические или логические диски, если у вас много растровых данных, которые не помещаются на один диск.
Я рекомендую следующую структуру каталогов. Theme \ SourceYear, где Theme - тематический слой, Source - сокращенное название источника данных, а Year - год, в котором данные представлены на местах. В этом сценарии дороги TIGER из Бюро переписей будут находиться в
\Roads\Census00и\Roads\Census10(или заменить «Census» на «TIGER»).Имейте в виду, что некоторые расширения в ArcGIS не работают с именами файлов длиннее 13 символов. Я не могу вспомнить, какое расширение, я просто помню, что это проблема.
источник
Мы работаем на уровне проекта для файлов CAD, полагаем, что это зависит от того, как настроен ваш конкретный рабочий процесс, у нас есть основной рабочий проект, а затем готовим любые дополнительные хранилища данных из этого в сценарии экспорта в конце сеанса редактирования.
datadir \ cad \
cadastre.dgn datadir \ srv \ fuel.dgn
datadir \ srv \ sewerage.dgn
datadir \ map \ base.dgn
datadir \ map \ printsets.dgn
...
тогда у каждого файла есть уровни / слои / объекты, названные с идентификатором
sewPipe
sewManhole
sewPit
...
Затем мы экспортируем все это в пространственный SQL, а не читаем файлы нашего рабочего проекта, где они отображаются пользователю через Mapguide или любое другое приложение ГИС.
Слои ГИС сортируются по имени объекта с идентификаторами и похожим макетом папки, что позволяет сортировать.
источник