Utilisation des classes d'étiquettes et des requêtes de définition - quelle est la meilleure?


11

Lequel fournirait les meilleures performances pour travailler dans ArcMap avec de très grands ensembles de données stockés dans une géodatabase ArcSDE? Plusieurs classes d'étiquettes utilisant des requêtes SQL complexes pour étiqueter des fonctionnalités spécifiques, ou plusieurs copies de la même couche en utilisant les mêmes requêtes SQL complexes définies comme une requête de définition pour chaque couche?


2
Je pense que "plusieurs copies de la même couche chacune avec leur propre requête de définition et un étiquetage basé sur un champ simple" seront les préférées, mais je n'ai pas de métriques pour sauvegarder ce sentiment d'intestin, donc je pense que c'est une excellente question. Une classe d'entités de géodatabase fichier avec un million de polygones serait-elle considérée comme un très grand ensemble de données dans votre langage?
PolyGeo

Réponses:


5

En supposant que les requêtes SQL sur les classes d'étiquettes sont les mêmes que celles sur les couches fractionnées, l'approche à couche unique avec plusieurs classes d'étiquettes sera plus rapide. Pourquoi?:

L'étiquetage dans ArcMap exécutera une requête pour le dessin de couche, puis une requête pour chaque classe d'étiquettes. Ainsi, une couche avec 4 classes d'étiquettes interrogera une fois (1 requête) toutes les entités dessinées, puis 4 fois au total (une pour chaque classe d'étiquettes ou 4 requêtes supplémentaires) = 5 requêtes totales

Si vous divisez les couches, vous aurez 1 requête filtrée (requête de définition) pour chaque couche (4 requêtes) plus cette même requête pour chaque classe d'étiquette (4 requêtes supplémentaires) = 8 requêtes totales

Dans presque tous les cas, 5 requêtes seront plus rapides que 8 requêtes en raison de la surcharge des requêtes, même si cela dépend de la source de données.

Remarque: dans ArcGIS Server, un cache est utilisé pour l'étiquetage d'entités et 1 couche avec 4 classes d'étiquettes sera très probablement gérée via une seule requête lorsque les classes d'étiquettes utilisent du SQL assez standard sans fonctions spécifiques au fournisseur.


2
Mais, avec le scénario de requête de définition, je ne créerais pas de classes d'étiquettes. Ils seraient simplement étiquetés en fonction d'une seule valeur de champ. Ou suis-je en train de lire le troisième paragraphe incorrectement?
ianbroad

Les classes d'étiquettes sont utilisées pour étiqueter un sous-ensemble d'entités définies par une clause SQL where (exactement la même chose qu'une requête de définition) et ont leur propre symbole de texte, expression d'étiquette et règles de placement. D'après votre description, je ne comprends pas comment le passage de classes à une requête de définition vous permet d'étiqueter uniquement sur un seul champ. Faites-vous référence à des expressions d'étiquette complexes et non à des requêtes SQL complexes?
Craig Williams

1
Non, je veux juste dire que pour les deux scénarios, aucun n'utilise une expression d'étiquette. Les deux sont étiquetés à l'aide d'un seul champ.
ianbroad

4
Je travaille dans l'équipe d'étiquetage chez Esri. Je connais intimement comment cela fonctionne. L'appel de l'emplacement de la requête n'affectera pas les performances, mais vous souhaiterez réduire le nombre total de requêtes.
Craig Williams

1
Je pense que je comprends votre réponse maintenant Craig, mais je me demande s'il existe un moyen de la reformuler pour la rendre plus facile à comprendre. J'ai dû le lire plusieurs fois pour réaliser que vos calculs ne sont probablement pas faux, comme moi et d'autres l'avions d'abord pensé.
jmpreiks

2

J'ai effectué quelques tests très simples en utilisant des données NHD provenant d'une connexion SDE et j'ai trouvé très peu de différence entre les deux méthodes.

  1. 7 classes d'étiquettes dans une seule couche, également 7 symbologies distinctes: 36 secondes
  2. 7 couches séparées avec des requêtes de définition, une seule classe d'étiquettes dans chacune sans requête: 37 secondes

Quelques mises en garde:

  1. Mon test était très simple avec des étiquettes simples et des requêtes simples, des requêtes complexes devraient être testées car cela faisait partie de la question.
  2. Environ un tiers du temps total était consacré au dessin de la symbologie.
  3. Mon timing était avec un chronomètre, donc la marge d'erreur est assez grande.

+1 pour vos tests. Je me demande si cela fait une différence si des conflits d'étiquettes se produisent ou non? Vous pouvez peut-être agrandir la taille de la police pour que beaucoup d'étiquettes se chevauchent. Désactivez ensuite l'option placer les étiquettes qui se chevauchent. Y a-t-il une différence maintenant?
Jens

1
En fait, il y avait beaucoup de conflits d'étiquettes dans mes tests parce que je devais montrer une grande partie pour obtenir un temps de traitement très long que je pouvais facilement mesurer.
jmpreiks

1
Il n'y a rien de tel que «pas de classes d'étiquettes» car il y en a toujours une.
Craig Williams du

Vrai Craig, j'ai édité ma réponse pour clarifier.
jmpreiks

1

Je pense que la requête de définition serait plus rapide car elle se situe au niveau de l'objet et non au niveau des données d'attribut.

Vous auriez encore à tester. Cependant, j'utiliserais des requêtes de définition et non des classes d'étiquettes.


1
Oui, veuillez tester (et faire un rapport si vous le pouvez). Je me penche également sur les requêtes de définition, mais pour des raisons de performances d'utilisation. Les boîtes de dialogue d'expression d'étiquette sont douloureusement lentes et plusieurs couches de clic plus profondes que celles de la requête def. Ils sont également plus faciles à obtenir en python.
matt wilkie

Je ne pense pas que cela puisse être considéré comme une réponse sans une sorte de base technique ou de tests quantitatifs. Cela pourrait induire certaines personnes en erreur. Il aurait été préférable de commenter la question d'origine.
jmpreiks

Je l'aurais fait si j'avais eu la capacité de commenter. Merci pour le vote négatif. J'essaie juste d'aider.
geogeek
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.