Aspettatevi l'inaspettato: Altova MissionKit risolve un mistero legato ai formati numerici

Ogni volta che si ricevono dati da una fonte esterna, esiste la possibilità che questi non arrivino nel formato previsto. Questo può richiedere soluzioni specifiche per gestire situazioni rare e improbabili, al fine di rendere una soluzione di mappatura e trasformazione dei dati realmente efficace e affidabile.

Abbiamo elaborato letteralmente decine di file .gpx, ognuno contenente centinaia di coordinate, utilizzando il sistema di mappatura MapForce di cui abbiamo parlato nel post del blog "Servizio web come tabella di ricerca per raffinare i dati GPS". Un giorno, abbiamo elaborato un nuovo file e abbiamo riscontrato l'errore riportato di seguito, che ha causato il fallimento della mappatura:

Utilizzando le funzionalità di Altova MissionKit, in particolare quelle di MapForce e XMLSpy, siamo riusciti rapidamente a individuare il problema e a sviluppare una soluzione che potremo riutilizzare anche in futuri progetti di mappatura.

Inizialmente, abbiamo sospettato un problema con i dati di input, quindi abbiamo aperto il file con XMLSpy, dove ha superato i controlli di validità della struttura XML Validazione XML test. Fortunatamente, ogni punto dati è associato a un timestamp univoco, quindi abbiamo cercato il timestamp "23:06:22", che indicava l'ultimo set di coordinate GPS elaborato correttamente. Questo timestamp è apparso una volta alla riga 1772 del file di input.

Non c'era nulla di apparentemente errato nei dati di origine che seguivano immediatamente. Abbiamo semplicemente commentato il punto dati successivo e abbiamo salvato il file per rielaborare la mappatura

Questa volta, l'operazione di mappatura si è svolta correttamente:

Ora eravamo sospettosi dei dati restituiti dal servizio web. Anche se il servizio web è gestito dal programma nazionale di geomatica dell'U.S. Geological Survey, è possibile che il database sottostante contenesse dati non validi.

Abbiamo inserito un semplice file .csv nel sistema di mappatura come output alternativo e abbiamo associato i risultati dell'altitudine a ciascun insieme di coordinate di origine, al fine di analizzare l'output del servizio web.

Una riga nel file di output "diagnostic.csv" conteneva lo stesso valore, racchiuso tra virgolette, che era stato indicato nel messaggio di errore precedente

Si tratta di notazione scientifica! Il servizio web ha restituito un numero formattato in notazione scientifica! La funzione di precisione decimale nel nostro sistema di mappatura dei dati, che elabora il risultato del servizio web, richiede un input decimale.

Conversione dei tipi di dati

Una possibile strategia potrebbe essere quella di scrivere una funzione che riconosca il risultato del servizio web come notazione scientifica e calcoli esplicitamente il valore numerico. Il messaggio di errore di MapForce "Conversione a decimale fallita per '-1.24202767892712E-06'" suggerisce una soluzione più semplice.

Questo è un momento opportuno per riflettere sui tipi di dati. Il componente del servizio web nella nostra mappatura indica chiaramente che restituisce una stringa di testo. MapForce esegue automaticamente le conversioni di tipo da stringa a numero decimale quando una mappatura collega una stringa come input a una formula matematica. Nella maggior parte dei casi, questo libera gli sviluppatori dalla necessità di pensare a conversioni di tipo esplicite, poiché i dati si spostano tra diversi formati. Nella nostra mappatura, MapForce ha eseguito con successo la conversione da stringa a decimale 178 volte prima di incontrare l'elemento espresso in notazione scientifica.

La notazione scientifica viene normalmente utilizzata per numeri troppo grandi o troppo piccoli per essere facilmente rappresentati in forma decimale. In MapForce, il tipo di dato decimale non specifica la dimensione o il valore del numero. Invece, identifica il tipo decimale XML, una sequenza di caratteri composta da cifre con un punto come separatore decimale.

In XML, e in MapForce, il tipo di dato "double" supporta la notazione scientifica. Possiamo convertire esplicitamente i dati in notazione scientifica al tipo di dato "double" e, successivamente, arrotondare il risultato.

Questa soluzione è facile da testare utilizzando una semplice mappatura, con file di testo sia per l'input che per l'output. Abbiamo inserito una variabile semplice prima della funzione di arrotondamento e abbiamo definito il suo tipo di dato come "double". Per il nostro primo test, abbiamo utilizzato i dati ottenuti dal servizio web USGS come input, in modo da elaborare gli stessi dati senza dover ripetutamente effettuare le chiamate al servizio web. Questa mappatura ci permette anche di creare facilmente altri casi di test con nuovi dati di input.

La mappatura è stata completata con successo, generando il seguente risultato:

Creare una funzione personalizzata

Funzioni utente in MapForce sono definite in un singolo file di mappatura e possono essere aggiunte alla libreria di funzioni per essere utilizzate in altri file di mappatura, anche da più utenti. Le funzioni utente consentono inoltre di incapsulare operazioni complesse e contribuiscono a rendere il flusso di dati complessivo di un progetto di mappatura di grandi dimensioni molto più facilmente tracciabile.

Avevamo già modificato la semplice chiamata al servizio web, scegliendo il database da utilizzare in base alla longitudine, a seconda che si trattasse della parte orientale o occidentale degli Stati Uniti continentali. Ora, l'aggiunta di una definizione esplicita dei tipi di dati al risultato rende la chiamata a "getElevation" ancora più complessa. Abbiamo scelto di definire tutto all'interno di una funzione utente.

Applicazione della funzione utente

Nella sezione di codice qui sotto, abbiamo inserito la nuova funzione getElevationUS.

A questo punto, è utile ricordare perché abbiamo arrotondato l'altitudine restituita dal servizio web. Il servizio web restituisce un valore in metri, e due cifre decimali, ovvero ogni centimetro, rappresentano meno di mezzo pollice.

Avremmo potuto includere l'operazione di arrotondamento come parte della funzione getElevationUS, ma la funzione sarà più utile per le future elaborazioni dei dati se non arrotonda i dati di altitudine originali.

L'output della mappatura rivista è mostrato di seguito, utilizzando lo stesso file .gpx che ha causato il problema iniziale. Abbiamo cercato nel file di output la stringa "23:06:22", il timestamp che abbiamo utilizzato per trovare le ultime coordinate corrette prima dell'errore. Il punto che segue, a partire dalla riga 902, è quello che ha causato il malfunzionamento.

Inizialmente, siamo rimasti delusi perché tutto questo lavoro si era concluso con un'elevazione che arrotondata risultava zero. Successivamente, abbiamo geolocalizzato le coordinate sospette su una mappa di Google:

Una parte del percorso seguiva un ponte che attraversava una zona di marea. Anche se non dovessimo mai più utilizzare la funzione getElevationUS in future mappature dei dati, è molto probabile che altri file .gpx relativi ad altri viaggi conducano attraverso altre zone di marea, dove potrebbero generare valori di altitudine molto piccoli.

Se desiderate utilizzare gli strumenti presenti in Altova MissionKit per creare funzioni personalizzate per definire le proprie mappature dei dati Clicca qui per scaricare una versione di prova gratuita.