Tags:
, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Elevation Web Services: Limitations and Prospects

Elevation Web Services: Limitations and Prospects

Elevation data is necessary for a wide range of geospatial applications such as creating relief maps and rendering 3D visualizations, deriving the slope and aspect of a geographic area, analyzing viewshed and delineating steams in a drainage basin, and orthorectifying aerial photographs and satellite imagery. Traditionally, elevation data is scarcer and less accurate than horizontal data. There are various reasons for this. First, the horizontal location of geographic entities has always been a priority over their elevation. Second, GPS units provide poor vertical accuracy compared to horizontal accuracy. Third, volunteers of geographic information carrying those units and wandering around, in general do not care about making profiles of hills or mountains. This is why OpenStreetMap projects rely on external height data (e.g., NASA’s SRTM) although their other content is mainly created by volunteers. Nonetheless, access to accurate spot heights has lately been an urgent need in geospatial community.

In spite of proprietary elevation data generated by private or public organizations to support specific needs, a wide range of open web services that provide elevation data at regional, national, and global level are currently available. These services are implemented as REST APIs and web users can submit requests through unclean URLs to freely acquire elevation (and bathymetric) data for individual locations, profiles, as well grids nearly everywhere in Canada, the US, and the world.

Elevation services go beyond raw elevation data. Recently, Esri has launched a series of elevation services through which ArcGIS Online or Desktop users have access to various elevation layers such as slope, hillshade, aspect, viewshed, and watershed. These services exempt ArcGIS platform users from storing, compiling, and processing terabytes of data on their local machine, with multiple benefits.

As elevation data becomes more and more easily accessible through elevation web services, it is expected to support a wide range of applications, such as hiking and biking, mobile positioning, or low resolution surveying. With such a range of uses it turns critical for end-users to know how accurate the data that these APIs serve back to their requests is.

server_diagramWeb users can post a URL request to Elevation Web Services and acquire elevation data.

In the Appendix below a brief introduction to a few popular elevation web services is given. However, these REST APIs have several limitations and as a consequence their results cannot be trusted in an operational framework. First, the resolution of the source surface model (e.g., NASA’s SRTM) is usually coarse and variant in space. Even worse, in some APIs the resolution is not reported. But even when it is reported (e.g., in Google Maps and Bing Maps APIs) the interpolation method applied for the calculation of a height or depth is unknown. Second, elevation data available in data sources was mainly captured at the top of the buildings, trees, and other objects rather that at ground level. This is not convenient for most geospatial applications this data is intended to.

In the future, elevation services are expected to mitigate these limitations and expand the list of applications being supported. Open and free access to higher resolution elevation data with an extended coverage on the earth surface and ocean floor using elevation APIs will be provided. The combination of new measurements from modern technologies (e.g., TanDEM-X satellite) and open access to elevation data of fine resolution (e.g., LiDAR datasets) will make this happen. Both digital surface models and digital terrain models will be available for any place on earth, while historical data will become available to support spatio-temporal analysis of elevation data. As stated above the third dimension (elevation data) has always had a lower priority over the other two dimensions (horizontal data). Looking back at the recent rapid changes in open data for the two dimensions, there is no doubt that we are going to witness compelling evolutions in elevation services within the years to come.

Appendix: How to post a request to elevation APIs and get the height of a single spot.

Google provides Google Maps Elevation API with global coverage for both the surface of the earth and ocean floor (depth values). The elevation reported is either an elevation measurement at the precise location of the request or the averaged value of the four nearest locations. An example request for elevation of the FRDN station http://webapp.geod.nrcan.gc.ca/geod/data-donnees/station/report-rapport.php?id=M031000 with coordinates N45° 56′ 0.588428″ W66° 39′ 35.564079″ and ground height 117.928m (minus 1.50m monument height) located in Fredericton, NB https://www.google.ca/maps/place/45.93349679,-66.65987891 is:

https://maps.googleapis.com/maps/api/elevation/json?locations=45.93349679,-66.65987891&key

The result returned by Google Service in JSON format is:

{

“results” : [

{

“elevation” : 118.0129470825195,

“location” : {

“lat” : 45.93349679,

“lng” : -66.65987891

},

“resolution” : 38.17580795288086

}

],

“status” : “OK”

}

The resolution value (here 38m) indicates the maximum distance between data points from which the elevation was interpolated.

Microsoft provides an elevation API along with Bing Maps. It covers the whole earth surface and ocean floors with a minimum resolution of 900m globally (including poles), 90m for latitudes between 56oS and 60oN, and 10m for the US. An example request for the elevation of the same location is the following (a valid key is required):

http://dev.virtualearth.net/REST/v1/Elevation/List?points=45.93349679,-66.65987891&key

The result returned in JSON format (excerpt) is:

{

[…]

“resourceSets” : [

{

“elevations” : [114],

“zoomLevel” : 11

}

]

[…]

}

The zoom level ranges from 1 to 21 and gives an indication of how accurate are the results. Lower value in zoom level means less accurate results. The zoom level used depends on the amount of elevation data available in the area. The formula connecting the map resolution with the zoom level is: Map resolution = 156543.04 meters/pixel * cos(latitude) / (2 ^ zoomlevel). Map resolution ranges from 78km/pixel for zoom level = 1 to 7cm/pixel for zoom level 21 at the equator (latitude = 0). For latitude of 45o those values are 55km/pixel and 5cm/pixel, respectively. The zoom level 11 at the above example corresponds to a resolution of 53m/pixel.

GeoNames database provides three web services for elevation data and specifies clearly the corresponding data sources. The first is GTOPO30 that uses USGS Gtopo30 digital elevation model for the earth surface (ocean floors are not represented) with a horizontal grid spacing of 30 arc seconds (approx. 1km). The second is SRTM3 that uses NASA’s SRTM elevation data for the earth surface between 56oS and 60oN (ocean floors are not represented) with a horizontal grid spacing of 3 arc seconds (approx. 90m). The third is ASTERGDEM that uses NASA’s ASTER elevation data for the earth surface between 83oS and 83oN (ocean floors are not represented) with a horizontal grid spacing of 1 arc second (approx. 30m). Example requests for the elevation of the same location are the following:

http://api.geonames.org/gtopo30JSON?lat=45.93349679&lng=-66.65987891&username=demo

http://api.geonames.org/srtm3JSON?lat=45.93349679&lng=-66.65987891&username=demo

http://api.geonames.org/astergdemJSON?lat=45.93349679&lng=-66.65987891&username=demo

The results of the above three requests in JSON format are respectively:

{“gtopo30″:98,”lng”:-66.65987891,”lat”:45.93349679}

{“srtm3″:113,”lng”:-66.65987891,”lat”:45.93349679}

{“astergdem”:102,”lng”:-66.65987891,”lat”:45.93349679}

MapQuest provides an open elevation service by serving NASA’s SRTM elevation data. The coverage is limited to the earth surface bounded by latitudes 56oS and 60oN. No depth data is provided through this service. An example request for the elevation of the same location is the following (a valid key is required):

http://open.mapquestapi.com/elevation/v1/profile?key&latLngCollection=45.93349679,-66.65987891

The result of the request in JSON format is:

{

“shapePoints” : [45.933497,-66.659879],

“elevationProfile” : [ {“distance”:0,”height”:113} ],

[…]

}

Natural Resources Canada provides two services for elevation data. The first service is the Canadian Digital Elevation Model (CDEM) that provides both elevation data as extracted from the National Topographic Data Base (NTDB) at the scale 1:50,000 and various other sources, such as provincial and territorial datasets, remote sensed imagery, etc. The second service is the Canadian Digital Surface Model (CDSM), a 0.75 arc second (approx. 20m) grid derived from NASA’s SRTM digital surface model. Example requests for the elevation of the same location are the following:

http://geogratis.gc.ca/services/elevation/cdem/altitude?lat=45.93349679&lon=-66.65987891

http://geogratis.gc.ca/services/elevation/cdsm/altitude?lat=45.93349679&lon=-66.65987891

The results of the above two requests in GML format are respectively:

<elevation>

<altitude>118.0</altitude>

<vertex>true</vertex>

<gml:Point xmlns:gml=”http://www.opengis.net/gml”>

<gml:coordinates>-66.65987891,45.93349679</gml:coordinates>

</gml:Point>

</elevation>

<elevation>

<altitude>113.717<altitude>

<vertex>true</vertex>

<gml:Point xmlns:gml=”http://www.opengis.net/gml”>

<gml:coordinates>-66.65987891,45.93349679</gml:coordinates>

</gml:Point>

</elevation>

Further Reading

GeoNames (visited 10.2015) GeoNames Web Services Documentation. http://www.geonames.org/export/web-services.html

Google (visited 10.2015) Google Maps Elevation API. https://developers.google.com/maps/documentation/elevation/intro

MapQuest (visited 10.2015) Open Elevation Service Developer’s Guide. MapQuest Developer. http://open.mapquestapi.com/elevation/

Microsoft (visited 10.2015) Elevations API – Bing.

https://msdn.microsoft.com/en-us/library/jj158959.aspx

Nagi, R. (2014) Introducing Esri’s World Elevation Services. ArcGIS Resources.

http://blogs.esri.com/esri/arcgis/2014/07/11/introducing-esris-world-elevation-services/

NRCan (visited 10.2015) Elevation API. Natural Resources Canada. http://geogratis.gc.ca/site/eng/elevation

NRCan (visited 10.2015) FRDN Station Report. Geodetic Reference Systems http://webapp.geod.nrcan.gc.ca/geod/data-donnees/station/report-rapport.php?id=M031000

NOAA (visited 10.2015) United States Interagency Elevation Inventory. http://coast.noaa.gov/inventory/

OSM (visited 10.2015) Relief maps. OpenStreetMap Wiki. http://wiki.openstreetmap.org/wiki/Relief_maps

VTP (2011) Global Elevation Data. Virtual Terrain Project. http://vterrain.org/Elevation/global.html

One comment on "Elevation Web Services: Limitations and Prospects"

  1. Camilo says:

    This is a very nice review about these services. Its a nice coincidence that I was just looking for elevations services right now. I think the only precise solution for getting hi accuracy elevations its Pleiades 1m and Lidar.
    Hope to see evolution on this area, we are elaborating 3D GIS more and more.

Comments are closed.

Related Articles

One of the Best Geomatics events in Canada: GeoAlberta 2017

I had a chance to attend the 2017 GeoAlberta conference earlier this month in Calgary, Alberta. This was my first…

My COGS GIS Education, Part II

In my first article, I introduced the how and why I chose to attend COGS from the fall of 2014…

Outil de versionnement des données géographiques à code source ouvert pour des environnements multi-contributeurs (partie 1)

Note des éditeurs : Cet article a été écrit conjointement par Nicolas Gignac, Dami Sonoiki (eHealth Africa) et Samuel Aiyeoribe (eHealth Africa). Ces auteurs…