[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