O ArcCatalog diz que as referências espaciais não ' t coincidem entre o conjunto de dados do recurso e a classe do recurso com o mesmo sistema de coordenadas?

O mesmo sistema de coordenadas nem sempre é um sistema de coordenadas idêntico . Encontrei situações em que algumas operações e ferramentas de geoprocessamento pensam que as classes de recursos não compartilham um sistema de coordenadas comum porque o nome descritivo da projeção difere (“Yukon Albers” vs “Albers – personalizado”), embora os parâmetros sejam idênticos, ou por causa de posições decimais diferentes (norte falso 500000,00 vs 500000,0000).

O que eu normalmente faço é garantir que os sistemas de coordenadas Feature Dataset (e F.class) sejam criados com nosso arquivo .prj padrão colocado no topo de C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (torna o CS disponível com menos cliques) e / ou copiando o CS de um modelo de classe de recurso mestre armazenado em algum lugar sempre à mão.

Em parte em resposta a isso problema, eu também tenho um conjunto de dados de recursos vazio (D:\s.gdb\_template) no qual canalizo todos os nossos dados como um filtro de primeira etapa antes de fazer qualquer outra coisa com eles. Em um sistema de coordenadas comum, isso também garante que a precisão e o domínio espacial etc. sejam idênticos.

Atualização: Veja a resposta de Andy sobre o uso de python, apenas 2 linhas, para copiar o sistema de referência espacial Feature Dataset de uma classe de recurso template. Isso funcionou para mim no ArcCatalog 10.3 quando o método interativo de definir SR selecionando uma classe de recurso para importar uma não funcionou.

Comentários

• Wouldn ‘ t essas pequenas mudanças no nome da impressão bonita ou nas posições decimais que você mencionou estão presentes no arquivo .prj que ‘ é exportado com a opção Salvar como ? Se sim, por que os arquivos prj diffing não mostram nada? Eu me perguntava se pequenas diferenças na resolução x, y poderiam estar causando o conflito também.
• Pode ser o arquivo .prj criado com ” Salvar como ” não é exatamente igual ao armazenado internamente. Eu uso um conjunto de dados de recursos ” filtro ” para garantir resolução espacial comum, etc.
• I ‘ Vou adicionar uma faceta adicional a isso: Às vezes, conjuntos de dados de outras fontes serão gerados como contendo valores M e Z quando na verdade não têm M ou Z.Eu ‘ descobri que algumas ferramentas ESRI detectam o sistema de coordenadas Z vazio como incompatível, apesar do fato de que os sistemas de coordenadas X / Y realmente correspondem exatamente.

Esta é uma explicação e não uma resposta.

Nós (Esri) fazemos testes bastante restritos de nomes e valores do sistema de referência de coordenadas. O teste “é igual” não retornará uma falha ao comparar 500000,00 e 500000,000000, mas poderá falhar se um for realmente 500000,0 e o outro 500000,00000005. Estamos trabalhando para adicionar apelidos para nomes de modo que “é igual” passe mais.

Como mindless.panda e matt wilkie mencionaram, as diferenças podem estar em outros valores de uma referência espacial. referência inclui o sistema de referência de coordenadas e os valores de armazenamento / processamento. Para armazenamento: xy, ze resolução e extensão de medida. Para processamento: xy, ze valores de tolerância de medida. Qualquer diferença entre estes pode causar um erro diferente.

Comentários

• sua resposta é muito apreciada. Eu realmente gostaria de ver o tratamento de erros, particularmente no que é relatado ao usuário, melhorar no ArcGIS. Mais erros informativos são necessários, com a opção de obter informações ainda mais detalhadas, se desejado. Mais uma vez, obrigado à ESRI por responder.
• Apoio a proposta para fornecer mais informações sobre os erros. nas últimas duas semanas, recebi o mesmo erro (Error code: 999999: Error executing function. Description: This is a generic error for which the cause of the error does not have an appropriate error ID. ) devido a uma série de problemas. mensagem furiosa para receber, pois nada posso fazer a não ser tentar executar o que fiz uma segunda vez para ver se o erro se repete ou desistir e usar outro método (ou software, o que é cada vez mais o caso).

Aqui está o que fiz para resolver o problema (usando o Arcpy no ArcGIS 10.0) –

Isso pressupõe o seguinte:

• FGDB – C: \ gisdata \ Test.gdb
• Classe de recurso – C: \ gisdata \ Test.gdb \ bldg

Você pode modificar seus caminhos e nomes de objetos no código e colá-los na janela Python no ArcCatalog.

sr = arcpy.Describe(r"C:\gisdata\Test.gdb\bldg").spatialReference arcpy.CreateFeatureDataset_management(r"C:\gisdata\Test.gdb", "MyFeatureDataset", sr) 

Após o conjunto de dados do recurso é criado, você pode arrastar e soltar as classes de recursos.

Comentários

• Obrigado! Isso funcionou para mim hoje em uma situação em que usar a ferramenta interativa para definir o novo sistema de coordenadas do conjunto de dados de recurso selecionando uma classe de recurso existente não funcionou (v10.3).

Este problema estava me matando! Depois de salvar um monte de classes de recursos de um arquivo CAD, tentei várias vezes definir seus sistemas de coordenadas e organizá-los em conjuntos de dados de recursos. Eu tentei definir todos os f.classes e f.datasets necessários da projeção WGS_1984_UTM_42N oficial da ESRI, bem como definir a projeção para o conjunto de dados e importar essa projeção para os f.classes usando a ferramenta Define Projection. Nenhuma f.classes iria colar, ou eu iria e as outras não.

Muito obrigado a @Matt Wilkie em neste post , a ferramenta Classe de recurso para classe de recurso parece ter resolvido o problema. Ele importa com sucesso as f.classes para o conjunto de dados desejado, mesmo que eu ainda não tenha definido o sistema de coordenadas para a f.class em questão.

Além disso, descobri que Feature Class to Geodatabase (multiple) script funciona muito bem para mover f.classes para um f.dataset em massa, exceto que isso deve ser feito de Geodatabase para outro ( não em um f.dataset na mesma geodatabase). Parece que isso ocorre porque o script não renomeia automaticamente os f.classes quando eles são copiados (ou pede ao operador um novo nome, como em Feature Class para Feature Class). No entanto, como apontado por outros (mesmo tópico vinculado acima), o erro fornecido é um 999999 genérico.

I teve esse problema quando simplesmente queria mover uma classe de recurso para um conjunto de dados de recurso em um GeoDatabase. Fiz meu conjunto de dados de recursos e garanti que ele tivesse o mesmo sistema de coordenadas. Repetidamente, recebi “Falha ao colar xyz As referências espaciais não correspondem” A solução mais rápida que descobri foi importar a referência espacial idêntica em meu conjunto de dados recém-criado da classe de recurso que eu queria importar para ele. Na segunda etapa do assistente “Criar novo conjunto de dados de recurso”.

Não sei por que as referências espaciais são diferentes.

Comentários

• Olá, @Alan! Obrigado por compartilhar sua experiência e bem-vindo ao nosso site.
• Olá Alan, a criação de um novo conjunto de dados de recursos / assistente de classe isn ‘ t sempre puxando todos os valores de armazenamento / processamento quando ” sistema de coordenadas de importação ” é usado.Estamos ‘ trabalhando para consertá-lo. Eu acho que é isso que você ‘ está encontrando.
• Eu ‘ m vendo este problema – mesmo se eu criar o conjunto de dados de recurso, usar o mecanismo de importação e selecionar a classe de recurso, ainda posso ‘ arrastar / copiar a classe de recurso para o conjunto de dados de recurso recém-criado sem o erro mencionado.

Acho que uma das mensagens para a ESRI é fornecer um parâmetro mais específico diferenças informações de depuração quando esse erro ocorre. Eu também encontrei esse erro mesmo depois de controlar cuidadosamente os sistemas de referência espacial e projeções, como acho que a maioria dos usuários de GIS faz.

Eu descobri o procedimento de usar os recursos do ArcToolbox Copy para corrigir mensagens de erro que ocorrem quando os mecanismos de importação ou cópia são usados. Aqui, estamos dependendo do procedimento da caixa de ferramentas Copiar recursos para resolver corretamente as diferenças de referência ou projeção antes de introduzir a classe de recursos no conjunto de dados de recursos.

Eu até tentei criar o conjunto de dados de recursos com um sistema de projeção definido no tempo de criação do conjunto de dados e, em seguida, projetar classes de recursos no conjunto de dados de recursos usando a ferramenta de projeção ArcToolbox com a mesma projeção, e ainda recebo o erro descrito aqui quando tento importar ou copiar a classe de recursos para o conjunto de dados.

Estes problemas do sistema de coordenadas tornam-se mascarados quando você usa dados no ArcMap. Uma vez que o ArcMap executa projeções em tempo real, várias classes de recursos, cada uma com diferentes projeções, podem ser adicionadas a um mapa ArcMap sem que o usuário perceba. ArcMap avisará sobre sistemas de referência de coordenadas diferentes.