J'hésitais entre écrire un article de blog ou simplement ouvrir une discussion dans l'espace Python. Cela fait un moment que je n'ai pas contribué à mon blog, alors je choisis la première option.<\/EM><\/P>
<\/P>
La fonction ArcPy Data Access Walk (arcpy.da.Walk<\/SPAN>) est une fonction vraiment robuste, et je m'y fie beaucoup. La fonction ArcPy Walk est un exemple où Esri a bien réussi avec leur implémentation Python. Je ne peux pas dire quel était leur objectif de conception, mais il semble assez évident que le but était de créer une version géospatiale de la fonction Python os.walk <\/A>. Les noms sont les mêmes, beaucoup de paramètres sont identiques, les résultats sont similaires, etc.... Je pense qu'imiter cette fonctionnalité native Python bien établie dans ArcPy a été une réussite car cela n'a pas réinventé une roue parfaitement bonne, c'est-à-dire que les utilisateurs familiers avec os.walk peuvent facilement passer à l'utilisation de arcpy.da.Walk.<\/P>
<\/P>
Aussi appréciée que soit la fonction ArcPy Walk, j'ai quelques petits problèmes avec elle. Le premier est un problème de documentation, ou devrais-je dire un manque de documentation. L'un des paramètres de la fonction Walk est datatype. La documentation contient un tableau listant tous les arguments acceptables pour datatype, mais il n'y a aucune documentation réelle sur les types de données eux-mêmes. En regardant les noms des types de données, la plupart semblent évidents, donc peut-être qu'Esri a décidé qu'il n'était pas nécessaire de les documenter.<\/P>
<\/P>
Aussi descriptif qu'un nom puisse paraître au premier abord, l'absence de documentation conduit généralement à l'ambiguïté et à la confusion. Par exemple, que recouvre "FeatureClass"? Évidemment, on supposerait qu'une classe d'entités dans une géodatabase est incluse, mais qu'en est-il des fichiers shape? Les fichiers shape sont-ils des classes d'entités? Dans le monde Esri, la réponse est généralement "Oui" mais pas toujours. L'énigme réelle est le type de données "Geo" puisqu'il inclut les fichiers shape mais pas les classes d'entités dans une géodatabase. Les classes d'entités ne sont pas "geo"? Aussi importante que soit la documentation pour les bibliothèques/APIs, ce n'est pas la raison principale pour écrire aujourd'hui.<\/P>
<\/P>
Un de mes modèles préférés avec ArcPy Walk est d'appeler la fonction intégrée Python
next()<\/SPAN> une fois pour retourner une liste de fichiers shape dans un dossier ou des classes d'entités dans une géodatabase ou des classes d'entités dans un jeu de données d'entités.<\/P>
>>> workspace = #chemin vers dossier ou géodatabase ou jeu de données d'entités
>>>
>>> _, _, filenames = next(arcpy.da.Walk(workspace, datatype="FeatureClass"))
>>> filenames
[u'canadwshed_p.shp', u'plots.shp']
>>>
>>> #ou boucle sur classes d'entités ou fichiers shape
>>> for file in next(arcpy.da.Walk(workspace, datatype="FeatureClass"))[2]:
... print file
canadwshed_p.shp
plots.shp
>>>
<\/code><\/pre>
<\/P>
Dans le premier exemple, je crée un objet Workspace Walker jetable que je n'ai pas besoin de conserver ou déconstruire. Dans le second exemple, appeler next() dans la boucle for me permet d'éviter une boucle supplémentaire quand je ne m'intéresse qu'à un seul niveau de données géospatiales.<\/P>
<\/P>
Comme c'est souvent le cas dans la vie, il n'y a pas qu'une seule façon de lister les classes d'entités dans une géodatabase ou les fichiers shape dans un dossier. En fait, la fonction ArcPy Walk est le nouveau venu introduit dans ArcGIS 10.1 SP1. Avant ArcPy Walk, un utilisateur pouvait utiliser l'une des nombreuses fonctions de listing ArcPy (ListDatasets, ListFeatureClasses, ListFiles, ListRasters, ListTables, et ListWorkspaces) ou la fonction ArcPy Describe . Je préfère généralement ArcPy Walk aux autres en raison de sa facilité d'utilisation et sa similarité avec la fonctionnalité Python intégrée.<\/P>
<\/P>
La raison principale de cet article est de partager un domaine où la fonction ArcPy Walk trébuche, c'est-à-dire les sources de données en mémoire. Alors que les anciennes méthodes pour lister les sources de données fonctionnent avec les espaces de travail en mémoire, ce n'est pas le cas avec ArcPy Walk.<\/P>
>>> arcpy.CreateFeatureclass_management('in_memory', 'test_fc')
<Result 'in_memory\\test_fc'>
>>> arcpy.CreateTable_management('in_memory', 'test_tbl')
<Result 'in_memory\\test_tbl'>
>>> arcpy.CreateRasterDataset_management('in_memory','test_rd')
<Result 'in_memory\\test_rd'>
>>>
>>> #utilisation d'ArcPy Walk
>>> next(arcpy.da.Walk('in_memory'))[2]
[]
>>>
>>> #utilisation des fonctions listing ArcPy
>>> arcpy.env.workspace = 'in_memory'
>>> arcpy.ListFeatureClasses()
[u'test_fc']
>>> arcpy.ListTables()
[u'test_tbl']
>>> arcpy.ListRasters()
[u'test_rd']
>>> arcpy.ListDatasets()
[u'test_rd']
>>>
>>> #utilisation de la fonction Describe d'ArcPy
>>> [child.name for child in arcpy.Describe('in_memory').children]
[u'test_tbl', u'test_fc', u'test_rd']
>>>
<\/code><\/pre>
<\/P>
Ne pas supporter les espaces de travail en mémoire n'est guère plus qu'un faux pas, mais c'en est un quand même. Après tout, la documentation indique que le premier paramètre est « l'espace de travail au niveau supérieur » et pourtant aucune mention n'est faite que les espaces en mémoire ne sont pas supportés. Heureusement pour les utilisateurs, il existe au moins deux autres façons de lister les sources de données en mémoire.<\/P>
<\/P>
MIS À JOUR 06/2017:<\/STRONG><\/P>
<\/P>
Depuis que j'ai écrit cet article il y a près de 18 mois (je sais que « le temps file » mais quand même, déjà 18 mois ?<\/EM>), j'ai découvert que le problème avec ArcPy Walk et les espaces en mémoire est plus nuancé que ce que je pensais initialement. Permettez-moi de démontrer :<\/P>
>>> arcpy.CreateFeatureclass_management('in_memory', 'test_fc')
<Result 'in_memory\\test_fc'>
>>> arcpy.CreateTable_management('in_memory', 'test_tbl')
<Result 'in_memory\\test_tbl'>
>>> arcpy.CreateRasterDataset_management('in_memory','test_rd')
<Result 'in_memory\\test_rd'>
>>>
>>> # utilisation d'ArcPy Walk avec "GPInMemoryWorkspace" plutôt que le commun "in_memory"
>>> next(arcpy.da.Walk('GPInMemoryWorkspace'))[2]
[u'test_tbl', u'test_fc', u'test_rd']
>>> <\/code><\/pre>
<\/P>
Il s'avère donc qu'ArcPy Walk fonctionne très bien avec les espaces en mémoire lorsqu'il sait réellement que vous lui indiquez un espace en mémoire. La partie vraiment frustrante et même un peu regrettable est que cela relève simplement de la sémantique et Esri n'a toujours pas réussi à corriger cela. Fonctionnellement, ArcPy Walk fonctionne déjà avec les espaces en mémoire ; la fonction ne sait juste pas que tout le monde et tous les autres outils désignent ces espaces par "in_memory" au lieu de "GPInMemoryWorkspace".<\/P>
