[mapguide-internals] RFC required for tile caching changes?

[Jason Birch]

I think that using large blocks may also prevent you from optimising the
user experience in the future by requesting from multiple servers.  

For instance, if there are 16 tiles in the user's current view, you
quickly hit the browser's settings for maximum connections per server.
If you are able to split this up between four tile servers (through some
kind of mod-based round robin?) the user experience is going to be
greatly improved.

I believe that this is really only feasible when storing the tiles in
user-requested sizes.

Jason
 

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul
Spencer
Sent: Sunday, January 14, 2007 10:59
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC required for tile caching changes?

FWIW, Traian's suggestion for naming folders based on a mod of r/c is
essentially the same approach I took with ka-Map (for the same reason
that Chris brought this up) and it seems to work very well.  In ka- Map,
tiles are rendered in blocks of about 2000x2000 pixels (tile size is
configurable but you might get 10 x 10 tiles in a typical
configuration) and they would go in one of these sub-directories.  I
think I figured out that this would be enough directories to decently
cache a pretty large area (say, all of the US) without running into file
system limits for most scales.

It would be interesting to know the limits on:

* files per directory
* directories per directory
* total number of directories
* total number of files
* minimum block(?) size in the file system compared to typical size of a
tile (wasted space per tile).

for various operating systems/file system combinations.  I know we use
ReiserFS because it handles lots of small files better than ext3 for
instance.  Knowing some of this might help make the caching system more
tunable in different environments.

Paul

On 13-Jan-07, at 11:09 AM, Traian Stanev wrote:

> Can you also give an example for tiles with negative indices?
> For example if in the current scheme the tile is -33, -64, what would 
> be the resulting directory path?
>
> R-2/C-3/-3_-4
>
> What about tile -1,-1
>
> Another suggestion I have -- name the folder part of the path (30 * 
> tile index div 30) and then the file part would be (tile index mod 
> 30).
>
> So for tile 33,64 the folder would be:
>
> Base Layer Group/30/60/3_4.png
>
> And for tile -33,-64 the folder would be:
>
> Base Layer Group/-30/-60/-3_-4.png
>
> For tile 1,1, the folder would be:
>
> Base Layer Group/0/0/1_1.png
>
> For tile -1,-1 the folder would be:
>
> Base Layer Group/-0/-0/-1_-1.png
>
>
> It's a little weird around 0, but it allows for arbitrary groupings of

> tiles in folders (they don't have to be 30x30) since the tile index 
> can be computed directly from the file path, by adding the folder term

> to the file path term.
>
> Also, can you tell us what the problem is with having too many images 
> in one directory? Is it a file system issue? And how many tiles is the

> limit, i.e. why is 30x30 the preferred grouping and not 1000x1000 for 
> example?
>
> Traian
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org on behalf of Jason 
> Birch
> Sent: Fri 1/12/2007 8:57 PM
> To: MapGuide Internals Mail List
> Cc:
> Subject: RE: [mapguide-internals] RFC required for tile caching 
> changes?
>
> Can I forward this to the "tiling" list for comment?
>
>
> From: mapguide-internals-bounces at lists.osgeo.org on behalf of Chris 
> Claydon
> Sent: Fri 2007-01-12 12:24 PM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] RFC required for tile caching 
> changes?
>
> A sample tile location would be as follows:
>
>
> ......\ Repositories\TileCache\Samples_Sheboygan_Maps_Sheboygan\7\Base
> Layer Group\R2\C3\3_4.png
>
>
> The R and C indices correspond to rows and columns where each row  
> contains 30 tiles vertically and each column contains 30 tiles  
> horizontally.
>
>
> This indicates that:
>
>
> 1)       We're at zoom level 7
>
> 2)       We're in grouped row 2
>
> 3)       We're in grouped column 3
>
> 4)       The tile location within this grouped row/column  
> combination is (3,4).
>
>
> The R and C indices never take a zero value (to avoid issues with  
> negative values around the origin), so this tile corresponds to a  
> location of (33, 64) in the old scheme.
>
>
> I took a quick look at the Tile Map Service Specification, but it  
> doesn't appear to support the concept of grouping blocks of tiles  
> into subfolders in its current form. Can you provide more  
> information on whether this is possible?
>
>
> Chris.
>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+




_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals