<\/HEAD>
Olá,<\/P>
<\/P>
Estamos trabalhando no desenvolvimento de interfaces para sincronizar o GIS (no ESRI Geodatabase) com o sistema enterprise asset management. Os conjuntos de dados da rede no Geodatabase estão habilitados com GLOBALID e registrados como versionados. Como parte da sincronização inicial, o GLOBALID junto com outros atributos são enviados para o sistema enterprise asset management e, a partir daí, o GLOBALID atua como chave primária para sincronizar quaisquer atualizações do GIS. Usando as alterações de versão, conseguimos identificar e sincronizar as mudanças realizadas no GIS (ou seja, inserções \/ atualizações \/ exclusões) com a ajuda do GLOBALID. Agora estamos enfrentando dois casos, ou seja, abandono de ativo e divisão de ativo.<\/P>
<\/P>
Assume-se que existem duas classes de feição como parte do modelo de dados para manter os recursos abandonados, ou seja, Linha Abandonada e Ponto Abandonado. Estamos usando as ferramentas de edição de rede do ArcGIS para abandonar \/ reativar feições. No caso de abandonar uma feição, observa-se que a feição está sendo excluída da camada fonte e uma nova feição é inserida na classe de feição abandonada (com um novo GLOBALID). Como estamos perdendo o GLOBALID da camada fonte, existe alguma maneira melhor de rastrear \/ identificar o GLOBALID da camada fonte a partir da camada de feição abandonada? Notamos o identificador da instalação como um dos campos, mas esse campo normalmente é usado para manter valores únicos? <\/P>
<\/P>
Além disso, durante a divisão do ativo, queremos manter a relação pai \/ filho entre a feição pré-divisão e as feições criadas após a divisão. Estamos assumindo que um campo original GLOBAL ID (além do campo padrão GLOBALID da ESRI) popula o GLOBALID original \/ pai em caso de divisão. Essa suposição funciona bem ou existe alguma abordagem alternativa para lidar com esse cenário?<\/P>
<\/P>
Será de grande ajuda se pudermos conhecer a forma padrão que as utilities seguem para superar os cenários mencionados acima.<\/P>
<\/P>
Atenciosamente,
Rama Rao<\/P><\/BODY><\/HTML>
