Estaba indeciso sobre si escribir una publicación en el blog o simplemente abrir una discusión en el lugar de Python. Ha pasado un tiempo desde que contribuí a mi blog, así que opto por lo primero.<\/EM><\/P>
<\/P>
La función ArcPy Data Access Walk (arcpy.da.Walk<\/SPAN>) es una función realmente trabajadora, y dependo bastante de ella. La función ArcPy Walk es un ejemplo donde Esri acertó con su implementación en Python. No puedo decir cuál fue su objetivo de diseño, pero parece bastante evidente que la meta era crear una versión geoespacialmente consciente de la función os.walk <\/A>de Python. Los nombres son iguales, muchos de los parámetros son iguales, los resultados son similares, etc.... Creo que emular esta funcionalidad nativa y de larga data de Python en ArcPy fue un acierto porque no reinventó una rueda perfectamente buena, es decir, los usuarios familiarizados con os.walk pueden fácilmente hacer la transición a usar arcpy.da.Walk.<\/P>
<\/P>
Por mucho que me guste la función ArcPy Walk, hay un par de problemas menores que tengo con ella. El primero es un problema de documentación, o debería decir falta de documentación. Uno de los parámetros de la función Walk es datatype. La documentación tiene una tabla que lista todos los argumentos aceptables para datatype, pero no hay documentación real sobre los tipos de datos en sí. Al revisar los nombres de los tipos de datos, parece que la mayoría son obvios, así que tal vez Esri decidió que no necesitaban documentarlos.<\/P>
<\/P>
Por descriptivo que pueda parecer un nombre a primera vista, la falta de documentación usualmente conduce a ambigüedad y confusión. Por ejemplo, ¿qué se incluye bajo "FeatureClass"? Obviamente uno asumiría que una clase de entidad en una geodatabase está incluida pero ¿qué pasa con los shape files? ¿Son los shape files clases de entidad? En el mundo Esri, la respuesta suele ser "Sí" pero no siempre. El verdadero enigma es el tipo de dato "Geo" ya que incluye shape files pero no clases de entidad en una geodatabase. ¿Las clases de entidad no son "geo"? Por importante que sea la documentación para bibliotecas/APIs, no es la razón principal para escribir hoy.<\/P>
<\/P>
Uno de mis patrones favoritos con ArcPy Walk es llamar a la función incorporada de Python
next()<\/SPAN> una vez para devolver una lista de shape files en una carpeta o clases de entidad en una geodatabase o clases de entidad en un conjunto de entidades.<\/P>
>>> workspace = #ruta a carpeta o geodatabase o conjunto de entidades
>>>
>>> _, _, filenames = next(arcpy.da.Walk(workspace, datatype="FeatureClass"))
>>> filenames
[u'canadwshed_p.shp', u'plots.shp']
>>>
>>> #o iterando sobre clases de entidad o shape files
>>> for file in next(arcpy.da.Walk(workspace, datatype="FeatureClass"))[2]:
... print file
canadwshed_p.shp
plots.shp
>>>
<\/code><\/pre>
<\/P>
En el primer ejemplo, creo un objeto Workspace Walker desechable que no tengo que preocuparme por mantener o descomponer. En el segundo ejemplo, llamar a next() dentro del bucle for me permite eliminar un bucle extra cuando solo me interesa un nivel de datos geoespaciales.<\/P>
<\/P>
Como ocurre con la mayoría de las cosas en la vida, no hay solo una forma de listar clases de entidad en una geodatabase o shape files en una carpeta. De hecho, la función ArcPy Walk es el nuevo jugador en el bloque introducido en ArcGIS 10.1 SP1. Antes de ArcPy Walk, un usuario podía usar una de las muchas funciones listadoras de ArcPy (ListDatasets, ListFeatureClasses, ListFiles, ListRasters, ListTables, y ListWorkspaces) o la función ArcPy Describe . Tiende a preferir ArcPy Walk sobre las otras debido a su facilidad de uso y similitud con la funcionalidad incorporada de Python.<\/P>
<\/P>
La razón principal para esta publicación del blog es compartir un área donde la función ArcPy Walk tropieza, es decir, fuentes de datos en memoria. Mientras que los métodos más antiguos para listar fuentes de datos funcionan con espacios de trabajo en memoria, ese no es el caso con 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'>
>>>
>>> #usando ArcPy Walk
>>> next(arcpy.da.Walk('in_memory'))[2]
[]
>>>
>>> #usando funciones listadoras de 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']
>>>
>>> #usando función Describe de ArcPy
>>> [child.name for child in arcpy.Describe('in_memory').children]
[u'test_tbl', u'test_fc', u'test_rd']
>>>
<\/code><\/pre>
<\/P>
No soportar espacios de trabajo en memoria no es mucho más que un tropiezo, pero sigue siendo un tropiezo. Después de todo, la documentación dice que el primer parámetro es el "espacio de trabajo a nivel superior" y sin embargo no se menciona que los espacios de trabajo en memoria no están soportados. Afortunadamente para los usuarios, existen al menos dos formas más para listar fuentes de datos en memoria.<\/P>
<\/P>
ACTUALIZACIÓN 06/2017:<\/STRONG><\/P>
<\/P>
Desde que escribí esta publicación hace casi 18 meses (Sé que "el tiempo vuela", pero aún así, ¿18 meses ya? <\/EM>), he descubierto que el problema con ArcPy Walk y los espacios de trabajo en memoria es más matizado de lo que originalmente pensé. Permítanme demostrar:<\/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'>
>>>
>>> # usando ArcPy Walk con "GPInMemoryWorkspace" en lugar del común "in_memory"
>>> next(arcpy.da.Walk('GPInMemoryWorkspace'))[2]
[u'test_tbl', u'test_fc', u'test_rd']
>>> <\/code><\/pre>
<\/P>
Entonces, resulta que ArcPy Walk funciona perfectamente con espacios de trabajo en memoria cuando realmente sabe que le estás apuntando a un espacio de trabajo en memoria. La parte realmente frustrante y hasta lamentable es que esto simplemente se trata de semántica y Esri todavía no puede arreglarlo. Funcionalmente, ArcPy Walk ya funciona con espacios de trabajo en memoria, solo que la función no sabe que todos los demás y todas las demás herramientas se refieren a esos espacios como "in_memory" en lugar de "GPInMemoryWorkspace".<\/P>
