Création de services de géotraitement avec des scripts Python—ArcGIS Pro

Approfondissement :

La plupart des outils de script Python qui s’exécutent correctement sur votre ordinateur sont publiés et exécutés en tant que service de géotraitement, sans qu’il soit nécessaire de modifier le script d’une quelconque manière. Toutefois, si vous rencontrez des problèmes, c’est peut-être que votre script utilise un grand nombre de données de projet (ce qui implique de saisir des données qui ne sont pas des paramètres) ou des instructions import pour importer des modules Python que vous avez développés. Dans ce cas, il est recommandé de lire cette rubrique, qui couvre les scénarios suivants :

Procédure de construction des chemins d'accès aux données de projet et procédure d'identification de ces chemins.
Procédure d’identification et de mise à disposition des modules importés pour l’utilisation de l’outil.
Procédure de gestion des bibliothèques tierces.
Procédure de gestion du code de validation de l'outil et interaction entre le client et le service de géotraitement.

Si vous ne connaissez pas Python, ArcPy ou les outils de script, passez à la section Prise en main de Python, d’ArcPy et des outils de script ci-dessous pour accéder à une liste de rubriques utiles.

Procédure de construction des chemins d'accès aux données de projet et procédure d'identification de ces chemins

La construction appropriée des chemins qui référencent des données constitue une part importante de nombreux scripts Python. Ceci inclut les données de projet (données en entrée non exposées en tant que paramètres) qui se trouvent à l’intérieur des scripts, ainsi que les données intermédiaires (temporaires). Vous pouvez écrire des chemins d’accès dans Python qui référencent des données de différentes façons. Reportez-vous à la rubrique Définition des chemins d’accès aux données dans Python pour savoir comment écrire un chemin complet.

Un chemin d’accès aux données relatives à un emplacement connu peut se construire avec os.path.join. Ceci est également utile pour construire des chemins d’accès à des emplacements en sortie figurant dans l’espace de travail en mémoire ou pour utiliser des emplacements temporaires pour des données temporaires sur le disque. Consultez l’exemple ci-dessous avec os.path.join.

Lorsque vous partagez votre outil en tant que service de géotraitement, le script est numérisé et chaque chaîne entre guillemets (simples ou doubles) utilisée dans une variable Python ou en tant qu’argument d’une fonction est testée afin de vérifier si la chaîne correspond à un chemin d’accès à des données existantes. Les données de projet, dans ce cas, impliquent les notions suivantes :

une couche dans la table des matières de votre carte ou scène,
un dossier,
un fichier,
un jeu de données géographiques, tel qu’une classe d’entités, un shapefile, une géodatabase, une carte (.mapx) ou un fichier de couche (.lyrx).

Lorsqu'une chaîne entre guillemets est identifiée dans le script, le test visant à vérifier l'existence de données se déroule comme suit :

La chaîne fait-elle référence à une couche dans la fenêtre Contenu ?
La chaîne contient-elle un chemin absolu d’accès aux données, tel que "e:\Warehousing\ToolData\SanFrancisco.gdb\streets" ?
La chaîne fait-elle référence à des données que l’on peut rechercher par rapport à un emplacement connu, tel que le fichier de projet .aprx ou au script ?

Ces tests se déroulent suivant un ordre séquentiel. Si le test est réussi et que les données existent, les données sont consolidées sauf dans le cas suivant : si les données ont été inscrites auprès du stockage des données fédéré du portail, elles ne sont pas consolidées.

Remarque :

Lorsque les dossiers sont consolidés, seuls les fichiers et les jeux de données géographiques du dossier sont copiés, pas les sous-dossiers du dossier. Certains jeux de données géographiques, tels que les géodatabases fichier et les rasters sont des dossiers techniquement parlant, mais comme ils sont aussi des jeux de données géographiques, ils sont copiés. Si le dossier contient des fichiers de couche (.lyrx) ou des cartes (.mapx), toutes les données référencées par le fichier de couche ou la carte sont également consolidées de manière à ce que n’importe quelle routine arcpy.mp du script puisse accéder aux données référencées.

Conseil :

Du fait du mode de consolidation des dossiers, il est préférable de ne pas encombrer le dossier avec des jeux de données et des fichiers volumineux qui ne seront jamais utilisés par votre outil. En effet, le volume des données à empaqueter ou à télécharger sur le serveur augmenterait inutilement. (Cette règle ne s’applique pas aux dossiers du stockage des données d’un serveur puisque ces dossiers ne sont pas chargés sur le serveur.)

Exemple

L'exemple suivante repose sur la structure de dossier de ce projet :

Chemins relatifs aux jeux de données et dossiers

Une routine arcpy.mp permet d’obtenir le chemin homeFolder ou defaultGeodatabase pour un projet donné. Les chemins peuvent être construits avec le module os de Python. Dans l’exemple suivant, une classe d’entités dans la géodatabase WebTools.gdb est définie et symbolisée à l’aide d’un fichier de couche dans le dossier LYRXs :

import arcpy
import os

# The ArcGIS Project is used to build paths from the defaultGeodatabase and 
# homeFolder using os.path.join

# Reference the CURRENT project with ArcGIS Pro open, or point to an .aprx on 
# disk
prj = arcpy.mp.ArcGISProject("CURRENT")
arcpy.CopyFeatures_management(os.path.join(prj.defaultGeodatabase, "study_sites"), 
                              "in_memory/tempSite")

# Create a variable to reference the LYRX folder
lyrxFolder = os.path.join(prj.homeFolder, "LYRXs")
arcpy.ApplySymbologyFromLayer_management("in_memory/tempSite", 
                                         os.path.join(lyrxFolder, "Site4.lyrx"))

Dans le code ci-dessus, la classe d’entités study_sites et le fichier Site4.lyrx (ainsi que les données vers lesquelles il pointe) sont testés dans le but de vérifier si les données de référence existent. Ces jeux de données sont consolidés et chargés sur le serveur (sauf si le dossier dans lequel ils se trouvent a été référencé dans le cadre du stockage des données du serveur).

La variable lyrxFolder fait référence à un chemin relatif vers un dossier de fichiers de couche. Ce dossier sera consolidé, c’est-à-dire que tout son contenu (à l’exception des sous-dossiers comme indiqué plus haut) sera empaqueté ou chargé sur le serveur (sauf si le dossier lyrxFolder fait partie du stockage des données du serveur).

Référencer des couches en tant que données de projet

Ce processus moins courant, qui consiste à utiliser des couches en tant que données de projet, peut entraîner une amélioration des performances de votre outil de script Python. Le code Python ci-dessus utilise les chemins d’accès entiers aux classes d’entités et aux fichiers de couche. Lorsqu’un service de géotraitement est exécuté, il doit d’abord ouvrir le jeu de données. L’ouverture d’un jeu de données induit un coût en termes de performances. L’utilisation des couches dans votre script permet de conserver les données ouvertes et en cache pour des performances plus rapides. L'image suivante présente la manière dont les couches dans le contenu du projet sont appariées et utilisées dans le script Python :

Couches utilisées dans l'outil de script Python

Les variables (extentMask et rasterLayer) pointent vers des chaînes simples qui correspondent aux noms des couches dans la carte. Les données sont consolidées et disponibles dans le service de géotraitement en cas de partage sur votre portail (si elles ne sont pas référencées dans le stockage des données). Une référence aux couches en mémoire est également maintenue. Cet appariement de nom des couches sur la carte vers les chaînes de votre script permet aux outils de fonctionner avec les couches.

Remarque :

Lorsque vous utilisez les couches en tant que données de projet internes dans un outil de script, ce dernier devient dépendant de la carte associée. Vous ne pouvez pas exécuter l’outil dans une autre carte si ces couches ne sont pas présentes. Ce modèle réduit la portabilité générale de votre outil de script. Il convient par conséquent mieux à la création de services de géotraitement.

Importer d’autres modules Python

Votre script peut importer d'autres scripts développés par vos soins. Par exemple, le code suivant illustre l’importation d’un module Python nommé myutils.py, qui se trouve dans le même répertoire que le script parent et qui contient une routine nommée getFIDName.

import arcpy
import myutils

inFeatures = arcpy.GetParameterAsText(0)
inFID = myutils.getFIDName(inFeatures)

Lorsqu’une instruction import est identifiée, la commande suivante est utilisée pour localiser le script :

Dossier identique à celui du script. Si le script est incorporé dans la boîte à outils, le dossier qui contient la boîte à outils est utilisé.
Dossier référencé par la variable d'environnement système PYTHONPATH.
Tout dossier référencé par la variable d'environnement système PATH.

Si le script utilisé pour l'import se trouve dans l'un de ces dossiers, le script est consolidé. Le processus d'analyse est récursif, le script importé est également analysé afin de rechercher les données de projet et les imports à l'aide de toutes les règles détaillées plus haut.

Une autre technique de référencement des modules à importer consiste à utiliser la méthode sys.path.append. Cette méthode permet de définir un chemin d'accès à un dossier contenant les scripts que vous devez importer.

import arcpy
import sys
import os

# Append the path to the utility modules to the system path
# for the duration of this script.
myPythonModules = r'e:\Warehousing\Scripts'
sys.path.append(myPythonModules)
import myutils  # A Python file within myPythonModules

Dans le code ci-dessus, il convient de noter que la méthode sys.path.append nécessite un dossier en tant qu’argument. Comme r'e:\Warehousing\Scripts' est un dossier, l’intégralité du contenu du dossier est consolidée. Les règles de copie du contenu d'un dossier s'appliquent également dans ce cas, tout le contenu du dossier est copié à l'exception des sous-dossiers qui ne correspondent pas à des jeux de données géographiques.

Remarque :

Les scripts Python contenus dans le dossier ne sont pas analysés en vue de l’identification des données de projet ou des modules importés.

Modules tiers

Les modules tiers et les bibliothèques (à savoir les modules ne faisant pas partie de l’installation de base de Python) ne sont pas consolidés. Vous devez vous assurer que le module existe et est exécuté correctement sur le serveur. Cela ne s’applique pas à numpy, matplotlib et aux autres modules installés avec votre instance ArcGIS Server par défaut. Pour déployer des modules Python tiers, reportez-vous à la rubrique Déploiement de paquetages Python personnalisés pour ArcGIS Server.

Code de validation d'un outil

Si vous avez l'habitude d'écrire des outils de script, vous pouvez fournir votre propre logique de validation d'outil. Les clients des services de géotraitement n’ont pas la possibilité d’exécuter votre logique de validation d’outil. Seul le serveur peut le faire. Lorsque les clients envoient leur demande de tâche d’exécution au service, votre logique de validation est exécutée sur le serveur. Si vos routines de validation génèrent une erreur, la tâche interrompt l’exécution. Si vous êtes en train de renvoyer des messages à partir de votre service, le client reçoit les messages générés par vos routines de validation. En règle générale, le code de validation d’outil d'un service de géotraitement publié est moins utile que celui d'un outil utilisé sur le Bureau. Vous pouvez utiliser une copie de votre service de géotraitement dont le code de validation a été réduit ou supprimé, puis la partager en tant que service de géotraitement. Vous devez développer la logique de validation dans l'application pour utiliser le service de géotraitement.

La logique de validation est implémentée avec Python et le code de validation est analysé en vue de l’identification des données de projet et des modules, comme avec n’importe quel autre script Python. Par exemple, la logique de validation peut ouvrir un dossier (tel que, d:\approved_projections) contenant des fichiers de projection (.prj) pour créer une liste de choix de références spatiales à l’intention du client lorsque le serveur exécute l’outil. Ce dossier n'est pas un paramètre d'outil ; il s'agit des données de projet utilisées dans le script de validation de l'outil. Les mêmes règles que celles décrites ci-dessus pour les scripts Python s’appliquent ici : le dossier d:\approved_projections est consolidé et copié sur le serveur (à moins qu’il ne figure déjà dans le Data Store du serveur).

Prise en main de Python, d’ArcPy et des outils de script

Si vous ne connaissez pas Python, ArcPy ou les outils de script, reportez-vous au tableau suivant qui contient des rubriques susceptibles de vous aider à démarrer :


Rubrique d'aide	Contenu
Présentation du géotraitement	Rubriques de présentation du géotraitement.
Qu'est-ce que ArcPy ?	Rubriques de présentation d’ArcPy.
Présentation rapide de la création d’outils dans Python Qu'est-ce qu'un outil de script ?	Rubriques de présentation de la création d’outils de script personnalisés avec Python.
Définition des paramètres des outils de script	Une fois que vous vous êtes familiarisé avec le processus de création d’un outil de script, cette rubrique est souvent référencée, car elle explique en détail comment définir des paramètres d’outils de script.

Vous avez un commentaire à formuler concernant cette rubrique ?