Oczekuj nieoczekiwanego – Altova MissionKit rozwiązuje zagadkę formatów liczbowych

Za każdym razem, gdy otrzymujesz dane z zewnętrznego źródła, istnieje ryzyko, że nie dotrą one w oczekiwanej formie. Może to wymagać specjalnych rozwiązań, aby zapewnić niezawodność i stabilność systemu mapowania i transformacji danych w rzeczywistych warunkach, zwłaszcza w sytuacjach rzadkich i mało prawdopodobnych.

Przetwarzaliśmy dosłownie dziesiątki plików .gpx, z których każdy zawierał setki współrzędnych, wykorzystując narzędzie MapForce, o którym pisaliśmy w artykule na blogu Usługa internetowa jako baza danych do precyzji danych GPS. Pewnego dnia uruchomiliśmy nowy plik i napotkaliśmy poniższy błąd, który spowodował niepowodzenie procesu mapowania:

Korzystając z zestawu narzędzi Altova MissionKit, który łączy funkcje programów MapForce i XMLSpy, szybko zdiagnozowaliśmy problem i opracowaliśmy rozwiązanie, które możemy również wykorzystać w przyszłych projektach mapowania danych.

Początkowo podejrzewaliśmy problem z danymi wejściowymi, więc otworzyliśmy plik w programie XMLSpy, gdzie przeszedł on testy poprawności składni i walidacji XML. Na szczęście, każdy punkt danych posiada unikalny znacznik czasu, więc przeszukaliśmy plik w poszukiwaniu godziny 23:06:22, oznaczającej ostatni zestaw współrzędnych GPS, który został pomyślnie przetworzony. Ten znacznik czasu wystąpił raz, w linii 1772 pliku wejściowego.

W danych źródłowych, które pojawiły się bezpośrednio po tym fragmencie, nie było nic, co wskazywałoby na oczywisty błąd. Po prostu zakomentowaliśmy kolejny punkt danych i zapisaliśmy plik, aby ponownie przetworzyć mapowanie

Tym razem proces mapowania przebiegł pomyślnie:

Teraz zaczęliśmy mieć wątpliwości co do danych zwracanych przez usługę internetową. Mimo że tę usługę prowadzi Narodowy Program Geoprzestrzenny Amerykańskiego Urzędu Geologicznego, możliwe, że baza danych, na której ona opiera się, zawierała nieprawidłowe dane.

Wprowadziliśmy prosty plik .csv do konfiguracji mapowania jako alternatywne wyjście i przyporzadkowaliśmy wyniki wysokościowe dla każdego zestawu współrzędnych źródłowych, aby przeanalizować wynik działania usługi internetowej.

W jednym z wierszy pliku diagnostycznego "diagnostic.csv" znajdowała się ta sama wartość, która została podana w poprzednim komunikacie o błędzie:

To jest notacja naukowa! Usługa internetowa zwróciła liczbę sformatowaną w notacji naukowej! Funkcja zaokrąglania precyzji w naszym narzędziu mapowania danych, które przetwarza wynik usługi internetowej, wymaga wprowadzenia danych w formacie dziesiętnym.

Konwersja typów danych

Jedną z możliwych strategii jest napisanie funkcji, która rozpoznaje wynik usługi internetowej jako notację naukową i wyraźnie oblicza wartość numeryczną. Komunikat o błędzie MapForce, brzmiący „Konwersja na dziesiętną nie powiodła się dla wartości ‘-1.24202767892712E-06’”, sugeruje prostsze rozwiązanie.

To dobry moment, aby zastanowić się nad typami danych. Komponent usługi internetowej w naszej mapie wyraźnie wskazuje, że zwraca tekst. MapForce automatycznie wykonuje konwersje typów ze stringu na liczbę dziesiętną, gdy mapowanie łączy string jako dane wejściowe do wzoru matematycznego. W większości przypadków to zwalnia programistów z konieczności ręcznego określania konwersji typów, ponieważ dane przesyłane są między różnymi formatami. W naszej mapie, MapForce pomyślnie wykonał konwersję z stringu na liczbę dziesiętną 178 razy, zanim napotkał wartość wyrażoną w notacji naukowej.

Notacja naukowa jest zwykle używana dla liczb, które są zbyt duże lub zbyt małe, aby można je było wygodnie zapisać w postaci dziesiętnej. W programie MapForce, typ danych "decimal" nie określa rozmiaru ani wartości liczby. Zamiast tego, identyfikuje on typ "decimal" w XML, czyli sekwencję znaków składającą się z cyfr, z kropką jako separatorem dziesiętnym.

W formacie XML – oraz w programie MapForce – typ danych "double" obsługuje notację naukową. Możemy jawnie przekształcić dane w notacji naukowej na typ "double", a następnie zaokrąglić wynik.

To rozwiązanie jest łatwe do przetestowania za pomocą prostego odwzorowania, wykorzystującego pliki tekstowe zarówno jako dane wejściowe, jak i wyjściowe. Wprowadziliśmy prostą zmienną przed funkcją zaokrąglania i ustawiliśmy jej typ danych jako "double". W naszym pierwszym teście wykorzystaliśmy dane pobrane z serwisu internetowego USGS jako dane wejściowe, aby przetworzyć te same dane bez konieczności wielokrotnego wykonywania zapytań do serwisu internetowego. To odwzorowanie pozwala nam również łatwo tworzyć dodatkowe przypadki testowe z nowymi danymi wejściowymi.

Proces mapowania przebiegł pomyślnie, w wyniku czego uzyskano następujący wynik:

Utwórz funkcję użytkownika

Funkcje użytkownika w MapForce są definiowane w jednym pliku mapowania i mogą być dodawane do biblioteki funkcji, aby być wykorzystywane w innych plikach mapowania, nawet przez wielu użytkowników. Funkcje użytkownika również pozwalają na enkapsulację skomplikowanych operacji i ułatwiają śledzenie przepływu danych w dużych projektach mapowania.

Zmodernizowaliśmy już prosty wywołanie usługi internetowej, wybierając bazę danych dla wschodniej lub zachodniej części Stanów Zjednoczonych w zależności od długości geograficznej. Teraz, dodanie jawnego określenia typów danych do wyniku sprawia, że wywoływanie funkcji getElevation staje się jeszcze bardziej skomplikowane. Postanowiliśmy zdefiniować wszystko w funkcji użytkownika.

Wykorzystanie funkcji użytkownika

W poniższym fragmencie kodu dodaliśmy nową funkcję o nazwie getElevationUS.

W tym momencie warto przypomnieć, dlaczego początkowo zaokrąglaliśmy wartość wysokości zwróconą przez usługę internetową. Usługa internetowa zwraca wartość w metrach, a dwa miejsca po przecinku – czyli każdy centymetr – to mniej niż pół cala.

Moglibyśmy zintegrować operację zaokrąglania jako część funkcji getElevationUS, ale funkcja będzie bardziej przydatna w przyszłych operacjach mapowania danych, jeśli nie będzie zaokrąglać surowych danych wysokościowych.

Wynik poprawionej konwersji jest przedstawiony poniżej, przy użyciu tego samego pliku .gpx, który spowodował początkowy problem. Przeszukaliśmy plik wynikowy w poszukiwaniu godziny 23:06:22, czyli znacznika czasu, który wykorzystaliśmy do znalezienia ostatnich poprawnych współrzędnych przed wystąpieniem błędu. Punkt, który spowodował błąd, zaczyna się na linii 902 i jest następujący:

Początkowo byliśmy rozczarowani, ponieważ okazało się, że cały ten wysiłek doprowadził jedynie do ustalenia wysokości, która zaokrąglona wynosiła zero. Następnie zlokalizowaliśmy te podejrzane współrzędne na mapie Google:

Część trasy prowadziła mostem nad zatoką pływową. Nawet jeśli funkcja getElevationUS nie zostanie ponownie wykorzystana w przyszłych projektach mapowania danych, jest bardzo prawdopodobne, że inne pliki .gpx, dotyczące innych wycieczek, będą prowadzić przez inne zatoki pływowe, gdzie mogą generować jeszcze więcej bardzo małych wartości wysokości.

Jeśli chcieliby Państwo korzystać z tych narzędzi, proszę Altova MissionKit aby tworzyć własne funkcje, które będą służyły do mapowania danych Kliknij tutaj, aby pobrać bezpłatną wersję próbną.