Erwarten Sie das Unerwartete – Altova MissionKit löst ein Problem mit Zahlenformaten

Jedes Mal, wenn Sie Daten von einer externen Quelle empfangen, besteht die Möglichkeit, dass diese nicht in der erwarteten Form ankommen. Dies kann spezielle Anpassungen erfordern, um eine robuste und zuverlässige Lösung für die Verarbeitung und Umwandlung von Daten in realen Anwendungen zu gewährleisten, insbesondere angesichts der Seltenheit solcher Fälle.

Wir haben buchstäblich Dutzende von .gpx-Dateien verarbeitet, die jeweils Hunderte von Koordinaten enthielten, mithilfe der Mapping-Funktion von MapForce, über die wir in dem Blogbeitrag "Web-Dienst als Nachschlagetabelle zur Verfeinerung von GPS-Daten" geschrieben haben. Eines Tages verarbeiteten wir eine neue Datei und stießen auf den unten beschriebenen Fehler, der dazu führte, dass das Mapping fehlschlug:

Durch die Nutzung des Altova MissionKit, um Funktionen von MapForce und XMLSpy zu kombinieren, konnten wir das Problem schnell identifizieren und eine Lösung entwickeln, die wir auch in zukünftigen Mapping-Projekten wiederverwenden können.

Zunächst vermuteten wir ein Problem mit den Eingabedaten. Wir öffneten die Datei in XMLSpy, wo sie die Tests zur korrekten Struktur und die XML-Validierung erfolgreich bestand. Glücklicherweise hat jeder Datenpunkt einen eindeutigen Zeitstempel, sodass wir nach dem Zeitstempel 23:06:22 suchten, der die letzte erfolgreiche Verarbeitung von GPS-Koordinaten markierte. Dieser Zeitstempel trat einmal in Zeile 1772 der Eingabedatei auf.

In den ursprünglichen Daten, die unmittelbar folgten, war nichts offensichtlich falsch. Wir haben einfach den nächsten Datenpunkt auskommentiert und die Datei gespeichert, um die Zuordnung erneut zu verarbeiten

Dieses Mal verlief die Zuordnung erfolgreich:

Wir waren nun misstrauisch gegenüber den Daten, die der Webdienst lieferte. Obwohl der U.S. Geological Survey mit seinem National Geospatial Program den Webdienst betreibt, könnte es sein, dass die zugrunde liegende Datenbank ungültige Daten enthielt.

Wir haben eine einfache .csv-Datei als alternative Ausgabe in die Zuordnung eingefügt und die Höhenergebnisse für jede Gruppe von Quellkoordinaten zugeordnet, um die Ausgabe des Webdienstes zu überprüfen.

Eine Zeile in der Ausgabedatei "diagnostic.csv" enthielt den gleichen Wert, der bereits in der vorherigen Fehlermeldung angegeben war:

Es handelt sich um wissenschaftliche Notation! Der Web-Dienst hat eine Zahl im Format der wissenschaftlichen Notation zurückgegeben! Die Funktion zur Rundung und Präzisionsanpassung in unserer Datenzuordnung, die das Ergebnis des Web-Dienstes verarbeitet, benötigt eine Dezimalzahl als Eingabe.

Datentyp-Konvertierung

Eine mögliche Strategie wäre, eine Funktion zu schreiben, die das Ergebnis des Web-Dienstes als wissenschaftliche Notation erkennt und den numerischen Wert explizit berechnet. Die MapForce-Fehlermeldung „Konvertierung zu Dezimalzahl fehlgeschlagen für '-1.24202767892712E-06'“ deutet jedoch auf eine einfachere Lösung hin.

Dies ist ein guter Zeitpunkt, um über Datentypen nachzudenken. Die Web-Service-Komponente in unserer Mapping-Definition zeigt deutlich, dass sie einen Textstring zurückgibt. MapForce führt automatisch Typkonvertierungen von String zu Dezimalzahl durch, wenn eine Mapping-Definition einen String als Eingabe für eine mathematische Formel verwendet. In den meisten Fällen entlastet dies die Entwickler von der Notwendigkeit, explizite Typkonvertierungen durchzuführen, da Daten zwischen verschiedenen Formaten übertragen werden. In unserer Mapping-Definition hat MapForce erfolgreich 178 Mal eine Typkonvertierung von einem String zu einer Dezimalzahl durchgeführt, bevor es auf den Eintrag in wissenschaftlicher Notation stieß.

Die wissenschaftliche Notation wird normalerweise für Zahlen verwendet, die entweder zu groß oder zu klein sind, um in einer übersichtlichen Dezimalform dargestellt zu werden. In MapForce gibt der Datentyp "Dezimal" weder die Größe noch den Wert der Zahl an. Stattdessen identifiziert er den XML-Datentyp "Dezimal", der eine Zeichenfolge aus Ziffern mit einem Punkt als Dezimaltrennzeichen ist.

In XML – und in MapForce – unterstützt der Datentyp "double" wissenschaftliche Notation. Wir können Daten in wissenschaftlicher Notation explizit in den Datentyp "double" umwandeln und anschließend das Ergebnis runden.

Diese Lösung lässt sich einfach in einer einfachen Zuordnung testen, wobei sowohl für die Eingabe als auch für die Ausgabe Textdateien verwendet werden. Wir haben eine einfache Variable vor der Funktion zur Rundung eingefügt und ihr Datentyp als "double" zugewiesen. Für unseren ersten Test haben wir die Daten verwendet, die vom USGS-Webdienst erfasst wurden, als Eingabe, um die gleichen Daten zu verarbeiten, ohne die Webdienstaufrufe unnötig zu wiederholen. Diese Zuordnung ermöglicht es uns auch, problemlos weitere Testfälle mit neuen Eingabedaten zu erstellen.

Die Zuordnung wurde erfolgreich durchgeführt, und es wurde folgendes Ergebnis erzeugt:

Erstellen Sie eine benutzerdefinierte Funktion

Benutzerdefinierte Funktionen in MapForce werden in einer einzigen Mapping-Datei definiert und können der Funktionsbibliothek hinzugefügt werden, um in anderen Mapping-Dateien verwendet zu werden, auch von mehreren Benutzern. Benutzerdefinierte Funktionen kapseln auch komplexe Operationen und tragen dazu bei, den gesamten Datenfluss eines umfangreichen Mapping-Projekts besser nachvollziehbar zu machen.

Wir hatten den einfachen Web-Service-Aufruf bereits modifiziert, indem wir die Datenbank basierend auf der geografischen Länge für den östlichen oder westlichen Teil der Vereinigten Staaten ausgewählt haben. Durch die explizite Definition der Datentypen für das Ergebnis wird der Aufruf von "getElevation" noch komplexer. Wir haben uns entschieden, alles in einer benutzerdefinierten Funktion zu definieren.

Die Anwendung der Benutzerfunktion

Im folgenden Codeabschnitt haben wir die neue Funktion getElevationUS eingefügt.

Zu diesem Zeitpunkt ist es gut, sich daran zu erinnern, warum wir ursprünglich die von der Web-Dienstleistung zurückgegebene Höhenangabe gerundet haben. Die Web-Dienstleistung gibt einen Wert in Metern an, und zwei Dezimalstellen – also jeder Zentimeter – sind weniger als eine halbe Zoll.

Wir hätten die Rundungsoperation in die Funktion getElevationUS integrieren können, aber die Funktion wird in Zukunft bei der Verarbeitung von Daten wahrscheinlich nützlicher sein, wenn sie die Rohdaten zur Höhenangabe nicht rundet.

Die Ausgabe der überarbeiteten Verarbeitung wird im Folgenden dargestellt, wobei die gleiche .gpx-Datei verwendet wird, die ursprünglich das Problem verursacht hat. Wir haben die Ausgabedatei nach dem Zeitstempel 23:06:22 durchsucht, den wir verwendet haben, um die letzten korrekten Koordinaten vor dem Fehler zu finden. Der folgende Punkt, beginnend in Zeile 902, ist der, der den Fehler verursacht hat.

Zunächst waren wir enttäuscht, denn all diese Mühe führte letztendlich nur zu einer Höhenangabe, die auf 0 gerundet wurde. Dann haben wir die verdächtigen Koordinaten auf einer Google-Karte eingezeichnet:

Ein Teil der Strecke verlief über eine Brücke, die eine Gezeiteneinbuchtung überspannte. Selbst wenn wir die Funktion getElevationUS in Zukunft nicht mehr für die Datenverarbeitung verwenden, ist es sehr wahrscheinlich, dass andere .gpx-Dateien für andere Reisen über andere Gezeiteneinbuchtungen führen, wo sie möglicherweise noch kleinere Höhenwerte liefern.

Wenn Sie die Werkzeuge in... verwenden möchten, Altova MissionKit um benutzerdefinierte Funktionen für Ihre eigenen Datenzuordnungen zu erstellen Klicken Sie hier, um eine kostenlose Testversion herunterzuladen.