Hi,
I'd like to share some ideas about an on the fly meta tiler, a thing
that could solve the issue at http://jira.codehaus.org/browse/GEOS-1076.
At the moment we disable tiling in OpenLayers output format, but it would be nice to keep it instead, and have decent labels for a change.
Now, unless we find some breakthrough idea on labeling, the only
solution up to date to make tiling and labels play together is to
meta-tile, that is, to render and cache 3x3 tiles on the same as
a seamless image, and then cut it and serve as 9 separate tiles.
That requires some server side configuration, eventual prefetching,
does not deal well with out of the blue requests (it requires the
request to conform to the pyramid that's configured server side).
What we want is just something that does better labels and does not
require any server side config.
The idea follows. First, we set up some kind of in-memory, short lived, caching. The cache hosts the tiles that we generate with the meta
tiler.
We say a request is tiled type if it contains "tiled=true" parameter and the image is 256x256 pixels size.
We get all request parameters besides request,bounds,width,height
and call them a map definition (and we use them unparsed, so
requests will have to be exactly the same).
Since we don't have an origin and a set of resolutions, we'll just
say that the origin is the location of the first requested tile,
and the resolution is the one of the first request.
Each time a request comes in, we check if it's tiled, if so, we get
the map definition and peek inside a store of cached maps, to see
if we have an entry with that definition, resolution and we check
if the map origin is compatible (that is, we have an integral number
of tiles between the requested one, and the guessed out origin).
If we find a match, we compute the row/col location of the requested
tile and see if we have it in cache, if true, we return it, if
false, we decide what meta-tile contains it, and compute it, splitting
the result and putting it inside the cache, and finally returning the
requested tile.
The tiles in the cache will be stored uncompressed, to avoid paying
the compression time for all tiles on first request (image encoding
is what kills us on simple data sets). We can eventually
have a background thread that does compress the tiles, but it's
not what we're interested in now, this cache is meant to be short lived,
I think we can first benchmark this thing a little, and then decide
wheter we really need compression or not. (oh, for the record, each full color 256x256 tile will take around 260kb, or 2.3MB for a 9x9 meta tile).
The cache will be made of soft references, so that a lack of memory situation will simply wipe it out. We could bend it afterwards to
perform compression and disk storage if we want, turning it into a full
fledged tile cache (we can think about it later, evaluating the potential for sharing with the jTileCache GSoc project).
For the moment, I'd like to put these ideas to rest for a day or so,
and gather some feedback about them before starting to implement the thing.
Let me know.
Cheers
Andrea