On 03/01/2008, Nick Whitelegg <[EMAIL PROTECTED]> wrote: > On Thursday 03 Jan 2008 09:31, Martin Spott 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 :-) > > The ability to read raw SRTM data would need to be built in directly to Mapnik > though. Simply overlaying maps on top of contour tiles would be of limited > use because the natural layering order is woods-contours-roads, i.e. the > contours are an intermediate layer, not the lowest layer. >
You can render the woods/parks etc as a base image, then contours as another but with transparent background and overlay the two. Then render all the rest of the stuff as another image and overlay that to get the final image which you save as a png. This is what we're doing on the cycle map to get the route overlays smoothly transparent (without the line joins showing up nastily). There might be a problem with doing this at the moment as there's a bug with rendering symbol pngs with alpha... but I'm sure that'll get fixed at some point. _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
