[webmap-discuss] OGC and google style tiling

[Steven M. Ottens]

Paul,

On Thu, 2006-04-27 at 16:08 -0400, Paul Spencer wrote:
> Steven,
> 
> (sorry folks, this is getting longer and longer)
indeed, interesting stuff though IMHO

<snip>
> 
> how are you doing the serverside cache on mapserv requests?

We have mod_cache on apache configured to cache all .cgi requests. It
stores the files on disk. The problem is that only the first map image
and some of the gazetteer-generated images are used more than once. So
starting up the application is fast, but if students start to pan en
zoom, all the images are rendered by mapserver in stead of delivered
from cache.
> 
> In the ka-Map case, tile.php only loads mapscript and gd if the tile  
> has not been previously generated.  Tiles are genereated the first  
> time they are requested and subsequently stored on disk and returned  
> directly by tile.php if they already exists
> 
This is more or less the same as our setup. I am wondering though if
using a dedicated cache like mod_cache or squid wouldn't be faster than
letting tile.php figure out if it is cached or not. The suggestion by
Steve Woodbridge to use mod_rewrite to first search disk than run
tile.php is an interesting one in this matter.

> GD is required because we generate 'metatiles', typically 25-36 tiles  
> constituting a large map image (1000-2000 pixels square), in a single  
> map draw and slice it up into smaller tiles using GD after.  The  
> large map draw minimizes the number of times we need to actually load  
> mapscript and render data, and also minimizes the effect of the label/ 
> symbol/rendering issues.

Ah of course. From what I've seen so far the tiling issue is not a pure
client side issue. The WMS server needs to be enhanced to do exactly
what tile.php is doing: split up one request in multiple tiles. 
> 
> >>
<snip>

> ka-Map uses a tile size of 200x200 in its default, but I have started  
> switching to 300x300.   In either case, the tile size minimizes the  
> number of actual images that are loaded (which impacts browser  
> performance when dragging the map) while keeping the download size  
> reasonable for each tile and providing a buffer of tiles 'offscreen'  
> so that users should rarely see empty tiles menu panning.
> 
> -- By comparison, google uses 256x256 (they used 128x128 for a while  
> then changed)
> 
Just curious: why not use google's tile size? It might make it easier in
the future to combine google layers with ka-map layers.
> 
> >>
> >> 3) mapserv has rendering issues that are difficult to detect when
> >> rendering a single image, but when you render tiles, they become very
> >> obvious.  The worst is thick lines rendered with a 'circle' symbol,
> >> the ends of the line (at the map draw boundary) are tailed off ...
> >> when two tiles come together, there is a very noticeable 'shearing'
> >> effect on the lines which looks very bad.
> > bad, bad, mapserver ;) I noticed the glitches after careful  
> > inspection.
> > So either our data is not sensitive to this error or you have  
> > better eyes ;)
> 
> It is most noticeable when rendering thick lines 10+ pixels wide.  I  
> had never noticed it before I started doing the tiling.  When I first  
> saw it, I actually though the that tiles were mis-aligned by a few  
> pixels :)  I spent quite a bit of time playing with my code before I  
> figured out I was right and mapserver was wrong ...
> 
Is the bug in mapserver solvable and is there anyone looking into it.
Obviously you and I need a solution right now, and your tile.php is a
nice workaround. But in the long run it is a bug in mapserver and if
possible should be solved. (but this is a whole other issue probably).
If we presume that the rendering bug is fixed on the WMS server used,
the above argument is not valid anymore. So we can skip it in a broader
point of view.
> >>
<snip>

> I didn't want ka-Map to be tied to ogc since not that many folks  
> outside our community care about ogc.

One of the arguments we used to get FOSS in the project was 'better
support for standards'. So we're obliged to at least try and stick to
the standards. Also we would like the users to be able to add external
datasources. But maybe we can solve this by using a special tiling layer
for our own data and standard WMS for external data.

<snip>
<snip explanation of the working of kamap>

Thanks for the explanation, that'll help with figuring out how to
combine mapbuilder and kamap.

> If we removed the requirement for calling init.php then you would  
> have no server-side dependency at all.
> 
> I just checked how it works and calling initialize is actually not  
> done in the constructor for kaMap so it should be possible to do this  
> already.  I've attached an html file which uses kaMap to render a wms  
> layer with no server side interaction at all.  You will need to  update
>  kaMap to the latest cvs version because wmsLayer was slightly  out of
>  date with a change I made to the _layer constructor.  


I'll try it monday at work. 
<snip>

>  I believe that a tiling extension to the spec is in the works?
>  Until WMS servers catch up, I'll stick with what we've got :) 

I can understand that, but your knowledge on tiling is rather extensive
and it would make sense if you bug the tiling-spec people every now and
then ;)

Thanks a lot for the info,

Steven


<snap>