On Mon, Apr 7, 2008 at 11:05 AM, Steve Hill <[EMAIL PROTECTED]> 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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
