Migrando recursos de Geographics a Bentley Map

Há algum tempo, estamos falando sobre o que significa fazer o salto da Microstation Geographics para Bentley Mapfalamos sobre como ambos trabalham esquemas e alguns benefícios importantes do Bentley Map. Já em um post falei sobre como é possível migre a estrutura do projeto, neste caso, eu quero mastigar sobre como migrar mapas com atributos geográficos para classes de recursos xfm.

Embora, uma estrutura de projeto construída com o Geographics Legacy possa ser importada do Bentley Map, isso não significa que os atributos que os objetos tenham sejam reconhecidos pelo novo projeto, eles devem ser atribuídos.

Como a geografia funcionou

No estilo Geographics os objetos através de um MSLINK tinham uma associação a um banco de dados, que era tudo que o objeto possuía, um link do tipo OLE. Este MSLINK associou o objeto gráfico do arquivo dgn através do MAPNAME da tabela MAPS e através do MSCATALOG para identificar de onde obter os dados do Entitynum. Além disso, havia mesas duplas para projetos compatíveis com Intergraph que normalmente carregavam um UG antes.

Além disso, o objeto possuía um FEATURE, embora este não fosse dinâmico, ao atribuí-lo adquiria as propriedades definidas para aquele atributo (incluindo comandos) e estava associado à tabela CATEGORY. Um objeto poderia ter mais de um atributo e a prioridade era aquela atribuída pelo estilo definitivo, que FEATURE e outros objetos vinculados à base foram associados à tabela MSCATALOG onde foram atribuídos a tal entitynum que era o umbigo de tudo.

Então, o arquivo index.dgn (MAPID), de modo que cada tabela ligada à Geografia tenha pelo menos dois campos: MSLINK (número de entidade exclusivo em cada mapa) que é sempre a chave primária e MAPID ( em qual mapa é armazenado, é exclusivo no catálogo do mapa), que é uma chave estrangeira para a tabela MAPS.

Portanto, a única maneira de interagir com os dados foi conectada à base, e as operações com ele foram feitas para a besta  como atualizar as tabelas que continham informações sobre o objeto, como área, perímetro e coordenadas, para que o Publisher soubesse como exibi-lo. Você também pode extrair Labels que caiu como objetos do banco de dados com o mesmo link do objeto conectado.

Parece simples, mas me custou um mundo para entender isso da MGE, e o doloroso é que toda essa fumaça não ajuda muito para um projeto com o Bentley Map.

Como o Bentley Map funciona

Um projeto Bentley Map mantém a mesma lógica de Categoria, atributo, mapa, objeto; mas, neste caso, substituindo a forma de link de dados OLE por XML, muitas das mudanças de processo.

Nesse caso, o objeto no mapa pode ter dados armazenados (no mesmo dgn), que é entendido como xml ou como Bentley wfm o chama. Então, também muda que agora os objetos podem ter apenas um atributo e ser associados espacialmente por regras topológicas; Antes, o limite da macieira podia ser a mesma linha e também o limite da propriedade, agora devem ser objetos separados mas com uma associação topológica tal que ao modificar um o outro também o seja.

Portanto, a interação com os dados está a apenas um clique de distância, esteja você conectado ou não ao projeto, você pode ler tudo o que foi deixado como data xfm. E então o manuseio de Labels e propriedades de atributos, apenas fazendo alterações a partir do Administrador Geoespacial. Anteriormente, fazer alterações era apenas dinâmico na visualização por meio do Publisher, mas os objetos exigiam que o atributo fosse removido e reatribuído.

Além disso, o Bentley Map oferece opções para criar formulários de dados, processos sequenciais, comandos associados (métodos / operações / domínios / critérios / relatórios) e outras piruetas que facilitam a construção de dados.

Algo não mudou muito, e é que, como os usuários dizem ESRI, essa fumaça ocupa o verde para mastigar e digerê-lo.

O problema

Agora, a migração da estrutura de um projeto é possível e, em seguida, adicione funcionalidades através do Administrador Geoespacial, o que significaria estar pronto para continuar com os dados de alimentação, mas o dilema é:

E os mapas construídos com Geographics?

Para este Bentley não projetou nenhum artefato que permita converter objetos de um projeto Legacy para um xfm ... Que merda é o negócio!

A proposta que eu sugiro é a que eu vejo viável, depois de conversar com um amigo que do Chile me contatou, depois de vários e-mails que chegamos a uma Geofumada desactualizada, mas funcional.

Passo 1. Exportando para formar arquivos

De um projeto geográfico aberto, a opção de exportar atributos para dar forma aos arquivos é escolhida (arquivo / exportação / SHP) Isso deve ser feito para cada integrado existente no mapa.

Seria necessário lutar um pouco quando os objetos são centroides / limites, pois seria necessário passá-los para formas, transferindo o ligue.

A exportação também pode ser feita no Mapinfo, como é preferível.

Passo 2. Importação do Mapa de Bentley

E agora, do Bentley Map Project, escolhemos a opção de importação (Tipos de dados de arquivo / importação / SIG), com isso a janela Interoperabilidade, clique com o botão direito do mouse em importações e selecione nova importação.

Clicar com o botão direito em Imoport1 seleciona um arquivo ou um diretório inteiro. É possível importar arquivos de formaum Mapinfo arquivos tipo mif e guia.

Ao jogar o classe de recurso podemos ver que é possível selecionar o nível, a cor, a transparência e outras propriedades.

Para atribuí-lo ao integrado O que nos interessa é suficiente para atribuir a camada (nível).

Quão doloroso

Como Memin disse naquele antigo pakin mexicano:

"Dana!"

você precisaria fazer isso para cada recurso em cada mapa em cada categoria em cada projeto.

Para fazer isso, você pode salvar o importar, por isso só é chamado arquivo por arquivo ou por diretório. A verdade é que é difícil transformar dados, principalmente se estiverem em arquivos separados. Não ia doer, trabalhar um vba em .NET para aut
Pule o processo em vez de fazer essa tarefa a pé, o que pode levar a mais do que alguns suicídios por dia. O principal problema é que para dar o salto continuamos dependendo de uma consultoria especializada (e fumegante) para entender os meandros do Bentley Map e da Geografia, é possível, mas as aplicações não deveriam ser tão astrais (admitamos, ambos são) para usuários comuns.

Ainda mais doloroso, se no original dgn havia informações armazenadas na história... o novo arquivo não terá nenhum histórico.

Em conclusão

A solução que apresento é viável se você tiver poucos dados, ou se eles estiverem armazenados em um cartucho espacial, então a triste conclusão é que a migração do Geographics para o Bentley Map não é tão fácil, devido à transformação dos dados. Se o Administrador Geoespacial, como ele disse antes, é uma dor de dente, a migração de dados pode ser ainda mais dolorosa, a menos que Bentley pense em soluções para seus usuários que não desejam passar de um dia para o outro.

Falar com amigos geofumados fez uma analogia imprudente, mas desde hoje é um dia aborrecido em um hotel de má morte e a comparação é tão certa, com sua permissão eu vou usá-lo:

"Não é como mudar de parceiros ...

... poderia ser como perder novamente a virgindade "