---
title: "Erwarten Sie das Unerwartete – Altova MissionKit löst ein Problem mit Zahlenformaten"
date: "2013-01-10"
tags: 
  - "data-mapping"
  - "mapforce"
  - "missionkit"
  - "xmlspy"
description: Entdecken Sie, wie Altova MissionKit, insbesondere MapForce und XMLSpy, dabei hilft, Probleme bei der Datenzuordnung zu diagnostizieren und zu beheben, einschließlich der Verarbeitung von wissenschaftlicher Notation in GPS-Koordinaten.
---
Status: #blog

Tags:  #data-mapping #mapforce #missionkit #xmlspy

Categories: [Altova](/blog/de/category/altova.md) 
# 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](https://www.altova.com/blog/2012/06/web-service-as-look-up-table-to-refine.html)" 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:

![Fehlermeldung während der Zuordnung von Web-Service-Daten](https://lh6.ggpht.com/-8eeq0Sre-5o/UO2IztvOjdI/AAAAAAAAA6k/LhnY21vwyK8/clip_image001%25255B3%25255D.png?imgmax=800 "Error message during mapping of Web services data")

Durch die Nutzung des [Altova MissionKit](https://www.altova.com/de/missionkit.html), um Funktionen von [MapForce](https://www.altova.com/de/mapforce.html) und [XMLSpy](https://www.altova.com/de/xmlspy.html) zu kombinieren, konnten wir das Problem schnell identifizieren und eine Lösung entwickeln, die wir auch in zukünftigen Mapping-Projekten wiederverwenden können.

<!--more-->

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](https://www.altova.com/de/xmlspy/xml-validator.html) 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

![Kommentare in einer XML-Datei einfügen](https://lh3.ggpht.com/-UeqIOKWBDp8/UO2I0JP9HII/AAAAAAAAA6s/3GC5RMqRXAA/clip_image002%25255B3%25255D.png?imgmax=800 "Commenting out a portion of an XML file")

Dieses Mal verlief die Zuordnung erfolgreich:

![Altova MapForce: Nachrichtenfenster](https://lh5.ggpht.com/-K0ySupBx4ZM/UO2I1KQnttI/AAAAAAAAA60/BpfcM6B9RY0/clip_image003%25255B3%25255D.png?imgmax=800 "Altova MapForce Messages window")

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.

![Die Verwendung einer einfachen Textdatei zur Erfassung von Daten von einem Webdienst](https://lh6.ggpht.com/-KAc2wKzVjes/UO2I1myy8oI/AAAAAAAAA68/aSoxAnJ7Zh8/clip_image004%25255B3%25255D.png?imgmax=800 "Using a simple text file to capture data from a Web service")

Eine Zeile in der Ausgabedatei "diagnostic.csv" enthielt den gleichen Wert, der bereits in der vorherigen Fehlermeldung angegeben war:

![Beispielausgabe des Web-Dienstes](https://lh3.ggpht.com/-_8RAIySmcXg/UO2I2ssrbNI/AAAAAAAAA7E/qtT4BbsKONo/clip_image005%25255B3%25255D.png?imgmax=800 "Sample output from the Web service")

Es handelt sich um wissenschaftliche Notation! Der Web-Dienst hat eine Zahl im Format der [wissenschaftlichen Notation](http://en.wikipedia.org/wiki/Scientific_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 Zuweisung eines Datentyps zu einer Variablen in MapForce](https://lh5.ggpht.com/-hosv1fkHlMw/UO2I2yvIsVI/AAAAAAAAA7M/-jMNaESV_rA/clip_image006%25255B3%25255D.png?imgmax=800 "Assigning the datatype of a variable in MapForce")

Die Zuordnung wurde erfolgreich durchgeführt, und es wurde folgendes Ergebnis erzeugt:

![Beispielausgabe der modifizierten Datenzuordnung](https://lh4.ggpht.com/-4jeljPRsVcU/UO2I3iKQtZI/AAAAAAAAA7U/sH3Wn2YS05I/clip_image007%25255B3%25255D.png?imgmax=800 "Example output from the mdified data mapping")

**Erstellen Sie eine benutzerdefinierte Funktion**

[Benutzerdefinierte Funktionen](https://www.altova.com/de/mapforce/visual-function-builder.html) 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.

![Eine Benutzerfunktion in MapForce, um eine komplexe Operation zu kapseln](https://lh6.ggpht.com/-EgfsEE1molQ/UO2I4X0fxbI/AAAAAAAAA7c/lgbGUeDDmIU/clip_image008%25255B3%25255D.png?imgmax=800 "A user function in MapForce to encapsulate a complex operation")

**Die Anwendung der Benutzerfunktion**

Im folgenden Codeabschnitt haben wir die neue Funktion `getElevationUS` eingefügt.

![MapForce-Datenmapping mit einer benutzerdefinierten Funktion erweitert](https://lh5.ggpht.com/-1WM_YloAs9Q/UO2I5OcvIQI/AAAAAAAAA7k/0rKkFhfhmKY/clip_image009%25255B3%25255D.png?imgmax=800 "MapForce data mapping enhanced with a User Function") 

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.

![Beispieldaten aus einer MapForce-Datenzuordnung](https://lh5.ggpht.com/-k6NYBvSghlA/UO2I52w8KQI/AAAAAAAAA7s/0-s7KfpJdpE/clip_image010%25255B3%25255D.png?imgmax=800 "Sample data from a MapForce data mapping")

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:

![Die Bestimmung eines Punktes anhand von Breitengrad und Längengrad](https://lh6.ggpht.com/-0v5cW6dbhms/UO2I6ssKn6I/AAAAAAAAA7w/6Kq-1XDWz5Q/clip_image011%25255B3%25255D.png?imgmax=800 "Locating a point by latitude and longitude")

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**](https://www.altova.com/de/missionkit/software-development-tools.html) **um benutzerdefinierte Funktionen für Ihre eigenen Datenzuordnungen zu erstellen** [Klicken Sie hier, um eine kostenlose Testversion herunterzuladen](https://www.altova.com/de/download-trial/)**.**
