[OpenLayers-Dev] singleTile optimization
Paul Spencer
pspencer at dmsolutions.ca
Fri Oct 5 09:56:31 EDT 2007
On 4-Oct-07, at 10:04 PM, Stephen Woodbridge wrote:
snip ...
> OR that the single tile is always rounded up so that the off screen
> corners snap to a tile vertices, but it is centered on the appropriate
> point in the viewport.
>
> Think of it as a single tile with a buffer, but the buffer is always
> snapped to the nearest tile vertex that is off screen. This just makes
> the image somewhat more cache-able at the expense of larger images.
> and
> you could slide the image up to the buffer edge without requesting
> a new
> image.
>
> I am not suggesting that we do this, only that it is another
> interpretation of Pauls request.
>
> The other reason that people might want to run singleTile models is
> that
> they do not want the overhead of setting up a tilecache and
> managing it.
> For example, I do a lot of small low volume pages that do not need
> tiles, it would just needlessly complicate things.
Stephen,
right now, the singleTile implementation defaults to a ratio of 1.5,
which means that a singleTile draw is 1.5 times larger than the
viewport. In many cases, people use large viewports because it is
cheap with tiles. The default singleTile will then draw a tile much
larger than the loaded grid. I don't think that larger images is
actually the issue here.
Also note that if you use singleTile instead of tiles, you are using
a singleTile as the baseLayer and then there is no convenient grid to
snap to. My original contention was that this was only useful when
singleTile is not a baseLayer AND the baseLayer is not singleTile. I
suppose it would be possible to deterministically size/place the
singleTile such that it behaved more like a tiled layer but that was
not my use case.
Just to elaborate a little more, here is my use case:
1) user is able to create a dynamic overlay by searching a database
of points - could be anything but in my case it is real estate locations
2) user can specify a wide range of criteria to filter the locations
3) user can change the criteria at any time
4) user can view all available results at any available resolution
5) there can be upwards of 50,000 results to display at any one time
6) new locations are added dynamically in the back end at any time,
but they do not need to be included in the 'current' query.
7) typical coverage for a user is an entire US state
We can't conveniently tile every query, even dynamic tiling takes too
long and would have too short a useful life span (i.e. the tiles may
or may not get used again.) The number of options make it unlikely
that we could share tiles between users at any given point in time.
And dynamic tiling requires administrative stuff to clean up because
disk space is not unlimited.
Perhaps a somewhat esoteric use case ... anyways, not much of an
issue. I only originally wanted to know if folks had thought of it,
and if not, would it be a generally useful idea. I'm getting the
sense that there is some differences of opinion in how useful it will
be. Fortunately, Chris is so tied up in vector stuff that I can
probably slip the change by him ;)
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
More information about the Dev
mailing list