Henry, I didn't have any data about efficiency...but I do now. The map tiles for the canal map I just generated take up 2.4GB (down to zoom level 14). I just extracted the canal data from the database (lines, points and polygons) and as a simple text file it was less than 57MB. Gzip compression took it down to just over 17 MB. ie a factor of over 100 when compressed.
This is not really a fair comparison though because most of my 2.4GB is taken up by blank tiles (tiles with no canal features in) - these are each 116 bytes. I am sure I could do something clever with having one image and lots of symbolic links which could reduce this significantly - better than say a factor of 10, but I don't know if I would get to 100. But that said, the difference was not as big as I expected it to be - good challenge! Maybe I will write a little program to replace all the empty tiles with a symbolic link....not tonight though! Graham. On 18 January 2011 13:32, Henry Gomersall <[email protected]> wrote: > On Tue, 2011-01-18 at 13:00 +0000, Graham Jones wrote: > > I think you are describing what my examples do - for example the map > > at http://maps.webhop.net/topo uses a simple base map and the > > OpenLayers javascript program running in the web browser draws the > > selectable overlays on top of it - the overlays are PNG images with a > > transparent background. Or maybe you meant some sort of clever > > bitmap with layers defined within it? Whether it is efficient or not > > depends on what you are trying to do with the overlays - for single > > points (e.g. the power stations themselves on my map) holding bitmaps > > is much less efficient than storing the locations of each power > > station - you could have OpenLayers take the locations of the points > > and plot them. > > What you describe is exactly what I meant. > > Regarding the bitmaps being less efficient, do you have any evidence for > this? I mean, naturally there is going to be a trade off between > computation and storage, but compression of things like power station > points is going to be pretty efficient. > > It might be that a good compromise would be rasterised layers that use > only a single colour per layer (which can be stored incredibly > efficiently) with a client-side beautification and overlay step. It > would also be very simple then to change the colours of features. > > cheers, > > Henry > > -- Graham Jones Hartlepool, UK.
_______________________________________________ Talk-GB mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-gb
