[webmap-discuss] OGC and google style tiling

[Paul Spencer]

Steven

On 28-Apr-06, at 7:04 AM, Steven M. Ottens wrote:

> 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.

ka-Map tries to be server agnostic I guess.  In my opinion, it is  
equivalent to ask a user of ka-Map to configure apache in a special  
way and to install php.  On the other hand, ka-Map should be  
configurable enough to take advantage of local optimizations if  
available.

>>
>> 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.

Its definitely possible.  There is a mode in ka-Map that bypasses  
tile.php to request the tile directly from the cache.  I have toyed  
with the idea of providing a 404-error-handler (apache directive)  
that would redirect the request to tile.php to generate the tile.  In  
the normal case of cached tiles (I consider the generation of the  
tile an event that happens only once so it is the special case), the  
web server would then handle returning the image with no cgi overhead  
at all.

>
>> 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.

its a little more complex unless the wmsserver can also do the  
caching.  If there is some other entity (squid?) doing the caching,  
then we run into the labeling issues discussed in the other email I  
just sent.

>>
>>>>
> <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.

its configurable, you can set it to generate whatever tile size you  
like.

Actually I was thinking about this last night.  I am now considering  
refactoring kaMap's code into the kaMap API and the kaMap tile  
server.  The use of the tile server would then be dependent on the  
type of layer that you create, allowing for the use of any tiling  
service.  Tile size could be controlled at the layer level ... there  
is nothing in the code that requires a global tile size other than  
the tile size is currently global, IIRC.

My idea for a tile server is that it can respond to a getcapabilities  
request that includes the tile size that it is willing to produce as  
well as the details necessary to construct layer objects that can  
request the tiles.


>>
>>>>
>>>> 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.

agreed.

>>>>
> <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.

If kaMap was refactored, you would be able to add layers from  
multiple sources very easily.

>
> <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>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: webmap-discuss-help at mail.osgeo.org
>

+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+