Prepárese para lo inesperado: Altova MissionKit resuelve un misterio relacionado con formatos de números

Cada vez que se reciben datos de una fuente externa, existe la posibilidad de que no lleguen en el formato esperado. Esto puede requerir adaptaciones especiales para que una solución de mapeo y transformación de datos, que se utiliza en situaciones reales, sea robusta y fiable, incluso en casos poco frecuentes.

Procesamos literalmente decenas de archivos .gpx, cada uno conteniendo cientos de coordenadas, utilizando la herramienta de mapeo MapForce de la que hablamos en la entrada del blog titulada "Servicio web como tabla de consulta para refinar datos de GPS". Un día, al procesar un nuevo archivo, nos encontramos con el siguiente error, que provocó que el mapeo fallara:

Utilizando las herramientas de Altova MissionKit para combinar las funcionalidades de MapForce y XMLSpy, pudimos diagnosticar rápidamente el problema y desarrollar una solución que también podemos reutilizar en futuros proyectos de mapeo.

Inicialmente, sospechamos que el problema estaba en los datos de entrada, por lo que abrimos el archivo en XMLSpy, donde superó las pruebas de estructura correcta y de validación XML. Afortunadamente, cada punto de datos tiene una marca de tiempo única, por lo que buscamos la marca de tiempo 23:06:22, que correspondía al último conjunto de coordenadas GPS que se procesaron correctamente. Esa marca de tiempo apareció una vez en la línea 1772 del archivo de entrada.

No se observó nada evidentemente incorrecto en los datos originales que seguían. Simplemente comentamos la siguiente entrada de datos y guardamos el archivo para volver a procesar la configuración

Esta vez, el proceso de mapeo se completó con éxito:

Ahora desconfiábamos de los datos que devolvía el servicio web. Aunque el Servicio Geológico de los Estados Unidos, a través de su Programa Nacional de Geoinformación, gestiona el servicio web, es posible que la base de datos subyacente contuviera información incorrecta.

Insertamos un archivo .csv sencillo en el sistema de mapeo como una salida alternativa y mapeamos los resultados de la elevación para cada conjunto de coordenadas de origen, con el fin de analizar la salida del servicio web.

Una de las líneas del archivo de diagnóstico "diagnostic.csv" contenía el mismo valor que se mencionaba en el mensaje de error anterior:

¡Es notación científica! El servicio web devolvió un número formateado en notación científica. La función de precisión decimal en nuestro sistema de mapeo de datos, que procesa el resultado del servicio web, requiere una entrada en formato decimal.

Conversión de tipos de datos

Una posible estrategia sería escribir una función que reconozca el resultado del servicio web como notación científica y calcule explícitamente el valor numérico. El mensaje de error de MapForce, "La conversión a decimal falló para '-1.24202767892712E-06'", sugiere una solución más sencilla.

Este es un buen momento para reflexionar sobre los tipos de datos. El componente de servicio web en nuestro mapeo indica claramente que devuelve una cadena de texto. MapForce realiza automáticamente conversiones de tipo de cadena a número decimal cuando un mapeo conecta una cadena como entrada a una fórmula matemática. En la mayoría de los casos, esto libera a los desarrolladores de tener que pensar en conversiones de tipo explícitas a medida que los datos se transfieren entre formatos. En nuestro mapeo, MapForce realizó con éxito la conversión de tipo de una cadena a un número decimal 178 veces antes de encontrar el valor en notación científica.

La notación científica se utiliza normalmente para números que son demasiado grandes o demasiado pequeños para ser representados de forma cómoda en formato decimal. En MapForce, el tipo de dato decimal no especifica el tamaño ni el valor del número. En cambio, identifica el tipo decimal de XML, que es una secuencia de caracteres que representan dígitos y utiliza un punto como separador decimal.

En XML, y también en MapForce, el tipo de dato "double" admite la notación científica. Podemos convertir explícitamente datos en notación científica al tipo de dato "double" y, posteriormente, redondear el resultado.

Esta solución es fácil de probar mediante una configuración sencilla, utilizando archivos de texto tanto para la entrada como para la salida. Insertamos una variable simple antes de la función de ajuste de precisión y asignamos su tipo de dato como "double". Para nuestra primera prueba, utilizamos los datos obtenidos del servicio web de la USGS como entrada, para procesar los mismos datos sin necesidad de realizar repetidamente las llamadas al servicio web. Esta configuración también nos permite crear fácilmente más casos de prueba con nuevos datos de entrada.

El proceso de mapeo se completó con éxito, generando la siguiente salida:

Crear una función de usuario

Funciones de usuario en MapForce se definen en un único archivo de mapeo y pueden añadirse a la Biblioteca de Funciones para su uso en otros archivos de mapeo, incluso por múltiples usuarios. Las funciones de usuario también encapsulan operaciones complejas y ayudan a que el flujo de datos general de un diseño de mapeo extenso sea mucho más fácil de rastrear.

Ya habíamos modificado la sencilla llamada al servicio web, eligiendo la base de datos para la parte este u oeste de los Estados Unidos continentales en función de la longitud. Ahora, añadir una definición explícita de los tipos de datos al resultado hace que la llamada a "getElevation" sea aún más compleja. Decidimos definir todo dentro de una función de usuario.

Aplicación de la función del usuario

En el siguiente diagrama, hemos incorporado la nueva función getElevationUS.

En este punto, es importante recordar por qué redondeamos la altitud que devuelve el servicio web. El servicio web devuelve un valor en metros, y dos decimales, es decir, cada centímetro, representa menos de media pulgada.

Podríamos haber incluido la operación de redondeo como parte de la función "getElevationUS", pero la función será más útil en futuras aplicaciones de mapeo de datos si no redondea los datos de elevación originales.

A continuación se muestra el resultado del nuevo proceso de mapeo, utilizando el mismo archivo .gpx que causó el problema inicial. Buscamos en el archivo de salida la marca de tiempo 23:06:22, que utilizamos para encontrar las últimas coordenadas correctas antes del error. El siguiente punto, a partir de la línea 902, es el que generó el fallo.

Inicialmente, nos decepcionó que todo este esfuerzo se redujera a una elevación que, al redondear, daba 0. Luego, ubicamos las coordenadas sospechosas en un mapa de Google:

Una parte de la ruta seguía un puente que cruzaba una ensenada influenciada por las mareas. Aunque es poco probable que volvamos a utilizar la función getElevationUS en futuros proyectos de mapeo de datos, es muy posible que otros archivos .gpx, correspondientes a otros viajes, crucen otras ensenadas influenciadas por las mareas, donde podrían generar valores de elevación aún más pequeños.

Si desea utilizar las herramientas en Altova MissionKit para crear funciones personalizadas que le permitan definir sus propios mapeos de datos Haga clic aquí para descargar una versión de prueba gratuita..