[OSM-talk] altitude information

Mike Collinson mike at ayeltd.biz
Fri Jun 1 10:54:09 BST 2007


At 10:24 PM 31/05/2007, Christoph Eckert wrote:
>> In my opinion, area data like this needs a completely different
>> storage method. Height is just one layer, in the future we may also
>> have layers for type of ground, water table level, population
>> density, you name it. This data is not suitable for
>> nodes/segments/ways but needs a completely different method of
>> storage/retreival. Probably something WMS related...
>
>I beg to differ. Cyclists want to see altitude information as a part of 
>nodes for routing. If you intend to use altitude information for 
>creating altitude lines on a map, yes, I agree. I even agree it's 
>similar to  water table level, population density etc. But the usage 
>mentioned above surely makes altitude information a part of nodes 
>describing a way.
>I even can imagine rendering streets in 3D. In this case, altitude 
>information on the nodes describing a way will make life much easier 
>for the renderers. 

I'd predict a practical outcome is to use both; primary data as grids and derived secondary data on OSM nodes for convenience:

Storing data such as topographic elevation as a regular grid of data or similar certainly makes the most sense and probably won't be stored by OSM itself ( 1) 90m data is already available via NASA, 2) Copyright on finer resolution data may make it impossible to disseminate directly).  OSM contributors will develop tools to display such data as RENDERED layers on OSM maps, such as contours being pioneered at http://www.free-map.org.uk/freemap/index.php.  

As a keen cyclist myself, I think it makes road/track elevation data more accessible to then write a simple script to interpolate from whatever is the best primary data source available at the time and add elevation to all OSM nodes for a given area as a SECONDARY source.  There are of course dangers in such redundancy - move a node taken from Landsat to a more accurate location and now the elevation is now wrong, perhaps wildly so.  But quickly and legally making data available to the folksonomy in an easy to use form and then iteratively improving quality seem so me to be what OSM is all about.

As a side note, the data has to come from somewhere.  As observed in a previous message, NASA already provides an international dataset on an approx. 90m grid and for the USA at approx. 30m (http://www2.jpl.nasa.gov/srtm/, ftp://e0srp01u.ecs.nasa.gov/srtm/version2/Documentation/SRTM_Topo.pdf).  I'd estimate that for OSM this is useful to get immediate global coverage but that around 5m would be ideal where available - any finer would be overwhelming and anyway likely to be extremely expensive.  Perhaps some OSM contributors can check if their companies have access to such data at a national level and look to see if licensing terms make some sort of derived presentation available for release to OSM??

Mike
Now in Stockholm







More information about the talk mailing list