Скільки шарів занадто багато шарів у ArcMap?

Я працюю над ArcGIS, використовуючи підключення віртуального програмного забезпечення Citrix на роботі. Часом це страшенно повільно, і без будь-яких змін MXD, над якими я працюю, одна хвилина ArcMap може працювати з розумною швидкістю, а потім наступної хвилини вона може сповільнитись до повзання. Департамент ІТ вважає, що причиною проблеми є занадто багато шарів на моїй карті. Я маю на увазі, що проблема може бути замість апаратних чи програмних засобів або просто тим, що ми використовуємо Citrix в першу чергу.

У моєму стандартному MXD, який я використовую для редагування, у мене є 57 шарів SDE та 2 файлові шари геоданих. Переважна більшість - це шари, які мені потрібно перевірити на редагування. Я повинен перевірити, чи існують якісь дані для кожного з шарів, оскільки вони потребують редагування та QC'd для кожного проекту будівництва трубопроводу. Лише кілька шарів - це основні шари, на які мені потрібно регулярно посилатися.

ІТ-відділ хоче, щоб я зменшив кількість шарів, які я використовую, до 10. В ідеальному світі це було б добре. Але в реальному світі це не практично. З такою пропозицією мені доведеться використовувати кілька різних MXD, щоб виконати завдання редагування для даного проекту. Я експериментував із використанням лише 10 шарів, і це сильно обмежує. Мені не вистачає контексту моїх даних стосовно інших даних, і мені доведеться повторно переглядати ту саму область, щоб переконатися, що всі дані були оновлені. Все це лише для незначного покращення продуктивності та незначного зменшення кількості збоїв під час редагування.

Тож я повинен запитати, чи існує ідеальна кількість шарів? Скільки занадто багато?

Раніше я працював у такому ж середовищі (точно такому ж!). Я не робив жодного тестового тестування, але я розумію, що кількість шарів у проекті не має великого ефекту сама по собі.

На мій досвід, маркування та кількість особливостей є набагато більшою проблемою, ніж кількість шарів (особливо якщо багато вимкнено). У мене раніше була включена панель інструментів для маркування і часто призупиняла маркування. Це, здається, покращує результативність неймовірно. Наявність шарів у проекті, які не були перевірені в TOC, здається, не має негативного впливу на продуктивність. Я можу помилитися, але кількість IMO кількість шарів - це червона оселедець.

Моя рекомендація - призупинити маркування (що є найзручнішим підходом) або взагалі вимкнути маркування функцій.

Я спершу перевірив кращі практики використання Citrix XenApp та ArcGIS , керівництва, складеного ESRI.

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

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

MXD Doctor - це щось інше, про що ви можете запустити, щоб побачити, які елементи можуть спричинити проблеми.

Переконайтеся, що ArcGIS фактично встановлений на самому сервері Citrix, а не просто дзеркально чи потоково.

Наше найбільше сповільнення, здавалося, було спричинене принтерами: коли ми відключили можливості принтера (та автоматичне підключення), ми зв’язалися набагато швидше та помітили менше часу затримки (див. Цей інформаційний бюлетень ESRI для отримання додаткової інформації) . Однак це зробило так, що нам довелося спочатку експортувати наші карти в pdf, а потім надрукувати, але, оскільки 90% нашої роботи редагували та аналізували, ніхто, мабуть, не заперечував.

59 шарів - це досить багато, якщо ви зможете збити це, це допоможе. Як запропонував @jbchurchill, погляньте на свою маркування. Ви також повинні ознайомитись із будь-якою власною символікою.

Я маю певний досвід виправлення неполадок у системах ГІС, в тому числі на 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- доступно для завантаження /

Я просто подумав, що підскочу, що працюю в компанії, яка має погану практику з MXD, використовуючи їх як майже файлові сервери для даних. Щоб дати вам уявлення, у нас є MXD з більш ніж 1000 шарами. Ми працювали з деякими консультантами, які рекомендували 650 м на кожен шар, щоб відкрити карту, це розумно, це означає, що деякі можуть зайняти 14 хвилин, щоб відкрити для нас! Це не добре і, безумовно, не є оптимальним, але я хотів повідомити вам, що є й інші, ніж страждаєте!

Нещодавно ми перейшли до EGDB, що масово вразило виступи. Я виявив, що ввімкнення кешування функцій значно відрізняється разом із забезпеченням належного обслуговування EGDB (аналіз, індекси, стиснення тощо)

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