---
title: "Verwacht het onverwachte – Altova MissionKit lost een mysterie rondom getalformaten op"
date: "2013-01-10"
tags: 
  - "data-mapping"
  - "mapforce"
  - "missionkit"
  - "xmlspy"
description: Ontdek hoe Altova MissionKit, met name MapForce en XMLSpy, u helpt bij het diagnosticeren en oplossen van problemen met data-omzetting, inclusief het verwerken van wetenschappelijke notatie in GPS-coördinaten.
---
Status: #blog

Tags:  #data-mapping #mapforce #missionkit #xmlspy

Categories: [Altova](/blog/nl/category/altova.md) 
# Verwacht het onverwachte – Altova MissionKit lost een mysterie rondom getalformaten op

Elke keer dat u gegevens ontvangt van een externe bron, bestaat de kans dat deze niet in de vorm aankomen die u verwacht. Dit kan speciale aanpassingen vereisen, en het is zeldzaam en onwaarschijnlijk, maar het is belangrijk om een robuuste en betrouwbare oplossing voor data-integratie en -transformatie te creëren.

We hebben letterlijk tientallen .gpx-bestanden verwerkt, elk met honderden coördinaten, met behulp van de mapping-functionaliteit van MapForce, waar we in de blogpost "[Webservice als naslagtabel om GPS-gegevens te verfijnen](https://www.altova.com/blog/2012/06/web-service-as-look-up-table-to-refine.html)" over schreven. Vervolgens, op een dag, verwerkten we een nieuw bestand en kregen we de onderstaande fout, waardoor de verwerking mislukte:

![Foutmelding tijdens het verwerken van gegevens van webdiensten](https://lh6.ggpht.com/-8eeq0Sre-5o/UO2IztvOjdI/AAAAAAAAA6k/LhnY21vwyK8/clip_image001%25255B3%25255D.png?imgmax=800 "Error message during mapping of Web services data")

Door gebruik te maken van de [Altova MissionKit](https://www.altova.com/nl/missionkit.html) om de functies van [MapForce](https://www.altova.com/nl/mapforce.html) en [XMLSpy](https://www.altova.com/nl/xmlspy.html) te combineren, konden we het probleem snel identificeren en een oplossing ontwikkelen die we ook in toekomstige mappingprojecten kunnen hergebruiken.

<!--more-->

We vermoedden in eerste instantie een probleem met de invoergegevens, dus we openden het bestand in XMLSpy, waar het de tests voor correcte structuur en [XML-validatie](https://www.altova.com/nl/xmlspy/xml-validator.html) succesvol doorheen kwam. Gelukkig heeft elk datapunt een unieke tijdstempel, dus we zochten naar 23:06:22, het tijdstip van de laatste set GPS-coördinaten die correct verwerkt werden. Die tijdstempel kwam één keer voor op regel 1772 van het invoerbestand.

Er viel in de brongegevens die direct volgden niets opvallends verkeerd. We hebben simpelweg de volgende datapunkt uitgeschakeld en het bestand opgeslagen om de mapping opnieuw te verwerken:

![Een deel van een XML-bestand uitschakelen](https://lh3.ggpht.com/-UeqIOKWBDp8/UO2I0JP9HII/AAAAAAAAA6s/3GC5RMqRXAA/clip_image002%25255B3%25255D.png?imgmax=800 "Commenting out a portion of an XML file")

Deze keer is de mapping succesvol uitgevoerd:

![Altova MapForce: Venster voor berichten](https://lh5.ggpht.com/-K0ySupBx4ZM/UO2I1KQnttI/AAAAAAAAA60/BpfcM6B9RY0/clip_image003%25255B3%25255D.png?imgmax=800 "Altova MapForce Messages window")

Nu waren we argwanend over de gegevens die door de webservice werden geretourneerd. Zelfs al wordt de webservice beheerd door het National Geospatial Program van de U.S. Geological Survey, het kan zijn dat de onderliggende database ongeldige gegevens bevatte.

We hebben een eenvoudig .csv-bestand in de mapping opgenomen als een alternatieve uitvoer en de resultaten van de hoogteberekeningen voor elke set broncoördinaten toegewezen, om de output van de webservice te onderzoeken.

![Het gebruik van een eenvoudig tekstbestand om gegevens van een webdienst op te slaan](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")

In een van de regels in het uitvoerbestand "diagnostic.csv" stond dezelfde waarde als in de vorige foutmelding, maar dan tussen aanhalingstekens:

![Voorbeeld van de uitvoer van de webservice](https://lh3.ggpht.com/-_8RAIySmcXg/UO2I2ssrbNI/AAAAAAAAA7E/qtT4BbsKONo/clip_image005%25255B3%25255D.png?imgmax=800 "Sample output from the Web service")

Het is wetenschappelijke notatie! De webservice heeft een getal geretourneerd in [wetenschappelijke notatie](http://en.wikipedia.org/wiki/Scientific_notation)! De functie voor afronding in onze datamapping, die het resultaat van de webservice verwerkt, vereist decimale invoer.

**Conversie van gegevenstypen**

Een mogelijke strategie is om een functie te schrijven die het resultaat van de webservice herkent als wetenschappelijke notatie en de numerieke waarde expliciet berekent. De MapForce-foutmelding "Conversie naar **decimaal** mislukt voor '-1.24202767892712E-06'" suggereert echter een eenvoudigere oplossing.

Dit is een goed moment om na te denken over datatypes. Het web service component in onze mapping geeft duidelijk aan dat het een tekststring retourneert. MapForce voert automatisch typeconversies uit van een string naar een decimale waarde wanneer een mapping een string als invoer koppelt aan een wiskundige formule. In de meeste gevallen hoeven ontwikkelaars hierdoor niet meer expliciet na te denken over typeconversies, omdat de data tussen verschillende formaten wordt verplaatst. In onze mapping heeft MapForce succesvol 178 keer een typeconversie uitgevoerd van een string naar een decimale waarde, voordat het een waarde in wetenschappelijke notatie tegenkwam.

Wetenschappelijke notatie wordt doorgaans gebruikt voor getallen die te groot of te klein zijn om handig in decimale vorm weer te geven. In MapForce specificeert het decimale datatype niet de grootte of waarde van het getal. In plaats daarvan identificeert het het XML-decimale type, een reeks cijfers met een punt als decimale scheidingsteken.

In XML, en in MapForce, ondersteunt het datatype "double" wetenschappelijke notatie. We kunnen gegevens in wetenschappelijke notatie expliciet omzetten naar het datatype "double" en vervolgens het resultaat afronden.

Deze oplossing is eenvoudig te testen met een eenvoudige mapping, waarbij tekstbestanden worden gebruikt voor zowel de invoer als de uitvoer. We hebben een eenvoudige variabele toegevoegd vóór de functie voor afronding van decimale getallen en het datatype van deze variabele is ingesteld op "double". Voor onze eerste test hebben we de gegevens die zijn opgehaald van de USGS-webservice als invoer gebruikt, om dezelfde gegevens te verwerken zonder de webservice-aanroepen onnodig te herhalen. Deze mapping maakt het ook eenvoudig om meer testgevallen te maken met nieuwe invoergegevens.

![Het toewijzen van het gegevenstype van een variabele 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")

De mapping is succesvol uitgevoerd en heeft het volgende resultaat opgeleverd:

![Voorbeeld van de uitvoer van de aangepaste datamapping](https://lh4.ggpht.com/-4jeljPRsVcU/UO2I3iKQtZI/AAAAAAAAA7U/sH3Wn2YS05I/clip_image007%25255B3%25255D.png?imgmax=800 "Example output from the mdified data mapping")

**Maak een gebruikersfunctie**

[Gebruikersfuncties](https://www.altova.com/nl/mapforce/visual-function-builder.html) in MapForce worden gedefinieerd in één mappingbestand en kunnen worden toegevoegd aan de Functiebibliotheek voor gebruik in andere mappingbestanden, zelfs door meerdere gebruikers. Gebruikersfuncties omvatten ook complexe bewerkingen en helpen om de algehele gegevensstroom van een uitgebreid mappingproject veel beter te volgen.

We hadden de eenvoudige web service aanroep al aangepast door de database te kiezen voor het oostelijke of westelijke deel van de Verenigde Staten, afhankelijk van de lengtegraad. Het toevoegen van expliciete datatypes aan het resultaat maakt het aanroepen van `getElevation` nu nog complexer. We hebben ervoor gekozen om alles te definiëren in een gebruikersfunctie.

![Een gebruikersfunctie in MapForce om een complexe bewerking te bundelen](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")

**Het toepassen van de gebruikersfunctie**

In de onderstaande code hebben we de nieuwe functie `getElevationUS` toegevoegd.

![MapForce datamapping verbeterd met een gebruikersfunctie](https://lh5.ggpht.com/-1WM_YloAs9Q/UO2I5OcvIQI/AAAAAAAAA7k/0rKkFhfhmKY/clip_image009%25255B3%25255D.png?imgmax=800 "MapForce data mapping enhanced with a User Function") 

Op dit moment is het goed om te herinneren waarom we in de eerste plaats de hoogte die door de webservice wordt geretourneerd, hebben afgerond. De webservice geeft een waarde in meters, en twee decimalen – of elk centimeter – is minder dan een halve inch.

We hadden de afrondingsbewerking wel in de functie `getElevationUS` kunnen opnemen, maar de functie zal in de toekomst nuttiger zijn voor het verwerken van data als deze de ruwe hoogtedata niet afrondt.

De resultaten van de herziene mapping worden hieronder weergegeven, met behulp van hetzelfde .gpx-bestand dat aanvankelijk het probleem veroorzaakte. We hebben het uitvoerbestand doorzocht naar "23:06:22", de tijdstempel die we gebruikten om de laatste correcte coördinaten te vinden voordat de fout optrad. Het volgende punt, beginnend bij regel 902, is het punt dat de fout veroorzaakte.

![Voorbeeldgegevens afkomstig van een data-mapping in MapForce](https://lh5.ggpht.com/-k6NYBvSghlA/UO2I52w8KQI/AAAAAAAAA7s/0-s7KfpJdpE/clip_image010%25255B3%25255D.png?imgmax=800 "Sample data from a MapForce data mapping")

In eerste instantie waren we teleurgesteld, want al die inspanning leek te resulteren in een hoogteverschil dat afgerond 0 was. Vervolgens hebben we de verdachte coördinaten op een Google Maps kaart ingevoerd:

![Een punt bepalen aan de hand van breedte- en lengtegraad](https://lh6.ggpht.com/-0v5cW6dbhms/UO2I6ssKn6I/AAAAAAAAA7w/6Kq-1XDWz5Q/clip_image011%25255B3%25255D.png?imgmax=800 "Locating a point by latitude and longitude")

Een deel van de route volgde een brug over een getijdengeul. Zelfs als we de functie `getElevationUS` in de toekomst niet meer gebruiken voor het verwerken van data, is het zeer waarschijnlijk dat andere .gpx-bestanden voor andere tochten ons over andere getijdengeulen zullen leiden, waar ze mogelijk nog meer zeer kleine hoogtemetingen opleveren.

**Als u de tools in wilt gebruiken** [**Altova MissionKit**](https://www.altova.com/nl/missionkit/software-development-tools.html) **om gebruikersgedefinieerde functies te maken voor uw eigen datamappingen** [Klik hier om een gratis proefversie te downloaden](https://www.altova.com/nl/download-trial/)**.**
