Combien de couches sont trop de couches dans ArcMap?


12

Je travaille sur ArcGIS en utilisant une connexion logicielle virtuelle Citrix au travail. Il est parfois terriblement lent et sans aucune modification des MXD sur lesquels je travaille, ArcMap peut fonctionner à une vitesse raisonnable pendant une minute, puis la minute suivante, il peut ralentir jusqu'à une exploration. Le service informatique estime que la cause du problème est trop de couches sur ma carte. J'ai le pressentiment que le problème peut plutôt être des configurations matérielles ou logicielles, ou simplement le fait que nous utilisons Citrix en premier lieu.

Quoi qu'il en soit, j'ai, dans mon MXD standard que j'utilise pour l'édition, 57 couches SDE et 2 couches de géodatabase fichier. La grande majorité sont des calques que je dois vérifier pour l'édition. Je dois vérifier pour voir s'il existe des données pour chacune des couches, car elles doivent être modifiées et contrôlées pour chaque projet de construction de pipeline. Seules quelques couches sont des couches de fond de carte auxquelles je dois faire référence régulièrement.

Le service informatique veut que je réduise le nombre de couches que j'utilise à 10. Dans un monde idéal, ce serait bien. Mais dans le monde réel, ce n'est pas pratique. Avec une telle suggestion, je vais devoir utiliser environ 5 MXD différents juste pour effectuer une tâche d'édition pour un projet donné. J'ai expérimenté avec seulement 10 couches et c'est très limitant. Je manque le contexte de mes données par rapport aux autres données, et je dois revoir la même zone plusieurs fois juste pour m'assurer que toutes les données ont été mises à jour. Tout cela pour seulement une légère amélioration des performances et une modeste réduction du nombre de plantages lors de l'édition.

Je dois donc demander, existe-t-il un nombre idéal de couches? Combien c'est trop?


1
Pouvez-vous essayer d'exécuter exactement le même MXD en dehors de l'environnement Citrix? Cela peut aider à déboguer si le problème vient du MXD ou de Citrix. De plus, lorsque vous avez expérimenté avec seulement 10 couches, cela a-t-il résolu le problème? Le problème pourrait-il être causé par une seule couche problématique plutôt que par le nombre de couches?
Stephen Lead

1
Votre premier paragraphe ressemble à une utilisation quotidienne typique d'ArcMap pour moi, peut-être aggravée par la configuration de Citrix. Il n'est pas exactement connu pour ses performances, selon mon expérience. Le verrouillage est un phénomène fréquent.
jpmc26

Réponses:


11

J'avais l'habitude de travailler dans ce même environnement (exactement le même!). Je n'ai pas fait de test de référence, mais mon sentiment est que le nombre de couches dans le projet n'a pas beaucoup d'effet en soi.

D'après mon expérience, l'étiquetage et le nombre de fonctionnalités est un problème beaucoup plus important que le nombre de couches (surtout si beaucoup sont désactivées). J'avais l'habitude d'avoir la barre d'outils d'étiquetage activée et interrompais souvent l'étiquetage. Cela semble améliorer considérablement les performances. Le fait d'avoir des couches dans le projet qui n'étaient pas contrôlées dans la table des matières ne semble avoir aucun effet négatif sur les performances. Je peux me tromper, mais l'OMI le nombre de couches est une sorte de hareng rouge.

Ma recommandation est de suspendre l'étiquetage (qui est l'approche la plus pratique) ou de désactiver complètement l'étiquetage des fonctionnalités.


1
Merci pour la suggestion de suspendre l'étiquetage. C'est une chose que j'ai ignorée. J'ai également désactivé MapTips dans mon MXD d'édition avec l'espoir que cela pourrait améliorer les performances.
Zachary Ordo - GISP

9

Je voudrais d'abord consulter les meilleures pratiques d'utilisation de Citrix XenApp et ArcGIS , un guide mis en place par ESRI.

Pour un client précédent, j'ai effectué pas mal de dépannage de performances avec ESRI et notre environnement Citrix. Voici les points saillants de ces conversations:

Je suppose que vous allez effectuer des modifications dans une zone restreinte (zoom avant assez proche). La configuration de votre carte de sorte que la plupart de ces couches soient désactivées jusqu'à ce que vous zoomiez près de ce niveau améliore les performances.

MXD Doctor est quelque chose d'autre que vous voudrez peut-être exécuter pour voir quels éléments peuvent causer des problèmes.

Assurez-vous qu'ArcGIS est réellement installé sur le serveur Citrix lui-même et pas seulement en miroir ou en streaming.

Notre ralentissement le plus important semble provenir des imprimantes - une fois que nous avons désactivé les capacités de l'imprimante (et la connexion automatique), nous nous sommes connectés beaucoup plus rapidement et nous avons remarqué moins de temps de latence (voir ce bulletin ESRI pour plus d'informations) . Cependant, cela nous a obligé à exporter nos cartes au format PDF, puis à les imprimer, mais avec 90% de notre travail étant l'édition et l'analyse, personne ne semblait s'en préoccuper.

59 couches, c'est beaucoup, si vous êtes en mesure de le faire tomber, cela aiderait. Comme suggéré par @jbchurchill, jetez un œil à votre étiquetage. Vous devez également examiner toute symbologie personnalisée que vous pourriez avoir.


5

J'ai une certaine expérience de dépannage des performances dans les systèmes SIG, y compris sur citrix. Votre problème peut être n'importe où et probablement une combinaison de facteurs. Parlez à votre représentant Esri pour obtenir des conseils.

Je vous recommande de lire ceci: http://www.wiki.gis.com/wiki/index.php/Software_Performance#Use_MXDPerfStat_to_measure_display_complexity

L'étiquetage, l'utilisation du cache de fonctionnalités et des fonds de carte mis en cache sont toutes de bonnes pratiques.

Il existe également un outil plus récent que vous pouvez essayer, plus convivial, appelé perfqanalyzer https://blogs.esri.com/esri/supportcenter/2014/02/03/calibrating-arcgis-performance-with-perfqanalyzer-new-build- disponible pour le téléchargement/


1

Je pensais juste sauter dans le coup que je travaille dans une entreprise qui a une mauvaise pratique avec les MXD les utilisant comme presque des serveurs de fichiers pour les données. Pour vous donner une idée, nous avons des MXD avec plus de 1000 couches. Nous avons travaillé avec certains consultants qui ont recommandé 650 ms par couche pour qu'une carte soit ouverte, ce qui signifie que certains peuvent prendre 14 minutes pour s'ouvrir pour nous! Ce n'est pas bon et ce n'est certainement pas optimal mais je voulais vous faire savoir qu'il y en a d'autres que de souffrir aussi!

Nous avons récemment déménagé à EGDB et cela a frappé les performances massivement. J'ai trouvé que l'activation de la mise en cache des fonctionnalités faisait une grande différence et garantissait une maintenance correcte de l'EGDB (analyse, indexation, compression, etc.)

Je seconde MXD Doctor pour supprimer tous les anciens chemins de connexion aux données, essayez de supprimer la carte de modèle. MXD perf stat est un outil puissant que je sens que je n'ai pas utilisé à moitié en raison de mon manque de compétences en cmd.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.