Prepare-se para o inesperado – o Altova MissionKit resolve um mistério relacionado a formatos de números

Sempre que recebe dados de uma fonte externa, existe a possibilidade de que estes não cheguem no formato que espera. Isto pode exigir adaptações especiais para que uma solução de mapeamento e transformação de dados, que é rara e improvável, seja robusta e fiável no mundo real.

Processámos literalmente dezenas de ficheiros .gpx, cada um contendo centenas de coordenadas, através da ferramenta de mapeamento MapForce, da qual falamos no artigo do blogue "Serviço Web como Tabela de Consulta para Refinar Dados GPS". Um dia, ao processar um novo ficheiro, detetámos o erro abaixo, que impediu o mapeamento de funcionar corretamente:

Ao recorrer ao Altova MissionKit para combinar as funcionalidades do MapForce e do XMLSpy, conseguimos diagnosticar rapidamente o problema e desenvolver uma solução que também podemos reutilizar em futuros projetos de mapeamento.

Inicialmente, suspeitamos de um problema com os dados de entrada, por isso, abrimos o ficheiro no XMLSpy, onde ele passou os testes de estrutura correta e.. Validação de XML testes. Felizmente, cada ponto de dados tem um carimbo de data e hora único, por isso, procurámos por "23:06:22", que corresponde ao último conjunto de coordenadas GPS que foram processadas com sucesso. Esse carimbo de data e hora apareceu uma vez na linha 1772 do ficheiro de entrada.

Não havia nada de obviamente errado nos dados originais que se seguiram. Simplesmente comentámos o próximo ponto de dados e guardámos o ficheiro para repor o processo de mapeamento:

Desta vez, o processo de mapeamento foi concluído com sucesso:

Agora, desconfiávamos dos dados fornecidos pelo serviço web. Embora o Serviço Geológico dos Estados Unidos, através do seu Programa Nacional de Geoinformação, seja o responsável pelo serviço web, talvez a base de dados subjacente contivesse informações incorretas.

Inserimos um ficheiro .csv simples no mapeamento como uma saída alternativa e mapeámos os resultados de elevação para cada conjunto de coordenadas de origem, de forma a analisar a saída do serviço web.

Uma linha no ficheiro de saída "diagnostic.csv" continha o mesmo valor, entre aspas, que foi mencionado na mensagem de erro anterior:

É notação científica! O serviço web devolveu um número formatado em notação científica! A função de precisão decimal no nosso mapeamento de dados, que processa o resultado do serviço web, requer uma entrada decimal.

Conversão de tipos de dados

Uma possível estratégia seria escrever uma função que reconheça o resultado do serviço web como notação científica e calcule explicitamente o valor numérico. A mensagem de erro do MapForce, "Conversão para 'decimal falhou para '-1.24202767892712E-06'", sugere uma solução mais simples.

Este é um bom momento para refletir sobre os tipos de dados. O componente de serviço web na nossa configuração indica claramente que retorna uma cadeia de texto. O MapForce realiza automaticamente conversões de tipo de cadeia de texto para número decimal quando uma configuração conecta uma cadeia de texto como entrada para uma fórmula matemática. Na maioria dos casos, isto liberta os programadores da necessidade de pensar em conversões de tipo explícitas, à medida que os dados se movem entre diferentes formatos. Na nossa configuração, o MapForce realizou com sucesso a conversão de tipo de uma cadeia de texto para um número decimal 178 vezes, antes de encontrar a entrada em notação científica.

A notação científica é normalmente utilizada para números que são demasiado grandes ou demasiado pequenos para serem registados de forma conveniente em formato decimal. No MapForce, o tipo de dados decimal não especifica o tamanho ou o valor do número. Em vez disso, identifica o tipo decimal XML, que é uma sequência de caracteres numéricos com um ponto como separador decimal.

Em XML – e no MapForce – o tipo de dados "double" suporta a notação científica. Podemos converter explicitamente dados em notação científica para o tipo de dados "double" e, em seguida, arredondar o resultado.

Esta solução é fácil de testar através de uma configuração simples, utilizando ficheiros de texto tanto para a entrada como para a saída. Introduzimos uma variável simples antes da função de arredondamento e definimos o seu tipo de dados como "double". Para o nosso primeiro teste, utilizamos os dados obtidos do serviço web da USGS como entrada, permitindo-nos processar os mesmos dados sem ter de efetuar repetidamente as chamadas ao serviço web. Esta configuração também nos permite criar facilmente mais casos de teste com novos dados de entrada.

O processo de mapeamento foi concluído com sucesso, gerando o seguinte resultado:

Criar uma função para o utilizador

Funções do utilizador no MapForce são definidas num único ficheiro de mapeamento e podem ser adicionadas à Biblioteca de Funções para serem utilizadas em outros ficheiros de mapeamento, mesmo por vários utilizadores. As funções do utilizador também encapsulam operações complexas e ajudam a tornar o fluxo de dados geral de um projeto de mapeamento complexo muito mais rastreável.

Já tínhamos modificado a chamada simples do serviço web, escolhendo o banco de dados para a costa leste ou oeste dos Estados Unidos com base na longitude. Agora, adicionar tipagem explícita ao resultado torna a chamada da função "getElevation" ainda mais complexa. Optámos por definir tudo numa função definida pelo utilizador.

Aplicar a função do utilizador

No diagrama abaixo, inserimos a nova função getElevationUS.

Neste momento, é importante relembrar por que motivo arredondamos a altitude retornada pelo serviço web. O serviço web retorna um valor em metros, e duas casas decimais – ou seja, cada centímetro – representam menos de meio centímetro.

Poderíamos ter incluído a operação de arredondamento como parte da função getElevationUS, mas a função será mais útil em futuras mapeações de dados se não arredondar os dados de altitude originais.

A saída do mapeamento atualizado é apresentada abaixo, utilizando o mesmo ficheiro .gpx que causou o problema inicial. Procurámos no ficheiro de saída a marca de tempo 23:06:22, que utilizamos para encontrar as últimas coordenadas corretas antes do erro. O ponto a partir da linha 902 é aquele que falhou.

Inicialmente, ficámos desiludidos por todo este esforço ter resultado apenas num valor que se aproximava de zero. Depois, mapeámos as coordenadas suspeitas num mapa do Google:

Uma parte do percurso seguiu uma ponte sobre uma zona costeira sujeita a marés. Mesmo que nunca voltemos a usar a função "getElevationUS" em futuros mapeamentos de dados, é muito provável que outros ficheiros .gpx, referentes a outras viagens, passem por outras zonas costeiras sujeitas a marés, onde poderão gerar valores de altitude muito pequenos.

Se desejar utilizar as ferramentas em Altova MissionKit para criar funções personalizadas para as suas próprias associações de dados Clique aqui para descarregar uma versão de avaliação gratuita.