Ik twijfelde of ik een blogpost zou schrijven of gewoon een discussie zou openen in de Python ruimte. Het is al een tijd geleden sinds ik iets aan mijn blog heb bijgedragen, dus ik ga voor het eerste.<\/EM><\/P>
<\/P>
De ArcPy Data Access Walk functie (arcpy.da.Walk<\/SPAN>) is een echte werkpaardfunctie, en ik vertrouw er behoorlijk op. De ArcPy Walk functie is een voorbeeld waarbij Esri het goed heeft gedaan met hun Python-implementatie. Ik kan niet zeggen wat hun ontwerpdoel was, maar het lijkt vrij duidelijk dat het doel was om een georuimtelijk-bewuste versie te maken van Python's os.walk functie. De namen zijn hetzelfde, veel van de parameters zijn hetzelfde, de resultaten zijn vergelijkbaar, enzovoort.... Ik denk dat het nabootsen van deze lang bestaande, native Python-functionaliteit in ArcPy een succes was omdat het geen perfect wiel opnieuw uitvond, d.w.z. gebruikers die bekend zijn met os.walk kunnen gemakkelijk overstappen naar het gebruik van arcpy.da.Walk.<\/P>
<\/P>
Hoe graag ik de ArcPy Walk functie ook mag, er zijn een paar kleine problemen die ik ermee heb. Het eerste is een documentatieprobleem, of beter gezegd gebrek aan documentatie. Een van de parameters van de Walk functie is datatype. De documentatie bevat een tabel die alle acceptabele argumenten voor datatype opsomt, maar er is geen daadwerkelijke documentatie over de datatypes zelf. Als je naar de datatypenamen kijkt, lijken de meesten voor de hand liggend, dus misschien heeft Esri besloten dat ze die niet hoefden te documenteren.<\/P>
<\/P>
Hoe beschrijvend een naam ook op het eerste gezicht lijkt, gebrek aan documentatie leidt meestal tot ambiguïteit en verwarring. Bijvoorbeeld, wat valt er onder "FeatureClass"? Uiteraard zou men aannemen dat een feature class in een geodatabase wordt gedekt, maar hoe zit het met shape files? Zijn shape files feature classes? In Esri-land is het antwoord meestal "Ja", maar niet altijd. De echte raadsel is het "Geo" datatype aangezien dit shape files omvat maar niet feature classes in een geodatabase. Feature classes zijn niet "geo?" Hoe belangrijk documentatie ook is voor libraries/APIs, dat is niet de hoofdreden om vandaag te schrijven.<\/P>
<\/P>
Een van mijn favoriete ArcPy Walk patronen is om Python's ingebouwde next()<\/SPAN> functie één keer aan te roepen om een lijst terug te krijgen van shape files in een map of feature classes in een geodatabase of feature classes in een feature dataset.<\/P>
>>> workspace = #pad naar map of geodatabase of feature dataset
>>>
>>> _, _, filenames = next(arcpy.da.Walk(workspace, datatype="FeatureClass"))
>>> filenames
[u'canadwshed_p.shp', u'plots.shp']
>>>
>>> #of itereren over feature classes of shape files
>>> for file in next(arcpy.da.Walk(workspace, datatype="FeatureClass"))[2]:
... print file
canadwshed_p.shp
plots.shp
>>>
<\/code><\/pre>
<\/P>
In het eerste voorbeeld maak ik een wegwerp Workspace Walker object dat ik niet hoef te bewaren of af te breken. In het tweede voorbeeld stelt het aanroepen van next() in de for-lus me in staat om een extra lus over te slaan wanneer ik alleen geïnteresseerd ben in één niveau van georuimtelijke data.<\/P>
<\/P>
Zoals bij de meeste dingen in het leven is er niet slechts één manier om feature classes in een geodatabase of shape files in een map op te sommen. In feite is de ArcPy Walk functie de nieuwkomer die werd geïntroduceerd in ArcGIS 10.1 SP1. Voorafgaand aan ArcPy Walk kon een gebruiker gebruik maken van één van de vele ArcPy lijstfuncties (ListDatasets, ListFeatureClasses, ListFiles, ListRasters, ListTables, en ListWorkspaces) of de ArcPy Describe functie gebruiken. Ik geef de voorkeur aan ArcPy Walk boven de anderen vanwege het gebruiksgemak en de gelijkenis met ingebouwde Python-functionaliteit.<\/P>
<\/P>
De belangrijkste reden voor deze blogpost is om één gebied te delen waar de ArcPy Walk functie struikelt, namelijk in-memory gegevensbronnen. Terwijl oudere methoden om gegevensbronnen op te sommen werken met in-memory workspaces, is dat niet het geval met 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'>
>>>
>>> #gebruik makend van ArcPy Walk
>>> next(arcpy.da.Walk('in_memory'))[2]
[]
>>>
>>> #gebruik makend van ArcPy lijstfuncties
>>> 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']
>>>
>>> #gebruik makend van ArcPy Describe functie
>>> [child.name for child in arcpy.Describe('in_memory').children]
[u'test_tbl', u'test_fc', u'test_rd']
>>>
<\/code><\/pre>
<\/P>
Het niet ondersteunen van in-memory workspaces is niet meer dan een struikelblok, maar toch een struikelblok. Immers, de documentatie zegt dat de eerste parameter de "top-level workspace" is en toch wordt nergens vermeld dat in-memory workspaces niet worden ondersteund. Gelukkig voor gebruikers zijn er ten minste twee andere manieren om in-memory gegevensbronnen op te sommen.<\/P>
<\/P>
UPDATE 06/2017:<\/STRONG><\/P>
<\/P>
Sinds ik deze blogpost bijna 18 maanden geleden schreef (Ik weet dat "de tijd vliegt", maar toch al 18 maanden? ), ben ik tot ontdekking gekomen dat het probleem met ArcPy Walk en in-memory workspaces genuanceerder is dan ik oorspronkelijk dacht. Laat me dit demonstreren:<\/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'>
>>>
>>> # gebruik makend van ArcPy Walk met "GPInMemoryWorkspace" in plaats van gebruikelijke "in_memory"
>>> next(arcpy.da.Walk('GPInMemoryWorkspace'))[2]
[u'test_tbl', u'test_fc', u'test_rd']
>>> <\/code><\/pre>
<\/P>
Dus blijkt dat ArcPy Walk prima werkt met in-memory workspaces, wanneer het daadwerkelijk weet dat je naar een in-memory workspace verwijst. Het echt frustrerende deel hiervan, en zelfs enigszins betreurenswaardig, is dat dit simpelweg om semantiek gaat en Esri er nog steeds niet in slaagt dit te repareren. Functioneel werkt ArcPy Walk al met in-memory workspaces, alleen weet de functie niet dat iedereen en elk ander hulpmiddel die ruimtes aanduidt als "in_memory" in plaats van "GPInMemoryWorkspace".<\/P>
