[OSM-dev] Altitude data & (cycle) route profiles

Sjors Provoost sjors at sprovoost.nl
Mon Apr 7 14:30:32 BST 2008


On Mon, Apr 7, 2008 at 11:05 AM, Steve Hill <steve at nexusuk.org> wrote:
> On Sun, 6 Apr 2008, Sjors Provoost wrote:
>
>
> > 1 - import SRTM data for (part of) Australia
> > 2 - write several algorithms to estimate the height of any given
> > coordinate (server side), using original STRM grid
> > 3 - display (on the fly) an altitude profile given a route (a sequence
> > of nodes). Drawing done server side.
> > 5 - integrate with the main website (on a dev server)
> >
>
>  This sounds good to me.  I'd also suggest considering implementing an API
> for clients to get at the SRTM altitude data.

Ok, I will include that.

> > For method 1 I will write a ruby script that imports the SRTM data and
> > will use the source code of SRTM for inspiration.
> >
>
>  Where are you going to import it to?  Consider using PostGIS since this
> will allow spacial referencing of the data (but you may need to experi

PostGIS sounds good indeed. I am used to working with MySQL but its
spatial extensions are not that complete. For this project I can try
PostgreSQL with PostGIS.

>  I posted some estimated figures for storing the entire SRTM3 data set as
> 10m contours in PostGIS a while ago - about half a terabyte.  I think your
> best option is to stick with the raw grid and write a system to generate
> parametric curves of elevation for arbitrary vectors across it on-the-fly.

Agree.

> > That separate server can use a stripped
> > down version of the OSM database to improve its performance.
> >
>
>  This server doesn't really need the OSM database at all - instead of
> sending a list of node IDs to the server, you can just send it a list of
> lat/lon tuples.

That would make it easier and faster indeed. It can also send any
existing altitude tags along with it, so the profile renderer can
choose between these tags and the SRTM3 data.

Sjors




More information about the dev mailing list