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 :

1. 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.
2. Procédure d'identification et de mise à disposition des modules importés sur le serveur pour l'exécution d'une tâche.
3. Procédure de création des données de projet et des paramètres des modules Python dans vos scripts.
4. Procédure de gestion du code de validation de l'outil et interaction entre le client et le serveur.
5. 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. (ArcMap ou 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 :

1. La chaîne fait-elle référence à une couche dans la table des matières ?
2. La chaine contient-elle un chemin absolu d'accès aux données (comme "e:\Warehousing\ToolData\SanFrancisco.gdb\streets") ?
3. 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 des jeux de données

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. 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 et aux jeux de données situés à l'intérieur est construit par rapport à l'emplacement du script (le même dossier que Warehouse.tbx).

import arcpy
import os
import sys
# Get the directory the script lives in.
# Folders and data will be found relative to this location.
#
scriptPath = sys.path[0]
# Construct paths to ../ToolData/SanFrancisco.gdb/Streets and
#                    ../ToolData/Warehouse.lyr
streetFeatures = os.path.join(scriptPath, "ToolData\\SanFrancisco.gdb\\Streets")
streetLyr = os.path.join(scriptPath, "ToolData\\Warehouse.lyr")

Dans le code ci-dessus, les variables streetFeatures et streetLyr sont testées afin de vérifier si elles référencent des données qui 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).

Chemins relatifs des dossiers

Le dossier ToolData peut être référencé et utilisé comme point de départ pour référencer des éléments. 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 même dossier que Warehouse.tbx).

import arcpy import os import sys
# Get the directory the script lives in. # Folders and data will be found relative to this location. #
scriptPath = sys.path[0]
# Construct paths to the ToolData folder toolDataFolder = os.path.join(scriptPath, "ToolData")
# Construct path to items inside the folder streetFeatures = os.path.join(toolDataFolder, "SanFrancisco.gdb\\Streets")

Dans le code ci-dessus, la variable toolDataFolder devient un chemin relatif d'un dossier de divers éléments pouvant être référencés via votre script Python. 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).

Notez que lors du référencement d'un dossier, c'est son contenu qui est copié, et non pas les fichiers individuels. Par exemple, dans le code ci-dessus, même si aucun chemin explicite d'accès au fichier Warehouse.lyr n'a été créé, le fichier est consolidé, car il est présent dans le dossier référencé.

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.

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

Ce workflow peu courant qui consiste à utiliser des couches en tant que données de projet peut entraîner une amélioration des performances pour votre outil de script. Les extraits de code Python ci-dessus utilisent les chemins d'accès entiers aux classes d'entités et 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 constitue un gain de performance. L'utilisation des couches dans votre script permet de conserver les données ouvertes et en cache pour une exécution plus rapide. L'image suivante présente la manière dont les couches dans la table des matières d'ArcMap sont appariées et utilisées au sein du script Python.

Couches également utilisées dans l'outil de script Python

Les deux couches situées dans la table des matières sont utilisées au sein de l'outil de script. Les variables pointent vers des chaînes simples qui correspondent aux noms des couches au sein du document ArcMap. Lorsque vous publiez ce workflow sur ArcGIS Server, les données sont consolidées et transférées sur le serveur (si elles ne sont pas référencées dans le stockage des données) et le service renferme une référence aux couches en mémoire. Au sein de ce service, l'outil recherche et utilise les couches via cet appariement des noms.

Remarque :

Lorsque vous utilisez les couches en tant que données de projet internes dans un outil de script, ce dernier devient dépendant du document ArcMap associé. Vous ne pouvez pas exécuter l'outil dans ArcCatalog ou dans un autre document ArcMap si ces couches ne sont pas présentes. Ce modèle ne fonctionne pas avec Traitement en arrière-plan et réduit la portabilité générale du workflow. Il convient par conséquent mieux à la création de services de géotraitement.

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"

Pour en savoir plus sur la spécification de chemins

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.

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 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. Par exemple, 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 du client qui 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 stockage des 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'éditeur de services définit les paramètres de dossier sur Mode en entrée ou 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	Contenu
Présentation rapide de la création d'outils personnalisés	Concepts de base relatifs à la création de vos propres outils de géotraitement.
Qu'est-ce que Python ? Qu'est-ce que ArcPy ?	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.
Présentation rapide de la création d'outils dans Python Qu'est-ce qu'un outil de script ?	Rubrique 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.