Сколько слоев - это слишком много слоев в ArcMap?


12

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

В любом случае, в моем стандартном MXD, который я использую для редактирования, есть 57 слоев SDE и 2 слоя файловой базы геоданных. Подавляющее большинство - это слои, которые мне нужно проверить для редактирования. Я должен проверить, существуют ли какие-либо данные для каждого из слоев, потому что они должны быть отредактированы и проверены для каждого проекта строительства трубопровода. Только несколько слоев являются слоями базовой карты, на которые я должен ссылаться на регулярной основе.

ИТ-отдел хочет, чтобы я сократил количество слоев, которые я использую, до 10. В идеальном мире это было бы хорошо. Но в реальном мире это не практично. С таким предложением мне придется использовать около 5 различных MXD, чтобы выполнить задачу редактирования для данного проекта. Я экспериментировал с использованием только 10 слоев, и это сильно ограничивает. Мне не хватает контекста моих данных по отношению к другим данным, и мне приходится многократно посещать одну и ту же область, чтобы убедиться, что все данные были обновлены. Все это лишь для небольшого улучшения производительности и небольшого снижения количества сбоев при редактировании.

Поэтому я должен спросить, есть ли идеальное количество слоев? Сколько это слишком много?


1
Можете ли вы попробовать запустить тот же MXD вне среды Citrix? Это может помочь отладить, является ли проблема с MXD, или с Citrix. Кроме того, когда вы экспериментировали только с 10 слоями, это решило проблему? Может ли проблема быть вызвана только одним проблемным слоем, а не количеством слоев?
Стивен Лид

1
Ваш первый абзац звучит для меня как обычное повседневное использование ArcMap, может быть, еще хуже из-за настройки Citrix. По моему опыту, он не совсем известен своей производительностью. Запирание - частое явление.
jpmc26

Ответы:


11

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

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

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


1
Спасибо за предложение приостановить маркировку. Это одна вещь, которую я упустил. Я также отключил MapTips при редактировании MXD в надежде, что это поможет повысить производительность.
Захари Ордо - GISP

9

Сначала я бы ознакомился с рекомендациями по использованию Citrix XenApp и ArcGIS , руководства, составленного ESRI.

Для предыдущего клиента я прошел немало проблем с производительностью с помощью ESRI и нашей среды Citrix. Ниже приведены основные моменты этих разговоров:

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

MXD Doctor - это еще кое-что, что вы можете запустить, чтобы посмотреть, какие предметы могут вызывать проблемы.

Убедитесь, что ArcGIS действительно установлен на самом сервере Citrix, а не просто зеркально отображен или передан в потоковом режиме.

Наше наибольшее замедление, по-видимому, было вызвано принтерами - как только мы отключили возможности принтера (и автоподключение), мы подключились намного быстрее и заметили меньшее время задержки (см. Этот информационный бюллетень ESRI для получения дополнительной информации) . Это, однако, сделало так, что мы сначала должны были экспортировать наши карты в pdf, а затем распечатать, но с 90% нашей работы, связанной с редактированием и анализом, никто не возражал.

59 слоев - это довольно много, если бы вы могли его сбить, это помогло бы. Как подсказывает @jbchurchill, взгляните на свою маркировку. Вы также должны взглянуть на любые пользовательские символы, которые у вас могут быть.


5

У меня есть некоторый опыт устранения неполадок производительности в ГИС-системах, в том числе на Citrix. Ваша проблема может быть где угодно и, вероятно, комбинация факторов. Поговорите с вашим представителем Esri для указателей.

Я рекомендую вам прочитать это: http://www.wiki.gis.com/wiki/index.php/Software_Performance#Use_MXDPerfStat_to_measure_display_complexity

Надписи, использование кэша компонентов и кэшированных базовых карт - все это хорошие практики.

Существует также более новый инструмент, который вы можете попробовать, который является более удобным для пользователя, и называется perfqanalyzer https://blogs.esri.com/esri/supportcenter/2014/02/03/calibrating-arcgis-performance-with-perfqanalyzer-new-build- имеющиеся в наличии для загрузки /


1

Просто подумал, что пойду, что работаю в компании, которая плохо работает с MXD, используя их в качестве почти файловых серверов для данных. Чтобы дать вам представление, у нас есть MXD с более чем 1000 слоями. Мы работали с некоторыми консультантами, которые рекомендовали 650 мс на слой для открытия карты, это разумно, то есть некоторым может потребоваться 14 мин, чтобы открыть для нас! Это не хорошо и определенно не оптимально, но я хотел сообщить, что есть и другие, которые тоже страдают!

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

Я второй врач MXD, чтобы удалить все старые пути, соединяющие данные, попробуйте удалить карту шаблона. MXD perf stat - это мощный инструмент, который, как мне кажется, я использовал не наполовину из-за отсутствия навыков работы с cmd.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.