Les services d'image ne servent pas uniquement à fournir des images ; ils peuvent également effectuer une analyse dynamique au niveau du pixel sur plusieurs ensembles de données raster superposés en utilisant des fonctions raster en chaîne. Les services d'image offrent des performances fulgurantes grâce à l'imagerie source prétraitée, surtout lorsqu'elle est servie depuis un cache de tuiles. Les services d'image dynamiques, en revanche, peuvent ne pas répondre aussi rapidement en raison des exigences de traitement supplémentaires qu'ils imposent au serveur. Une haute performance est importante pour les services d'image dynamiques car les données sont retraitées automatiquement chaque fois que l'utilisateur déplace ou effectue un zoom sur la carte. Les services d'image dynamiques produisent généralement des réponses en moins d'une seconde pour des types simples d'analyse. Mais une analyse plus complexe peut prendre beaucoup plus de temps selon la complexité de la chaîne de traitement et le nombre d'ensembles de données d'entrée impliqués. Comment pouvons-nous obtenir de meilleures performances dans ces situations ? Pour répondre à cette question, j'ai réalisé une série de tests pour voir comment les facteurs suivants affectent la performance des services d'image dynamiques :<\/P>
<\/P>
Dans cet article, je présente les résultats de ces tests ainsi que quelques suggestions pour maximiser les performances. Ma machine de test est un ordinateur de bureau fonctionnant sous Windows 7 SP1 et ArcGIS 10.2.1 avec 18 Go de RAM et un processeur quad-core Intel Xeon W3550 cadencé à 3 GHz. Les données test étaient stockées sur un disque dur SATA vide de 2 To que j'ai défragmenté et consolidé avant les tests. Les tests ont été configurés pour déterminer les temps moyens de réponse des services dans diverses conditions. Par « temps de réponse », j'entends le temps nécessaire à un service pour récupérer les données sources, les traiter et transmettre une image en sortie. Le temps de transmission a été minimisé en exécutant l'application de test directement sur la machine serveur.<\/P>
Ces informations sont écrites pour un utilisateur SIG intermédiaire à avancé. Je suppose que le lecteur a une compréhension générale des services d'image, des données raster et analyses, des fonctions raster, du géotraitement, des ensembles mosaïques, des projections cartographiques et du cache des services cartographiques.<\/P>
Échelle de la carte et résolution des données sources<\/STRONG><\/P><\/P>Les pixels traités pour l'analyse par les services d'image dynamiques ne sont généralement pas identiques aux pixels stockés dans les ensembles de données sources. Au lieu de cela, les pixels des données sources sont d'abord rééchantillonnés à la volée à une nouvelle taille basée sur l'échelle actuelle de la carte. Cette formule montre la relation entre l'échelle de la carte et la taille du rééchantillonnage lorsque les unités cartographiques des données sont en mètres :<\/P><\/P>Taille du pixel rééchantillonné = échelle de la carte * 0.0254\/96<\/A><\/P><\/P>La taille du pixel rééchantillonné est analogue au paramètre « Taille cellule d'analyse » dans le cadre du géotraitement et est parfois appelée « taille du pixel de la requête ». En effectuant un zoom arrière vers des échelles plus petites, la taille du pixel rééchantillonné augmente jusqu'à ce que finalement le service rééchantillonne à partir des pixels dans les pyramides. Le rééchantillonnage à partir des pyramides aide à maintenir une performance relativement constante du service sur une gamme d'échelles cartographiques.<\/P><\/P>Graphique 1. Performance d'un service d'image effectuant une analyse binaire superposée sur une gamme d'échelles cartographiques.<\/P><\/DIV>La performance varie toujours selon l'échelle de la carte et ressemble typiquement au graphique 1. J'ai généré ces résultats en utilisant une application configurée pour simuler un seul utilisateur déplaçant la carte 100 fois successivement à des échelles spécifiques. Le graphique montre le temps moyen que le service a mis pour traiter et transmettre les images en sortie pour différentes échelles cartographiques. Ce service particulier a été configuré avec un modèle de fonction raster pour effectuer une analyse binaire superposée sur onze rasters superposés dans un ensemble mosaïque. Les tailles des pixels des ensembles sources variaient entre 91,67 et 100 mètres. Le modèle de fonction raster était configuré pour retourner un résultat binaire, où chaque pixel en sortie est classifié comme « adapté » ou « non adapté » selon les paramètres d'analyse.<\/P><\/P>Regardez les trois points le long de l'axe horizontal où le temps de réponse chute brusquement. À ces échelles cartographiques, la taille du pixel rééchantillonné est identique à celle des pixels des pyramides dans les données sources. Le temps de traitement pour le rééchantillonnage est le plus bas à ces échelles car il y a presque une correspondance 1:1 entre les pixels des données sources et ceux rééchantillonnés. Les applications clientes qui utilisent ce service verront des temps de réponse nettement plus rapides si elles sont limitées d'une manière ou d'une autre uniquement à ces échelles. Une façon d'y parvenir est d'utiliser une couche basemap tuilée. Les applications web cartographiques qui utilisent des basemaps tuilés sont généralement limitées uniquement à ces échelles cartographiques. Le schéma de tuilage le plus couramment utilisé est le schéma ArcGIS Online\Bing Maps\Google Maps (appelé ci-après « schéma AGOL » par souci de concision). Les lignes verticales rouges pointillées dans le graphique indiquent les échelles cartographiques pour les niveaux 7 – 12 de ce schéma de tuilage. Malheureusement, ces échelles ne sont pas très proches des échelles où ce service fonctionne au mieux. Il existe deux options pour aligner les pixels des données sources avec les échelles du schéma de tuilage :<\/P><\/P>Construire un basemap personnalisé avec un schéma de tuilage personnalisé qui correspond aux tailles des pixels des données.<\/LI>Échantillonner ou rééchantillonner les données à une taille pixel qui correspond au schéma de tuilage du basemap.<\/LI><\/OL><\/OL>Graphique 2. Performance du service d'analyse binaire superposée avec différentes tailles pixel des données sources<\/P><\/DIV>L'axe horizontal dans le graphique 2 représente la « taille du pixel de la requête » plutôt que l'échelle cartographique comme dans le graphique 1. La courbe orange montre les temps de réponse d'un autre service configuré identiquement au premier en bleu, sauf qu'il utilise des ensembles sources qui ont été sur-échantillonnés à des pixels de 38 mètres en utilisant l'outil Resample<\/A>. Le sur-échantillonnage à 38 mètres a aligné les temps de réponse les plus rapides du service avec les échelles du schéma AGOL, ce qui a entraîné une diminution significative du temps de traitement à ces échelles passant d'environ 1,5 seconde à environ 0,5 seconde. De plus, remarquez que la performance s'améliore à presque toutes les échelles sauf la plus grande. Cela est très probablement dû au fait que toutes les données sources ont maintenant la même résolution (38m) au lieu de trois (91,67m, 92,5m, 100m), et/ou parce que les pixels sources sont également alignés entre ensembles (réalisé en définissant un point origine commun pour chaque raster rééchantillonné via le paramètre environnement « Snap Raster »).<\/P><\/P>Il est vrai que l'utilisation de l'outil Resample pour préparer les données à l'analyse n'est pas idéale car elle produit des données secondaires moins précises que l'originale. Cela peut être parfaitement acceptable pour des applications destinées à fournir une analyse initiale sommaire ; cependant, il est préférable de générer autant que possible des nouvelles données primaires à la taille pixel souhaitée.Par exemple, si vous avez accès aux polygones classes terrestres, vous pourriez les utiliser pour générer un nouvel ensemble raster primaire à la taille pixel désirée en utilisant l'outil Polygon to Raster<\/A>, plutôt que de rééchantillonner un ensemble raster existant.
La taille du pixel rééchantillonné est analogue au paramètre « Taille cellule d'analyse » dans le cadre du géotraitement et est parfois appelée « taille du pixel de la requête ». En effectuant un zoom arrière vers des échelles plus petites, la taille du pixel rééchantillonné augmente jusqu'à ce que finalement le service rééchantillonne à partir des pixels dans les pyramides. Le rééchantillonnage à partir des pyramides aide à maintenir une performance relativement constante du service sur une gamme d'échelles cartographiques.<\/P>
Il est vrai que l'utilisation de l'outil Resample pour préparer les données à l'analyse n'est pas idéale car elle produit des données secondaires moins précises que l'originale. Cela peut être parfaitement acceptable pour des applications destinées à fournir une analyse initiale sommaire ; cependant, il est préférable de générer autant que possible des nouvelles données primaires à la taille pixel souhaitée.Par exemple, si vous avez accès aux polygones classes terrestres, vous pourriez les utiliser pour générer un nouvel ensemble raster primaire à la taille pixel désirée en utilisant l'outil
Pour déterminer dans quelle mesure la performance s'est améliorée avec des pixels à 38 mètres, j'ai calculé le changement en pourcentage moyen des temps moyens de réponse pour chaque échelle et fait une moyenne sur plusieurs échelles.
Avec
Le sur-échantillonnage des données sources à pixels de 38 mètres a réduit les temps de réponse sous-performance aux échelles cibles sous-performance -63.8 % ! &nbpsp;
Échelles de carte et tailles de pixel pour le schéma de tuilage ArcGIS Online\/Bing Maps\/Google Maps<\/EM><\/P><\/A><\/P><\/P>Au fait, faire correspondre les tailles de pixel de vos données avec un schéma de tuilage de fond de carte est également utile pour les flux de travail impliquant des images statiques superposées à un fond de carte en tuiles. <\/SPAN>Dans ces cas, vous pouvez construire des aperçus de jeu de mosaïque pour la visualisation à des échelles plus petites au lieu des pyramides raster. <\/SPAN>L'un des grands avantages des aperçus de jeu de mosaïque est que vous pouvez définir la taille de pixel de base des aperçus ainsi que le facteur d'échelle pour correspondre à votre schéma de tuilage cible. <\/SPAN>De cette façon, vous n'avez pas besoin de rééchantillonner les données source à une nouvelle taille de pixel de base afin d'adapter un schéma de tuilage particulier.<\/P>Méthode de rééchantillonnage<\/STRONG><\/P><\/P><\/P>La méthode de rééchantillonnage<\/A> <\/SPAN>spécifiée pour une requête de service d'image a également un impact sur la performance. <\/SPAN>Le choix de celle à utiliser doit être basé principalement sur le type de données utilisées dans l'analyse. <\/SPAN>Le graphique 3 montre la performance du service d'analyse par superposition binaire (avec des données à 38 mètres) avec différentes méthodes de rééchantillonnage.<\/P><\/A>Graphique 3. Temps de réponse du service d'analyse par superposition binaire avec différentes méthodes de rééchantillonnage<\/P><\/DIV><\/P><\/P><\/P>Le rééchantillonnage bilinéaire est la méthode par défaut. <\/SPAN>Voici comment les temps de réponse des autres méthodes se comparent au bilinéaire en moyenne sur les cinq échelles cartographiques testées :<\/P><\/A><\/P>Format raster<\/STRONG><\/P><\/P>Le format de stockage des données peut avoir un énorme impact sur la performance. Par exemple, le temps de réponse du service d'analyse par superposition binaire en moyenne sur toutes les échelles cartographiques était inférieur de 36 % lorsque les données étaient stockées au format GeoTIFF par rapport au raster géré par géodatabase fichier. La section Sources et formats des données<\/A> du guide Image Management recommande de laisser les données dans leur format original sauf si elles sont dans l'un des formats plus lents comme ASCII. GeoTIFF avec tuiles internes est le choix recommandé pour le reformatage car il offre un accès rapide aux pixels pour des zones rectangulaires couvrant seulement un sous-ensemble du fichier entier.Type et compression du pixel<\/STRONG><\/P><\/P>Le type de pixel détermine la précision des valeurs stockées dans les données et peut avoir un énorme impact sur la performance. En général, les types entiers sont plus rapides que les types à virgule flottante, et les types à faible précision sont plus rapides que ceux à haute précision. La compression des images peut potentiellement augmenter ou réduire la performance selon la situation. Pour plus d'informations sur l'effet de la compression sur la taille du fichier, consultez la section Sources et formats des données du guide Image Management. Pour évaluer l'impact du type et de la compression du pixel sur la performance des données stockées sur un disque dur local, j'ai testé un groupe de services d'image configurés pour effectuer une analyse par superposition extrêmement intensive sur 15 jeux de données raster. Les services étaient configurés identiquement sauf pour les types de pixel et compression des données analysées. Les tests ont été effectués à l'échelle cartographique correspondant à la taille du pixel des données.<\/P>Graphiques 5 & 6. Temps moyen de réponse et taille du stockage vs. type de compression pour un service d'image effectuant une analyse par superposition complexe<\/P> à différentes tailles de requête sur le service d'analyse par superposition pondérée que j'ai utilisé pour les tests de reprojection à la volée. J'ai mesuré les temps de réponse moyens pour des tailles de requête allant de 400x400 à 2200x2200, augmentant par incréments de 100 pixels (par exemple 500x500, 600x600, etc6#8230;). Tous les tests ont été effectués à l'échelle de la carte de 1:113386, ce qui correspond à la taille de pixel de 30 mètres des jeux de données raster source.<\/P><\/A>Graphique 9. Réponse moyenne en MP\/s pour différentes tailles de requête pour le service d'analyse par superposition pondérée.<\/P><\/DIV><\/A>Graphique 10. Temps de réponse moyen à différentes tailles de requête pour le service d'analyse par superposition pondérée.<\/P><\/DIV><\/P><\/P>Le graphique 9 montre que le débit pour ce service se stabilise à une taille de requête d'environ 1000x1000 pixels à environ 1,5 6 6 6 6 6 6 MP\/s. Le graphique 10 montre que la taille de la requête a un impact linéaire sur la performance. Ce service est capable de fournir des temps de réponse inférieurs à une seconde pour des requêtes allant jusqu'à environ 1 440 000 pixels, soit une taille de requête de 1200x1200.<\/P><\/P>Résumé<\/STRONG><\/P><\/P>L'analyse raster peut impliquer plusieurs étapes de traitement et d'analyse des données. Des chaînes complexes de traitement à la volée peuvent imposer une lourde charge de traitement sur un serveur et contribuer à une performance lente. D'énormes améliorations des performances peuvent être obtenues dans certains cas en prétraitant les données dans un format plus efficace pour le rééchantillonnage et le traitement à la volée.<\/P><\/P>Pour les applications qui utilisent des couches basemap en tuiles, les plus grandes améliorations des performances sont susceptibles d'être obtenues en alignant les tailles des pixels des données avec les échelles du schéma de tuilage du basemap. La section 3Map Scales and Source Data Resolution 4 décrit la théorie derrière cette approche et fournit un tableau avec les tailles de pixels recommandées pour les applications qui utilisent des basemaps avec le schéma de tuilage ArcGIS Online\Bing Maps\Google Maps. Alternativement, les développeurs peuvent construire des basemaps avec des schémas de tuilage personnalisés pour s'aligner sur les tailles existantes des pixels des données d'analyse.<\/P><\/P>Une autre façon de réduire significativement la charge de traitement sur un serveur dans certains cas est d'éviter la projection à la volée des données d'analyse. Cela s'accomplit en s'assurant que le basemap et les données d'analyse sont dans le même système de coordonnées. L'impact sur la performance de la projection à la volée varie selon les systèmes de coordonnées d'entrée et de sortie et est discuté dans la section intitulée 3On-the-fly Projection 4.<\/P><\/P>Le format du fichier, le type de pixel et le type de compression des données d'analyse peuvent également avoir un impact énorme sur la performance. GeoTIFF avec tuiles internes est recommandé pour les situations où il est nécessaire de reformater les données depuis un format plus lent. Les types de pixels à précision inférieure offrent une meilleure performance que les types à haute précision. La compression des pixels peut potentiellement augmenter ou diminuer la performance selon la manière dont les données sont stockées et accédées par le serveur. Ces sujets sont abordés dans les sections intitulées 3Raster Format 4 et 3Pixel Type and Compression 4.<\/P><\/P>Les applications clientes peuvent également jouer un rôle dans la performance dynamique du service d'image. Les temps de réponse du service sont les plus faibles lorsque les applications spécifient un rééchantillonnage au plus proche voisin, suivi du rééchantillonnage bilinéaire. Et il existe une relation directe entre la performance du service et la taille de la fenêtre cartographique dans une application. Ces sujets sont abordés dans les sections intitulées 3Resampling Method 4 et 3Request Size 4.<\/P><\/BODY><\/HTML>
Au fait, faire correspondre les tailles de pixel de vos données avec un schéma de tuilage de fond de carte est également utile pour les flux de travail impliquant des images statiques superposées à un fond de carte en tuiles. <\/SPAN>Dans ces cas, vous pouvez construire des aperçus de jeu de mosaïque pour la visualisation à des échelles plus petites au lieu des pyramides raster. <\/SPAN>L'un des grands avantages des aperçus de jeu de mosaïque est que vous pouvez définir la taille de pixel de base des aperçus ainsi que le facteur d'échelle pour correspondre à votre schéma de tuilage cible. <\/SPAN>De cette façon, vous n'avez pas besoin de rééchantillonner les données source à une nouvelle taille de pixel de base afin d'adapter un schéma de tuilage particulier.<\/P>Méthode de rééchantillonnage<\/STRONG><\/P><\/P><\/P>La
Graphique 3. Temps de réponse du service d'analyse par superposition binaire avec différentes méthodes de rééchantillonnage<\/P><\/DIV>
Le rééchantillonnage bilinéaire est la méthode par défaut. <\/SPAN>Voici comment les temps de réponse des autres méthodes se comparent au bilinéaire en moyenne sur les cinq échelles cartographiques testées :<\/P>
Format raster<\/STRONG><\/P><\/P>Le format de stockage des données peut avoir un énorme impact sur la performance. Par exemple, le temps de réponse du service d'analyse par superposition binaire en moyenne sur toutes les échelles cartographiques était inférieur de 36 % lorsque les données étaient stockées au format GeoTIFF par rapport au raster géré par géodatabase fichier. La section
Graphiques 5 & 6. Temps moyen de réponse et taille du stockage vs. type de compression pour un service d'image effectuant une analyse par superposition complexe<\/P> à différentes tailles de requête sur le service d'analyse par superposition pondérée que j'ai utilisé pour les tests de reprojection à la volée. J'ai mesuré les temps de réponse moyens pour des tailles de requête allant de 400x400 à 2200x2200, augmentant par incréments de 100 pixels (par exemple 500x500, 600x600, etc6#8230;). Tous les tests ont été effectués à l'échelle de la carte de 1:113386, ce qui correspond à la taille de pixel de 30 mètres des jeux de données raster source.<\/P>
Graphique 9. Réponse moyenne en MP\/s pour différentes tailles de requête pour le service d'analyse par superposition pondérée.<\/P><\/DIV>
Graphique 10. Temps de réponse moyen à différentes tailles de requête pour le service d'analyse par superposition pondérée.<\/P><\/DIV>
Le graphique 9 montre que le débit pour ce service se stabilise à une taille de requête d'environ 1000x1000 pixels à environ 1,5 6 6 6 6 6 6 MP\/s. Le graphique 10 montre que la taille de la requête a un impact linéaire sur la performance. Ce service est capable de fournir des temps de réponse inférieurs à une seconde pour des requêtes allant jusqu'à environ 1 440 000 pixels, soit une taille de requête de 1200x1200.<\/P>
Résumé<\/STRONG><\/P><\/P>L'analyse raster peut impliquer plusieurs étapes de traitement et d'analyse des données. Des chaînes complexes de traitement à la volée peuvent imposer une lourde charge de traitement sur un serveur et contribuer à une performance lente. D'énormes améliorations des performances peuvent être obtenues dans certains cas en prétraitant les données dans un format plus efficace pour le rééchantillonnage et le traitement à la volée.<\/P><\/P>Pour les applications qui utilisent des couches basemap en tuiles, les plus grandes améliorations des performances sont susceptibles d'être obtenues en alignant les tailles des pixels des données avec les échelles du schéma de tuilage du basemap. La section 3Map Scales and Source Data Resolution 4 décrit la théorie derrière cette approche et fournit un tableau avec les tailles de pixels recommandées pour les applications qui utilisent des basemaps avec le schéma de tuilage ArcGIS Online\Bing Maps\Google Maps. Alternativement, les développeurs peuvent construire des basemaps avec des schémas de tuilage personnalisés pour s'aligner sur les tailles existantes des pixels des données d'analyse.<\/P><\/P>Une autre façon de réduire significativement la charge de traitement sur un serveur dans certains cas est d'éviter la projection à la volée des données d'analyse. Cela s'accomplit en s'assurant que le basemap et les données d'analyse sont dans le même système de coordonnées. L'impact sur la performance de la projection à la volée varie selon les systèmes de coordonnées d'entrée et de sortie et est discuté dans la section intitulée 3On-the-fly Projection 4.<\/P><\/P>Le format du fichier, le type de pixel et le type de compression des données d'analyse peuvent également avoir un impact énorme sur la performance. GeoTIFF avec tuiles internes est recommandé pour les situations où il est nécessaire de reformater les données depuis un format plus lent. Les types de pixels à précision inférieure offrent une meilleure performance que les types à haute précision. La compression des pixels peut potentiellement augmenter ou diminuer la performance selon la manière dont les données sont stockées et accédées par le serveur. Ces sujets sont abordés dans les sections intitulées 3Raster Format 4 et 3Pixel Type and Compression 4.<\/P><\/P>Les applications clientes peuvent également jouer un rôle dans la performance dynamique du service d'image. Les temps de réponse du service sont les plus faibles lorsque les applications spécifient un rééchantillonnage au plus proche voisin, suivi du rééchantillonnage bilinéaire. Et il existe une relation directe entre la performance du service et la taille de la fenêtre cartographique dans une application. Ces sujets sont abordés dans les sections intitulées 3Resampling Method 4 et 3Request Size 4.<\/P><\/BODY><\/HTML>
I think you have the right idea. It's great that you are getting good performance at 1:10,000, even though one of the pyramid levels in your source data corresponds to a map scale of 1:10,500. That's the power of Image Server at work! Image Server is highly optimized out-of-the-box. For typical service configurations and usages, details like the pixel sizes of the source data are not significant factor in overall performance. However based on my results, I expect you would get even better performance if the pyramid in your data was at 9,500 instead of 10,500. Although it's possible that the improvement may not be easily perceived at the human level in your case. Putting this in perspective, the service I used to generate my results performed a server-side analysis on 11 different raster datasets. So the performance impact of resampling from 11 datasets with sub-optimal pixel sizes was greatly amplified. Typical image services do not require this amount of heavy lifting. But for cases like mine where performance was not satisfactory, this is one approach that can potentially bring huge gains in performance.
I had to find this post again after I realised I potentially have an image service with pyramids at inappropriate levels with respect to our basemap levels. Luckily, we are on the right side of this performance pattern and resampling is not required. However, this goes against my understanding as I thought we were going to have performance implications.
Let's say your basemap tiling has a level 14 at 10,000, should the pyramid be at 9,500 or 10,500? I had assumed (potentially incorrectly) that you would want 9,500 for the pyramid so that the resampling up to 10,000 when drawing in the web is minimal. What my tests showed was that our image service drew quickly at 10,000 even though the pyramid was at 10,500.
You are very welcome. Thanks for the compliment!
Six years later and this is still a phenomenal post. Thank you.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
