La dissolution des fonctionnalités améliore-t-elle l'efficacité du géotraitement?


9

J'ai un grand ensemble de données de ligne (> 140 000 fonctionnalités). Existe-t-il un avantage de traitement, en termes de temps requis ou (plus important) de mémoire utilisée:

  • exécuter Dissolve sur les données avant d'exécuter Buffer ?
  • exécuter Dissolve sur les entrées de deux opérations d' identité ?

J'attendrais généralement jusqu'à ce que tout le géotraitement soit terminé, puis j'effectuais une fusion à la fin. Cependant, je débogue le très vieux script de quelqu'un d'autre, et je ne sais pas s'il dissolvait tout à plusieurs reprises pour une raison (de retour dans Arc 9.3), ou s'il ne pensait tout simplement pas aux alternatives. (Le même script projette à plusieurs reprises des données entre les outils de géotraitement, de sorte que la logique est déjà discutable.)


Je n'ai pas de données matérielles pour sauvegarder cela, mais d'après mon expérience personnelle: toujours tamponner avant une dissolution si possible, car la mise en mémoire tampon d'une fonctionnalité de ligne aussi complexe prend une éternité effrayante.
nmpeterson

Réponses:


9

Si l'utilisation de la mémoire est votre principale préoccupation, alors beaucoup de petites fonctionnalités (faible nombre de sommets) seront probablement plus à votre goût que quelques très grandes (nombre élevé de vertex). Mais vous constaterez peut-être que «trop de fonctionnalités» peuvent éventuellement dépasser même «trop de sommets» pour la vitesse de traitement.

Si vous réfléchissez à la façon dont les algorithmes doivent être structurés pour traiter toutes les entités par rapport à toutes les entités entre deux classes d'entités, vous travaillez avec des boucles imbriquées à plusieurs reprises (pour les entités dans FC1 et FC2, et pour les sommets dans Feature1 et Feature2). Dans des opérations comme le dessin, le nombre de demandes de dessin est souvent plus préoccupant que les sommets de chaque demande, mais avec des opérations thème par thème, les algorithmes clés sont susceptibles d'être basés sur le nombre de sommets dans chaque paire F1 / F2. , avec une " grande notation O " de "O (N * M)" (le temps nécessaire pour terminer l'opération est lié au facteur du nombre de sommets impliqués), qui, pour les grandes entités des deux jeux de données, est assez proche de O (N ^ 2) pour vous faire craindre que le travail ne soit jamais terminé.

J'ai réussi à superposer des fonctionnalités massives (comme la Russie, le Canada, les États-Unis, l'Australie, le Brésil, la Norvège) avec une grille à 5 degrés (résille) pour réduire la complexité des fonctionnalités pour le traitement intermédiaire. J'ai vu des opérations de point dans un polygone sur une couche COUNTRIES 1: 15m limitée aux sommets s'exécuter 100 à 1000 fois plus rapidement que la table d'origine (avec seulement une augmentation du nombre d'entités de 20x). Cependant, vous devez être prudent dans votre logique de traitement pour gérer correctement les relations un-à-plusieurs et plusieurs-à-plusieurs, en particulier dans les cas où une fausse limite existe.

Il y a aussi un aspect "rendements décroissants" dans les économies de travail avec des fonctionnalités plus petites - je me suis installé sur une grille à 5 degrés en testant les performances de l'intersection avec 90, 45, 30, 20, 15, 10, 5, 3, 2 et Grilles à 1 degré, qui ont montré une augmentation alarmante du temps de traitement lorsque le nombre de fonctionnalités totales a augmenté.

Il y a des moments où moins de fonctionnalités avec plus de sommets sont plus efficaces, il vaut donc probablement la peine de faire des tests sur l'ordre de fonctionnement avec des données réelles (sous-ensembles de tests non simplifiés) avant de s'engager dans une approche par rapport à l'autre (équilibrer l'utilisation de la RAM avec Durée).

REMARQUE: J'ai relancé l'exercice de maillage avec du matériel moderne et obtenu des performances optimales avec une superposition de 30 degrés, ce qui augmente le risque de fonctionnalités trop petites et augmente l'importance de l'évaluation avec les données de production.


10

Une Dissoudre opération réduira généralement le nombre de caractéristiques, des arcs et des noeuds dans une couche, en particulier pour les couches avec des longueurs importantes des limites partagées. Étant donné que le temps passé pendant une opération de mise en mémoire tampon dépend fortement du nombre de nœuds, le prétraitement avec Dissolution peut réduire considérablement le temps d'exécution (et les besoins en mémoire). Que cela soit utile ou non dans votre cas dépendra de la mesure dans laquelle vous pourrez réduire le nombre de nœuds (en fonction de votre couche de données) et de l'efficacité de l' opération Dissoudre par rapport à la mise en mémoire tampon . D'après mon expérience, en utilisant Java Topology Suite, une opération de fusion peut être assez rapide par rapport àMise en mémoire tampon , bien que les performances de Dissolve varient considérablement selon la bibliothèque. L'autre considération est que Dissoudre est fortement affecté par les erreurs topologiques. Si votre calque contient des erreurs, vous devrez effectuer un nettoyage vectoriel avant l'opération de fusion, ce qui augmentera la durée d'exécution du flux de travail.


2
Je ne suis pas sûr de la partie "mémoire requise". Les fonctionnalités plus grandes nécessitent plus de stockage. La mise en mémoire tampon de fonctionnalités très complexes est plus difficile (et gourmande en RAM) que la mise en mémoire tampon de fonctionnalités simples. Il est plus probable qu'il y ait un "point idéal" entre "trop ​​de fonctionnalités" et "trop ​​de sommets par fonctionnalité" que de faire une affirmation générale que la dissolution en premier améliorera toujours les performances du tampon.
Vince

@Vince, je conviens que l'effet de la dissolution est beaucoup plus efficace pour réduire le temps d'exécution plutôt que la mémoire, mais finalement si un groupe de fonctionnalités a moins de fonctionnalités avec moins de nœuds au total, il faudra moins de mémoire pour représenter.
WhiteboxDev

Cela réduira la mémoire totale, mais pas la mémoire par fonctionnalité. Selon mon expérience, effectuer des opérations de géotraitement sur des entités massives et complexes prend plus de temps que sur des entités plus simples - et pas seulement de manière linéaire.
nmpeterson

@Vince, Dissolve également, en fonction de la couche, entraînera moins de fonctionnalités plus grandes. La taille géographique réelle d'une entité n'a rien à voir avec ses besoins en mémoire. C'est entièrement dû à sa complexité, qui est fonction du nombre de nœuds utilisés pour le représenter. Je suis cependant d'accord avec vous sur l'équilibre idéal.
WhiteboxDev

@nmpeterson, Oui, il est vrai que cela se fait par couche et non par entité. Mais nous tampons les couches en général et non les entités individuelles. Vous avez certainement raison sur la non-linéarité des performances dans le traitement géospatial! Il semble que ce soit toujours le cas pour nous!
WhiteboxDev
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.