Christopher Schmidt wrote: > On Thu, Oct 04, 2007 at 11:09:34AM -0500, Erik Uzureau wrote: >> There we go. What David's said here is what I was grasping for earlier here. >> >> If you use a singleTile layer that is gridded, *eventully* the user is >> going to pan the map such that the corners of the grid are in the >> viewbox. At that point, the only option is to load 4 tiles, at which >> point, we're back to gridded, in which case you might as well just use >> a normal gridded layer with a very big tilesize and a buffer:0 > > I think Paul is imagining a singleTile which matches the grid of a > *smaller* set of tiles -- so the gridded tile is 'snapped' to a corner > of a smaller grid. For example, you could imagine the grid existing at > 0.5 degree increments all the way across the world, and the tile would > snap to the closest one. The tile no longer has equal buffer space on all > outside edges, but is more cachable. > > The size of a single grid square must be smaller than the smallest area > that can outside the map at any given time, so when the new area is > requested, the tile 'jumps' to fill it, but positions itself based on > the grid instead of based on the map center. > > Regards,
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. -Steve _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
