[GIS] How to get an elevation profile for a gps track

elevationgpsgpsbabelsrtm

I'd like to get a reasonably accurate elevation profile for a track recorded with a GPS (which often has very unreliable altitude data and occasionally none at all, depending on the model.)

Does anyone have any hints on the easiest way to do this. The two techniques I am considering so far are:

Using the Google Elevation API

This API is relatively easy to use, but still requires a few steps that aren't trivial due to it's usage restrictions: max 512 samples returned per request, and the number of points along the path is limited (by URL length) as well.

I expect a gpsbabel simplify filter can be concocted to reduce the track to a suitable number of points (no point in them being closer than 100m or so together due to the resolution of the altitude data), but then the problem remains of how to map this simplified track back onto the original path, since the lengths will differ.

Or, if this isn't suitable for automation the best approach may be to let the user select the transect points on a map manually.
Downloading the Shuttle Radar Topography Mission (SRTM) data and doing the query locally.

This is something I have no experience with, so any suggestions on how feasible this is are welcome. How big is the data set? What GIS software is required, and can it be scripted in a suitable manner? I'd prefer not to have to write an sampling and interpolation algorithm, that sounds like a pain. What is the likely performance of such an approach? (I need it to be pretty quick and run on a memory-limited VPS webserver…)

Some further details to flesh out @MerseyViking's answer re downloading the data from http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp:

There are 72 x 24 tiles, each about a 20mb zip file that decompresses to a 72.1mb 16bit TIF file (6001×6001 pixels).

That's ~120 gb, which is more than I can store. Leaving it compressed and ignoring the oceans will reduce it to maybe 10gb, which is still a bit too large. Loading the data on-demand would dramatically reduce the needed storage space, but the source site is slow (I was only getting 10kb/s) making that pretty impractical.

Best Answer

For a local solution, GRASS can be scripted to do this:

# extract raster values at our points
# use cubic convolution for interpolation between DEM locations
v.drape in=my_pts out=pts_srtm_elev type=point rast=srtm_dem method=cubic

I ran an extended version of this for one of my use cases and performance of v.drape was no issue at all.

Related Solutions

PostGIS – Querying Elevation Data from DEM Files

Your elevation points are definitely regularly aligned and hence there is no need to bother about nearest neighbors. The value of the pixel in which your point fall into is always the value of the nearest neighbor.

Load all the raster in one command like this:

raster2pgsql -t 10x10 -I -C c:/temp/*.dem schema.table | psql -U postgresuser -d database

This will load all the rasters into one table, tile them as 10x10 pixel raster per row and index all those rows.

Query the raster for each point like this:

SELECT pointid, ST_Value(rast, ST_SetSRID(ST_MakePoint(x, y), 12345)) val FROM rastertable, pointtable WHERE ST_Intersects(rast, ST_SetSRID(ST_MakePoint(x, y), 12345));

ST_SetSRID() is to build your points in the same coordinate system as the rasters. Just do:

SELECT ST_SRID(rast) FROM rastertable LIMIT 1;

to know the right number of the coordinate system and replace '12345' with that number.

ST_Intersects(rast, geom) takes avantage of the indexes and make sure the query will return quite fast.

You might be very unlucky and some of your points will fall exactly on the edge of two tiles. In that case the query will return more rows than the number of points. You can deal with that by GROUPING BY pointid and compute an average of the two values or by adding DISTINCT ON (pointid) to the query to select one over the other.

[GIS] GPS Elevation height

There's not really a way to tell unless you can find some reference data to confirm what either the NAVD88 / approx MSL / height relative to geoid OR the ellipsoidal height is.

One way is to find a topographic map with elevation contours for the area to get a general idea. That would give you NAVD88 or NGVD29 elevations.

I pulled some NGS (National Geodetic Survey) control mark datasheets. There's nothing exactly at the location so I was pulling datasheets for marks that were within a few minutes away (several kilometers). Their NAVD88 elevations were around 15 - 25 m. The separation between the ellipsoid surface and the geoid/NAVD88 surface is around 23 m, which you can see in the VDATUM results.

Several searches to datasheets are available at the NGS Survey Marks and Datasheets page. I used the radial search and you'll want to look for "any vertical control." Note that the searches sometimes want postive-west longitude values and/or DMS (degrees minutes seconds) rather than decimal degree values.

GPS "elevation" should be either ellipsoidal (that's natively calculated), but many GPS devices do have access to a geoid model and can convert to elevations / gravity-related heights.

I would suggest looking through your data to see if you can match up something close to a survey mark to compare the z values.

Note: GPS height values are not as accurate as the 'horizontal' (latitude-longitude) values due to the geometry of the GPS satellite constellation. If the GPS data wasn't RTK'ed (real-time kinematic) or post-processed, it could be up to a few meters off at least.

Related Question