[OSM-dev] SRTM relief

[Andy Allan]

On Jan 3, 2008 9:31 AM, Martin Spott <Martin.Spott at mgras.net> wrote:
> "Andy Allan" wrote:
>
> > One of the things I haven't worked out yet is how to render
> > planet-wide contours in an efficient manner, since the shapefiles
> > mulitply either in size or number to rather large amounts (for 10m
> > contours especially) as I start including europe, never mind in the
> > US. I found there were more than 4GB of contours for the UK, which
> > made it impossible to combine the results for each SRTM->shp
> > conversion into one large shp file.
>
> Yup, at least the 'shapelib' implementation of a Shapefile
> reader/writer will likely limit you to 2 GByte filesize on 32-bit and 4
> GByte on 64-bit systems.
> If you really would like put everything into a common storage, then you
> should consider importing the resulting Shapefiles into a PostGIS
> database. If you intend to use these contours together with Mapnik
> then, as I understand, you'll have such thing already at hand.
>
> Still you will have to consider storage space 'issues', no matter if
> you're going to use a PostGIS DB or simply do a somehow "spatially
> organized" (TM  ;-)  set of Shapefiles.
> As an example: A 20 MByte compressed CGIAR ZIP file turns into a
> Shapefile of approx. 500 MByte when you render contour lines of only
> 10 m distance in elevation. This is 25x the file size. So, doing a
> rough estimation, the whole 15 GByte CGIAR SRTM would deliver you,
> well, at least over 350 GByte of contour lines at a still really coarse
> representation.
> I have no doubt that PostGIS for example will handle this for you, but
> you're still going to deal with a pretty huge amount of data when doing
> reads. You might run into major I/O performance trouble.
>
> When I was doing these tests, my final conclusion was to rely on raw
> SRTM data without any conversion whenever possible  :-)

Yeah, that's why Artem's suggestion that his rendering tool can read
compressed SRTM directly caught my attention.

Cheers,
Andy