Web Service as a Look-Up Table to Refine GPS Data

Elevation data recorded by GPS devices is notoriously inaccurate, especially in hilly terrain like the Russian River Valley example from our earlier post.

The final elevation track plotted from the Russian River Valley GPX file is suspicious for several reasons. First, the graph shows we descended almost 50 feet below sea level. That’s hard to believe, since we were travelling along the bank of the river, only about 10 miles from the Pacific Ocean.

Secondly, we were headed mostly west, following the river downstream, but the track shows a predominantly uphill trend.

We can evaluate the recorded GPS elevation data by comparing it to information available from the United States Geological Survey (USGS). The USGS operates a Web service that accepts latitude and longitude coordinates, and returns elevation data measured by NASA and assessed for accuracy based on over 13,000 control points in the continental United States.

Using the elevation Web service in an Altova MapForce mapping will let us extract each point from the GPX file, send the coordinates to the USGS Web service, and build a new GPX file with corrected elevation data.

This solution matches the Web service as a Look-Up Table pattern described in the Data Mapping Patterns blog post. Each set of coordinates identified by latitude and longitude has exactly one corresponding elevation value. Just like a local look-up table, the source data points are unique, but the output values may be duplicated.

We can start to get familiar with the USGS Web service by opening the WSDL in XMLSpy. This is especially useful for reading embedded documentation.

XMLSpy can also generate a SOAP request for the Web service, allowing easy identification and testing of the needed parameters.

For the first test, we used the coordinates where the elevation reported was below sea level. The Source_Layer element specifies which map set to query for the result. We selected a map that covers the western half of the United States from the list at http://gisdata.usgs.gov/XMLWebServices2/Elevation_Service_Methods.php

XMLSpy can send the request to the Web service provider and automatically open the result.

Where the GPS recorded 12 meters below sea level, the USGS reports the actual elevation was more than 33 meters above sea level.

We could have requested the elevation in feet, but chose not to do that because the GPX schema defines the elevation value in meters. We intend to apply the StyleVision style sheet for localization on the final data anyway.

Data Mapping with a Web Service

Sometimes it’s useful to create a small, simplified MapForce mapping to test the Web service before sending it a large data set. The screenshot below shows a simple mapping for the getElevation Web service with string constants providing parameters and a text file for output.

Clicking the MapForce Output button executes the mapping with the supplied parameters. Here is the result:

We’ll start the production version of the MapForce mapping with two copies of the GPX schema, and connect all the elements from the source to the destination except elevation.

Next, we simply copy the Web service definition with its parameters from the test mapping to the production version and connect X_Value and Y_Value in the Web service to longitude and latitude in the source GPX file.

On the output side of the Web service, we simply connect the result to the elevation element of the output component. (We rounded the elevation in meters to two decimal places because 13 feels like overkill – we are not measuring the rise and fall of tectonic plates here!)

When we execute the new version of the mapping, the coordinates from each <trkpt> are supplied to the Web service, and the reported elevation value is plugged into <ele> on the output side.

We can compare the converted GPX file with new elevation data to the original file using Altova DiffDog. The differences are clearly highlighted in Grid View. A few irrelevant trailing zeroes were also dropped from the latitude and longitude values during the transformation.

We can also graph the converted file using the StyleVision SPS style sheet with localization features.

As you would expect when following a river downstream, the track does not go below sea level and the overall trend is downhill!

Elevation data recorded by GPS devices is inherently less accurate than x-y coordinates. Additionally, as you are moving, hills and other obstacles can block line of sight to one or more GPS satellites and their radio signals are lost.

The map below illustrates a segment of the Russian River Valley trip. The red dot marks a spot where the GPS recorded -12.8 meters elevation, but the USGS reported +33.28 meters. Wild Hog Hill directly to the west rises over 1,100 feet, obstructing large sections of sky and very likely blocking GPS satellite signals.

As one last point of interest, we converted the elevation data from the New Hampshire hike GPX file and used XMLSpy to graph the USGS elevation in green as an overlay on the original GPS elevation track.

It’s not hard to tell which shape more accurately depicts an old eroded New England mountainside.

If you would like use the tools in the Altova MissionKit to create your own data mapping with a Web service as a look-up table, click here to download a free trial.