Alterando o caminho da fonte de dados envolvendo o conjunto de dados do recurso em arquivos * .lyr usando o ArcPy?

11

Como alterar os caminhos de dados de origem para cada arquivo de camada na pasta X usando o arcpy?

Eu segui Atualizando e corrigindo fontes de dados com o arcpy.mapping da melhor maneira possível, mas tudo o que recebo é inútil, o Runtime error <type 'exceptions.ValueError'>: Layer: Unexpected errorque não me diz o suficiente para solucionar o que está errado ou faltando.

Aqui está o código (simplificado para testar um arquivo de camada única):

import arcpy, os

fname = r'K:\Layers\xxx.lyr'
lyr = arcpy.mapping.Layer(fname)
oldpath = lyr.workspacePath
print 'oldpath: ', oldpath
lyr.findAndReplaceWorkspacePath(oldpath, r'C:\some\other.gdb')
print 'newpath: ', lyr.workspacePath

e os resultados:

oldpath:  K:\Canvec_Utility\Temp.gdb
Traceback (most recent call last):
  File "x10x.py", line 12, in <module>
    lyr.findAndReplaceWorkspacePath(oldpath, r'C:\some\other.gdb')
  File "C:\ESRI\ArcGIS\Desktop10.0\arcpy\arcpy\utils.py", line 181, in fn_
    return fn(*args, **kw)
  File "C:\ESRI\ArcGIS\Desktop10.0\arcpy\arcpy\_mapping.py", line 601, in findAndReplaceWorkspacePath
    return convertArcObjectToPythonObject(self._arc_object.findAndReplaceWorkspacePath(*gp_fixargs((find_workspace_path, replace_workspace_path, validate), True
)))
ValueError: Layer: Unexpected error

((seção 'atualização' movida para uma resposta))

arcpy arcgis-10.0 layers

— Matt Wilson
fonte

o Runtime error...citado acima é do shell python interativo no Arccatalog, que não fornece retorno. Os resultados com traceback são copiados de um shell de comando.

— Matt Wilkie

1

Você está movendo dados para dentro ou para fora de um conjunto de dados de recursos e de uma área de trabalho?

— geographika

@geographika: sim, o FDS está mudando, assim como o espaço de trabalho. Fui enganado pela documentação que diz que não especifica o FDS, e que mxd e lyr os ignoram. Validar, por outro lado, não os ignora, ou pelo menos não completamente (veja minha resposta).

— 226117 #

7

Parece que o método correto a ser usado ao alternar áreas de trabalho E conjuntos de dados de recursos é lyr.replaceDataSource () . Aqui está o meu script de trabalho:

''' Change the datasource path for the given layer file '''

import arcpy, os

# layer file to re-path
fname = arcpy.GetParameterAsText(0)
# new path to workspace containing the feature class
target_wspace = arcpy.GetParameterAsText(1)
# where to save the layer files
savedir = arcpy.GetParameterAsText(2)

lyr = arcpy.mapping.Layer(fname)

fixed_fname = os.path.join(savedir, lyr.longName)

print '\nOld layer properties (%s)' % (fname)
print 'workspace:\t', lyr.workspacePath
print 'full path:\t', lyr.dataSource

try:
    lyr.replaceDataSource(target_wspace, 'FILEGDB_WORKSPACE', lyr.datasetName, True)
    lyr.saveACopy(fixed_fname)
except:
    print arcpy.GetMessages()

print '\nNew layer properties (%s)' % (fixed_fname)
print 'workspace:\t', lyr.workspacePath
print 'full path:\t', lyr.dataSource

del lyr

Nos testes, parece que validar neste método é diferente novamente: verifica se o novo espaço de trabalho é válido, mas ignora a classe de recurso e os conjuntos de dados do recurso - o que significa que não retornará um erro se o FC de destino não estiver lá.

Por outro lado, se o FC de destino estiver presente, mesmo dentro de um conjunto de dados de recurso diferente, o novo caminho da fonte de dados será adaptado adequadamente, independentemente de a validação ser verdadeira ou falsa.

Atualização: agora no Github para facilitar o compartilhamento e a revisão.

— Matt Wilson
fonte

Isso funciona quando eu quero substituir o arquivo .lyr source shp por um novo? Recebo ValueError: Layer: erro inesperado.

— GeorgeC

@ GeorgeC - Eu sei que esta é uma postagem antiga, mas caso alguém encontre isso através do mecanismo de pesquisa, a solução para esse erro provavelmente eliminará o .shp do nome do conjunto de dados. IOW o terceiro arg para replaceDataSource precisa ser "newfile" não "newfile.shp"

— perrygeo

6

O inútil unexpected errorneste caso significa algo como "novo caminho não existe" . O validateparâmetro opcional é padronizado como True se não for especificado. Com false, o script é concluído sem erros, mas os arquivos de camada resultantes ainda estavam quebrados, mesmo que o caminho de destino e a classe de recurso existam.

...    
lyr.findAndReplaceWorkspacePath(oldpath, r'C:\some\other.gdb', False)
...

resultado

oldpath:  K:\code\Canvec\Scripts\Temp.gdb
newpath:  C:\some\other.gdb

Além de inicialmente não saber validar como padrão, true, um bug ou pelo menos algum comportamento muito peculiar dificultava a solução de problemas. Atualizar e corrigir fontes de dados com arcpy.mapping diz Não incluir os nomes dos conjuntos de dados do recurso no caminho da área de trabalho. Os conjuntos de dados do recurso fazem parte da área de trabalho. Se uma classe de recurso, por exemplo, for movida de uma classe de recurso independente para um conjunto de dados de recursos, um documento de mapa ainda será aberto sem que a camada seja quebrada " e " Se uma camada ou tabela em um documento de mapeamento ou arquivo de camada é movido para dentro ou para fora de um conjunto de dados de recursos, seus links não devem ser quebrados ".

Acontece que validar tem um ângulo ligeiramente diferente sobre isso. Sim, não importa em que lugar do novo geodatabase (espaço de trabalho) a classe de recurso de destino reside , no nível superior ou em um conjunto de dados de recursos completamente diferente. No entanto, o espaço de trabalho de destino deve conter um conjunto de dados do recurso com o mesmo nome ou validar falhas .

Fontes :

— Matt Wilson
fonte