Préparez-vous à l'inattendu : Altova MissionKit résout une énigme concernant les formats de nombres

Chaque fois que vous recevez des données provenant d'une source externe, il est possible qu'elles n'arrivent pas dans le format que vous attendez. Cela peut nécessiter des adaptations spécifiques, et il est rare que cela se produise. Pour créer une solution de cartographie et de transformation de données fiable et robuste dans le monde réel, il est important de prendre en compte ces situations exceptionnelles.

Nous avons traité littéralement des dizaines de fichiers .gpx, chacun contenant des centaines de coordonnées, en utilisant la solution de cartographie MapForce dont nous avons parlé dans l'article de blog intitulé "Service web utilisé comme table de consultation pour affiner les données GPS". Un jour, nous avons traité un nouveau fichier et nous avons rencontré l'erreur suivante, qui a empêché le processus de cartographie de fonctionner :

En utilisant les fonctionnalités combinées de Altova MissionKit, notamment celles de MapForce et XMLSpy, nous avons rapidement identifié le problème et développé une solution que nous pourrons également réutiliser dans de futurs projets de transformation de données.

Nous avons d'abord suspecté un problème avec les données d'entrée, alors nous avons ouvert le fichier dans XMLSpy, où il a passé les tests de conformité syntaxique et.. Validation XML tests. Heureusement, chaque point de données possède un horodatage unique, nous avons donc recherché la valeur 23:06:22, qui correspondait au dernier ensemble de coordonnées GPS traitées avec succès. Cet horodatage est apparu une seule fois, à la ligne 1772 du fichier d'entrée.

Il n'y avait rien d'évident qui clochait dans les données sources qui suivaient immédiatement. Nous avons simplement commenté le point de données suivant, puis nous avons enregistré le fichier pour pouvoir refaire le traitement :

Cette fois, l'opération de cartographie s'est déroulée avec succès :

Nous étions maintenant suspicieux quant aux données renvoyées par le service web. Bien que le programme national de géospatialisation du Service géologique des États-Unis gère ce service web, il se pourrait que la base de données sous-jacente contienne des données incorrectes.

Nous avons inséré un simple fichier .csv dans la configuration de la cartographie comme sortie alternative, et nous avons associé les résultats d'altitude pour chaque ensemble de coordonnées sources afin d'examiner la sortie du service web.

Une ligne du fichier de diagnostic diagnostic.csv contenait la même valeur, entre guillemets, que celle mentionnée dans le message d'erreur précédent :

Il s'agit d'une notation scientifique ! Le service web a renvoyé un nombre formaté en notation scientifique ! La fonction de précision décimale de notre outil de mappage de données, qui traite les résultats du service web, nécessite une entrée décimale.

Conversion de types de données

Une stratégie possible serait d'écrire une fonction qui reconnaisse le résultat du service web comme une notation scientifique et qui calcule explicitement la valeur numérique. Le message d'erreur de MapForce, "La conversion en décimal a échoué pour '-1.24202767892712E-06'", suggère une solution plus simple.

C'est le moment idéal pour réfléchir aux types de données. Le composant de service web dans notre mappage indique clairement qu'il renvoie une chaîne de caractères. MapForce effectue automatiquement les conversions de type de chaîne de caractères en nombre décimal lorsque le mappage connecte une chaîne de caractères en entrée à une formule mathématique. Dans la plupart des cas, cela libère les développeurs de la nécessité de penser aux conversions de type explicites lorsque les données transitent entre différents formats. Dans notre mappage, MapForce a effectué avec succès la conversion de type d'une chaîne de caractères en nombre décimal à 178 reprises avant de rencontrer une valeur exprimée en notation scientifique.

La notation scientifique est généralement utilisée pour les nombres qui sont trop grands ou trop petits pour être facilement représentés sous forme décimale. Dans MapForce, le type de données décimal ne spécifie ni la taille, ni la valeur du nombre. Au lieu de cela, il identifie le type décimal XML, qui est une séquence de caractères numériques avec un point comme séparateur décimal.

En XML, et dans MapForce, le type de données "double" prend en charge la notation scientifique. Nous pouvons convertir explicitement des données en notation scientifique vers le type de données "double", puis arrondir le résultat.

Cette solution est facile à tester grâce à une configuration simple, en utilisant des fichiers texte pour les données d'entrée et de sortie. Nous avons inséré une variable simple avant la fonction d'arrondissement et nous avons défini son type de données comme "double". Pour notre premier test, nous avons utilisé les données récupérées auprès du service web de l'USGS comme données d'entrée, afin de traiter les mêmes données sans avoir à effectuer à nouveau les appels au service web. Cette configuration nous permet également de créer facilement de nouveaux cas de test avec de nouvelles données d'entrée.

Le processus de cartographie s'est déroulé avec succès, générant le résultat suivant :

Créer une fonction utilisateur

Fonctions utilisateur dans MapForce sont définies dans un seul fichier de mappage et peuvent être ajoutées à la bibliothèque de fonctions pour être utilisées dans d'autres fichiers de mappage, même par plusieurs utilisateurs. Les fonctions utilisateur permettent également de regrouper des opérations complexes et contribuent à rendre le flux de données global d'une conception de mappage importante beaucoup plus facile à suivre.

Nous avions déjà modifié l'appel simple du service web en choisissant la base de données en fonction de la longitude, en fonction de si l'utilisateur se trouvait dans la partie est ou ouest des États-Unis continentaux. Maintenant, l'ajout d'une définition explicite des types de données pour le résultat rend l'appel de la fonction "getElevation" encore plus complexe. Nous avons choisi de définir tout cela dans une fonction utilisateur.

Appliquer la fonction utilisateur

Dans le code ci-dessous, nous avons intégré la nouvelle fonction getElevationUS.

À ce stade, il est utile de rappeler pourquoi nous avons arrondi l'altitude renvoyée par le service web. Le service web renvoie une valeur en mètres, et deux décimales, soit chaque centimètre, représentent moins de douze millimètres.

Nous aurions pu intégrer l'opération d'arrondi dans la fonction getElevationUS, mais cette fonction sera plus utile pour les futures analyses de données si elle ne procède pas à l'arrondi des données d'altitude brutes.

Le résultat de la nouvelle cartographie est présenté ci-dessous, en utilisant le même fichier .gpx qui avait causé le problème initial. Nous avons recherché dans le fichier de sortie la mention "23:06:22", l'horodatage que nous avons utilisé pour trouver les dernières coordonnées correctes avant l'erreur. Le point suivant, à partir de la ligne 902, est celui qui a posé problème.

Au début, nous avons été déçus de constater que tous ces efforts se résumaient à une altitude qui arrondissait à zéro. Ensuite, nous avons repéré ces coordonnées suspectes sur une carte Google :

Une partie de l'itinéraire suivait un pont au-dessus d'une zone marécageuse soumise aux marées. Même si nous ne réutilisons jamais la fonction getElevationUS dans une future cartographie de données, il est très probable que d'autres fichiers .gpx, correspondant à d'autres trajets, traverseront d'autres zones marécageuses, ce qui pourrait générer davantage de valeurs d'altitude très faibles.

Si vous souhaitez utiliser les outils disponibles dans Altova MissionKit pour créer des fonctions personnalisées permettant de définir vos propres règles de correspondance de données Cliquez ici pour télécharger une version d'essai gratuite.