grahamjones139 at gmail.com
Tue Jan 18 21:37:28 GMT 2011
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
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!
On 18 January 2011 13:32, Henry Gomersall <heng at cantab.net> 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-GB