Организация и порядок нескольких копий слоев? [закрыто]

28

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

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

  1. Как вы организуете свои слои? Как их назвать? По имени, дате, содержанию, клиенту?
  2. Как вы организовываете или имеете дело с несколькими копиями (более остро: как вы обновляете несколько копий одновременно)?

Примечание: я говорю от POV аналитика / DBA, а не от POV веб-разработчика / веб-менеджера (я говорю об организации слоев для себя и, возможно, еще двух сотрудников ГИС, не больше).

jonatr
источник
6
Хороший вопрос На самом деле это не вопрос, это квест. Вопрос приводит к единственному или узкому набору ответов, и как только он решен, все кончено. Квест - это постоянная вещь, приключение, которое никогда не может иметь окончательного конца, и это то, что у вас есть здесь. Смирись с правдой, что независимо от того, на каком соглашении ты согласен, оно не сработает полностью или тщательно. Тем не менее, существуют соглашения, которые вы можете использовать, чтобы сделать путь более плавным и легким. Ответ Кевина и последующие комментарии являются хорошим началом в этом отношении.
Мэтт Уилки

Ответы:

21

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

Вот краткий обзор нашей текущей практики:

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

Ключевые принципы:

  • отделяйте медленно меняющиеся и часто используемые вещи от динамических и переменных и относитесь к ним по-разному
  • Не дублируйте без необходимости, по возможности используйте файлы слоев и ярлыки / ссылки.
  • не меняйте системы слишком часто, дайте каждому основательную попытку.

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

Мэтт Уилки
источник
Вчера я слегка отчитал кого-то за то, что он опубликовал что-то слишком большое и длинное, и здесь я иду и делаю то же самое, просто без фотографий. Как вы думаете, что лучше представить сплоченное целое или разбить вещи на модульные части, каждая из которых может голосовать «за» или «против» по ​​своему собственному достоинству, но, возможно, сломать или скрыть свою интеграцию с другими? Поговорим об этом на мета: Длинный и сплоченный или короткий и модульный
Мэтт Уилки
Вау. Что за сквозная система подачи документов (я уже прочитал ее четыре раза, но до сих пор не уверен, что все понял). Два комментария, которые выделились для меня как связующего пользователя AutoCAD и ArcGIS: 1. Как мне вписать в эту систему хранилище DWG? 2. GeoDatabase - отличный способ сохранить организованность. Единственная проблема, которую я имею, состоит в том, что карта AutoCAD не видит GDB, а только шейп-файлы. Но спасибо, я приму советы от вашей тщательной системы ...
Jonatr
имейте в виду, что эта система становилась такой в ​​течение примерно 15 лет и приспособлена к тому, как мы работаем. Там должно быть несколько портативных элементов, хотя. Что касается взаимодействия с САПР, продолжайте в том же духе ESRI, чтобы выполнить свое обязательство по публикации открытого API в файловой базе геоданных .
Мэтт Уилки
1
То же самое относится к наборам классов объектов. Это какая-то бесполезная функция, кроме ArcCatalog. Предполагается, что они группируют слои общего пользования и пространственной привязки, но программист никогда не видит набор классов объектов, пока он не мешает циклически проходить по слоям в рабочей области. При использовании разных проекций отдельные базы данных кажутся лучше, чем наборы классов объектов.
Тим Рурк
1
@ Я полагаю, что наборы классов объектов являются концептуальным наследником покрытий ArcInfo, а именно они должны быть средством группировки разнородных типов геометрии, которые описывают общую «вещь», в одну корзину. Таким образом, вы можете иметь, например, водотоки (линии), водоемы (полигоны) и камни в воде (точки) вместе. Я не знаю, почему они не представлены более непосредственно программисту.
Matt Wilkie
6

Если другие люди будут получать доступ к данным в вашей системе, вы не сможете сделать схему организации значимой только для себя; Вы должны помнить об их использовании системы. Если вы их не рассматриваете, вы будете тратить много времени на ответы на такие вопросы, как «где данные о землепользовании» и «почему я не могу найти [вставить набор данных здесь]?»

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


источник
Спасибо, Кевин, как насчет соглашения об именах файлов? Я думаю, что решение, подобное <Object> _ <Location> _ <Range> _ <Date> _ <FileFormat> _ <Resolution>. <Ext> coast_eu_340509.76N0080201.23E_350509.76N_0090201.23E_2011_shp.zip box_eu_340509.76N0080201.23E_350509 .76N_0090201.23E_2011_tiff.zip. Как вы думаете, это правильная идея?
Джейд
5
Эти имена файлов могут стать очень громоздкими для использования в командной строке или в программе. Они также приведут к очень широкой таблице содержания и / или легенде в ArcMap (по крайней мере по умолчанию). Я бы выбрал более короткие имена файлов, например, просто объект или объект и дату, и использовал бы стандартные метаданные или, по крайней мере, файл readme для передачи остальной информации. Просто мое мнение.
4
Я согласен с Кевином. В моей нынешней компании существует устаревшее соглашение об именах файлов (которое я нахожусь в процессе изменения), которое обязывает искать имена файлов, и это очень громоздко по причинам, упомянутым Кевином. Два дополнительных соображения 1) Многое из того, что у вас есть в имени файла, может быть разбито на папки и отсортировано в структуре файла, а не в имени файла; 2) множественные точки / точки (.) В имени файла могут вызвать проблемы с доступом к файлам через определенное программное обеспечение и / или программно. обычно символы после (.) являются расширением файла, а не дополнительными компонентами имени файла.
hgil
2

Мы работаем на уровне проекта для файлов 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 или любое другое приложение ГИС.

Слои ГИС сортируются по имени объекта с идентификаторами и похожим макетом папки, что позволяет сортировать.

Jamo
источник