[ka-Map-dev] purpose of tile.php

[Lorenzo Becchi]

Hi Tim,
with Andrea we are working on the idea to do a system to let the client 
change only affected tile in a query related layer.
We are doing this on the Object Overlay system that we are developing 
but it's far to be completed.
It seem to me that this idea is useful only when you are doing 
something on the fly like a WMS call or an Object overlay system 
related to a query system. I  don't see convenience in doing it from 
mapfile (please, tell me if I'm wrong).
  I suggest you to work on pesonalized tile.php file as Paul did with 
wms and we are doing with overlays.
no better suggestions at the moment...

cheers
Lorenzo





Il giorno 27/feb/06, alle 19:01, Tim Schaub ha scritto:

> I'm interested to get some feedback on this.  I can imagine three 
> broad categories of use cases that determine how tile.php should be 
> used.  I'm making changes to my ka-Map to handle these three cases.  
> I'd be happy to contribute if people agreed that it would be of 
> general use.  If anybody can see another case that is not treated 
> here, or if there is a problem with the way I've suggested handling 
> these, please let me know.
>
> Use cases:
>
> 1) Static Data/Infrequent Updates - file or database data that is 
> updated infrequently
>
> Here tile.php is used only in pre-rendering the cache.  Client side 
> scripts could be modified so that pre-rendered tiles are accessed 
> directly (if cache is web-accessible) - bypassing tile.php.  Whenever 
> mapfile or data changes, cache is flushed and regenerated.
>
>
> 2) Static Data/Frequent Updates - file or database data that is 
> updated frequently
>
> Here tile.php is called all the time.  A version number could be used 
> to determine when tiles should be re-rendered.
>
>
> 3) Dynamic Data - data derived from queries generated by the client
>
> When the client generates a query (SELECT fields FROM table WHERE date 
> > somedate - for example) tile.php could be used to do mapfile 
> variable substitution.  In this way, if someone wants to customize 
> their client interface to have some forms that generate queries, they 
> don't have to customize the ka-Map core.  This can all be handled by 
> placing %variables% in the mapfile and sending those variables to 
> tile.php.
>
>
> The client side scripts could be modified to determine when to use 
> tile.php based on layer metadata.  A tag like "TILE_SOURCE" for 
> example could have three possible values:
>
> 1) <CACHE_URL> - path to web accessible cache.  This corresponds to 
> use case #1.  Image is requested  by client directly, without going 
> through tile.php.
>
> 2) "AUTO" - default value.  Tile.php decides whether or not to render 
> a tile.  This is how things currently work.  This would correspond 
> with use case #2 if a version number were appended to the query to 
> determine when to update an existing tile (bug 1041).
>
> 3) "FORCE_REDRAW" - always render new tile.  With variable 
> substitution added to tile.php, this would handle use case #3.  
> Suggested patches in bug 1290 and 1303.
>
>
> Thanks for any feedback,
> Tim
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.1.0/269 - Release Date: 
> 2/24/2006
>
>
> _______________________________________________
> ka-Map-dev mailing list
> ka-Map-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/ka-map-dev
>