Création de tâches de géotraitement avec des scripts Python
Approfondissement :La majorité des outils de script Python qui s'exécutent avec succès sur votre ordinateur se publient et s'exécutent avec succès sur un Serveur SIG, sans qu'il y ait besoin 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 ou des instructions d'import pour importer des modules Python que vous avez développés. Dans ce cas, il est recommandé de lire cette rubrique qui traite en détail des sujets suivants :
- Procédure d'identification et de mise à disposition sur le serveur pour l'exécution d'une tâche des données de projet utilisées dans un script.
- Procédure d'identification et de mise à disposition des modules importés sur le serveur pour l'exécution d'une tâche.
- Procédure de création des données de projet et des paramètres des modules Python dans vos scripts.
- Procédure de gestion du code de validation de l'outil et interaction entre le client et le serveur.
- Procédure de gestion des bibliothèques tierces.
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 d'identification des données de projet dans votre script
Chaque fois que vous partagez un résultat, que ce soit en tant que paquetage ou service, et que le résultat fait référence à un outil de script, cet outil est analysé afin de rechercher toutes les données de projet utilisées dans le script. Une fois les données de projet identifiées, ces données sont consolidées dans un dossier temporaire qui est empaqueté (si vous partagez un paquetage) ou téléchargé sur le serveur (si vous partagez un service).
A l'issue de l'analyse du script, 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 que la chaîne correspond à un chemin d'accès aux données existantes. Dans ce cas, on entend par données
- une couche dans la table des matières (d'ArcMap ou d'ArcGlobe),
- un dossier,
- un fichier,
- un jeu de données géographiques comme une classe d'entités, un fichier de formes, une géodatabase, un document ArcMap (.mxd) et un fichier de couche (.lyr).
Dans le cadre de cette discussion, seules les données utilisées en entrée dans les outils de géotraitement ou chemins faisant référence à d'autres modules Python méritent notre attention. Les données en sortie sont également consolidées mais ne sont pas considérées comme des données de projet.
Chaque fois qu'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 table des matières ?
- La chaine contient-elle un chemin absolu d'accès aux données (comme "e:\Warehousing\ToolData\SanFrancisco.gdb\streets") ?
- La chaîne fait-elle référence à des données que l'on peut rechercher par rapport à l'emplacement du script ? L'emplacement du script est défini comme suit :
- Dossier contenant le script.
- Si le script est incorporé dans la boîte à outils, l'emplacement correspond au dossier qui contient la boîte à outils.
- Si le script se trouve dans une boîte à outils Python, l'emplacement correspond au dossier qui contient la boîte à outils Python.
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 vous partagez un service, le magasin de données du serveur est analysé afin de savoir si les données résident dans le magasin de données. Le cas échéant, les données 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, les rasters et les TIN 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 (.lyr) ou des documents ArcMap (.mxd), toutes les données référencées par le fichier de couche ou document ArcMap sont également consolidées de manière à ce que n'importe quelle routine arcpy.mapping du script puisse accéder aux données référencées.
Astuce: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 trouvés dans un magasin de données du serveur puisque ces dossiers ne sont pas téléchargés sur le serveur.)
Exemples
Les exemples ci-après reposent sur cette structure de dossier :
 |
Exemple de dossier de projet |
Chemins relatifs et dossiers
La technique suivante d'identification des données par rapport à l'emplacement du script correspond à un schéma classique, en particulier pour les services créés pour ArcGIS 10.0. Pour information, le code de script qui suit réside dans le dossier Scripts illustré ci-dessus. Le dossier ToolData contient une géodatabase fichier SanFrancisco.gdb. La géodatabase fichier SanFrancisco.gdb contient une classe d'entités appelée Streets. Dans l'échantillon de code ci-après, le chemin d'accès au dossier ToolData est construit par rapport à l'emplacement du script (le dossier Scripts).
import arcpy
import os
import sys
# Get the pathname to this script, then strip off the
# script file name to yield the containing folder
#
scriptPath = sys.path[0]
thisFolder = os.path.dirname(scriptPath)
# Construct paths to ../ToolData/SanFrancisco.gdb/Streets and
# ../ToolData/Warehouse.lyr
#
toolDataPath = os.path.join(thisFolder, "ToolData")
streetFeatures = os.path.join(toolDataPath, "SanFrancisco.gdb", "Streets")
streetLyr = os.path.join(toolDataPath, "Warehouse.lyr")
Dans le code ci-dessus, la chaîne "ToolData" (un argument de la fonction os.path.join) est testée afin de vérifier s'il s'agit de données qui existent. Dans ce cas, il existe un dossier appelé ToolData, par rapport à l'emplacement du script. Ce dossier ToolData sera consolidé, c'est à dire que tout son contenu (à l'exception des sous-dossiers comme indiqué plus haut) sera empaqueté ou téléchargé sur le serveur (sauf si le dossier ToolData fait partie du magasin de données du serveur).
Il convient de noter que c'est le contenu de ce dossier qui est copié, et non pas les fichiers individuels. Par exemple, dans le code ci-dessus, le chemin d'accès au jeu de données e:/Warehousing/ToolData/SanFrancisco.gdb/Streets est créé. Le processus de consolidation ne permet pas d'isoler et de copier uniquement le jeu de données Streets, il copie l'intégralité du dossier ToolData.
Chemin absolu d'accès à un jeu de données géographiques
On appelle chemin absolu un chemin qui commence par la lettre d'une unité, comme e:/, comme illustré dans l'échantillon de code ci-après.
import arcpy
import os
streetFeatures = 'e:/Warehousing/ToolData/SanFrancisco.gdb/Streets'
Dans le code ci-dessus, le jeu de données Streets et toutes les autres données dont il dépend (comme les classes de relations et les domaines) seront consolidés.
Exemple hybride
import arcpy
import os
toolDataPath = r'e:\Warehousing\ToolData'
warehouseLyr = os.path.join(toolDataPath, "Warehouse.lyr")
Dans le code ci-dessus, l'intégralité du contenu du dossier ToolData est consolidé. Comme le contenu du dossier (en dehors des sous-dossiers) est consolidé, Warehouse.lyr est également consolidé, ainsi que toutes les données auxquelles Warehouse.lyr fait référence.
Barres obliques et barres obliques inverses
La convention propre à Windows stipule l'utilisation d'une barre oblique inverse (\) comme séparateur dans un chemin. Les systèmes UNIX utilisent une barre oblique (/).
Remarque :Dans ArcGIS, cela n'a pas d'importance que vous utilisiez une barre oblique ou une barre oblique inverse dans votre chemin. ArcGIS transpose toujours les barres obliques et les barres obliques inverses selon la convention de système d'exploitation appropriée.
Barres obliques inverses dans les scripts
Les langages de programmation qui ont leurs racines dans UNIX et le langage de programmation C, tel que Python, utilisent la barre oblique inverse (\) comme caractère d'échappement. Par exemple, \t correspond à une tabulation. Comme les chemins peuvent contenir des barres obliques inverses, vous devez empêcher l'utilisation de la barre oblique inverse comme caractère d'échappement. La méthode la plus simple consiste à convertir les chemins en chaînes brutes Python à l'aide de la directive r, comme illustré ci-dessous. Cela indique à Python d'ignorer les barres obliques inverses.
thePath = r"E:\data\telluride\newdata.gdb\slopes"
Importation d'autres modules Python
Votre script peut importer d'autres scripts développés par vos soins. Par exemple, le code ci-dessous illustre l'importation d'un module Python intitulé 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)
Chaque fois qu'une instruction import est identifiée, la commande suivante est utilisée pour identifier 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.
Une autre technique pour référencer les 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 'e:\Warehousing\Scripts' est un dossier, l'intégralité du contenu du dossier sera consolidé. 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 Pyhton contenus dans le dossier ne sont pas analysés pour identifier les données de projet ou les modules importés.
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 du service de géotraitement n'ont pas la possibilité d'exécuter votre logique de validation d'outil. Seul le serveur peut le faire. Lorsque le client envoie sa 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.
La logique de validation est implémentée avec Python et le code de validation est analysé pour identifier les données de projet et les modules, comme pour tout autre script Python. Ainsi, la logique de validation peut ouvrir un dossier (par exemple, d:\approved_projections) contenant des fichiers de projection (.prj) pour créer une liste de choix de références spatiales à l'intention des utilisateurs qui exécutent 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 magasin de données du serveur).
Création des données de projet et des paramètres d'outil des modules
Comme décrit ci-dessus, les scripts Python sont analysés lorsqu'ils sont partagés et les décisions sont prises pour savoir quelles données sont utilisées par le script en fonction des chaînes entre guillemets trouvées dans le code. Si vous voulez contrôler ce processus, vous pouvez utiliser la méthode qui consiste à créer des paramètres pour toutes les données et tous les modules utilisés par le script. L'échantillon de script ci-dessous illustre le concept, toutes les données de projet et tous les modules sont convertis en paramètres qui sont transmis au script.
import arcpy
import sys
import os
inFeatures = arcpy.GetParameterAsText(0) # Feature Layer
projectDataFolder = arcpy.GetParameterAsText(1) # Folder
myPythonModules = arcpy.GetParameterAsText(2) # Folder
# Append the path to the utility modules to the system path
# for the duration of this script.
#
sys.path.append(myPythonModules)
import myutils # a Python file within myPythonModules
# Construct a variable to hold the Streets feature class found in the
# project data folder
#
streetsFeatures = os.path.join(projectDataFolder, "SanFrancisco.gdb", "Streets")
Lorsque le script utilise les paramètres pour toutes ses données comme illustré ci-dessus, plusieurs événements positifs se produisent :
- Vous connaissez mieux les données dont le script a besoin : comme il s'agit d'un paramètre, il s'affiche dans la boîte de dialogue des outils. Vous n'avez pas besoin de modifier le code pour savoir quelles données vous utilisez.
- La logique de validation de l'outil interne prime : si la valeur du paramètre fait référence à des données qui n'existent pas, la boîte de dialogue des outils renvoie un message d'erreur et vous ne pouvez pas exécuter l'outil permettant de créer un résultat.
- Pour redéfinir l'emplacement des données, vous pouvez rechercher l'emplacement à l'aide de la boîte de dialogue des outils plutôt que de saisir l'emplacement dans le script (ce qui est source d'erreurs).
- Lorsque le résultat est partagé en tant que service, l'Editeur de services définit les paramètres de dossier sur le Mode en entrée Constante ; de cette manière le client ne voit jamais les paramètres. Lors de la publication, les deux dossiers sont copiés sur le serveur (sauf s'ils sont enregistrés dans le magasin de données). Lorsque votre tâche est exécutée sur le serveur, votre script reçoit les chemins d'accès aux dossiers copiés.
Modules tiers
Les modules tiers (à 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 s'exécute correctement sur le serveur. Ceci ne s'applique pas aux modules numpy et matplotlib installés avec ArcGIS Server.
Remarque :L'installation de modules Python tiers (autres que numpy et matplotlib) sur Linux requiert une prise en charge particulière.
En savoir plus sur l'installation de modules Python tiers sur Linux
Prise en main de Python, d'ArcPy et des outils de script
Si vous ne connaissez pas Python, ArcPy et les outils de script, le tableau ci-dessous contient des rubriques qui vous aideront dans votre apprentissage.
Rubrique d'aide | Table des matières |
|---|---|
Concepts de base relatifs à la création de vos propres outils de géotraitement. | |
Rubriques de présentation de Python et ArcPy. Ces rubriques vous permettent d'accéder à des rubriques plus détaillées sur Python et sur le site-package ArcPy. | |
Rubrique de présentation de la création d'outils de script personnalisés avec Python. | |
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. |