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

[Tim Schaub]

Thanks for the ideas.  I think I'm probably not being clear about use case #3 (or maybe it's less typical than I imagine).  More below...

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

Here's an example:  Imagine a database of wildlife surveys.  These are records that describe observations of particular species (hundreds of thousands of records).  On the UI of my application, the user can generate a query by selecting a single species from a dropdown (for example).  On the server side, abundance data is generated based on that query (number of individuals observed in all surveys).  I want to serve this data up to the client based on pre-determined symbology.

This is easiest done (in my opinion) by having a mapfile with a LAYER that has all the CLASSes I need (I might have symbols sized or colored by level of abundance).  If my data is in Postgres, I can have a %variable% in the DATA parameter that gets generated by the client.  If my data is in some other format, I can have my %variable% be an inline OVF that gets substituted in the CONNECTION string.

I'm assuming this is why other people use variable substitution, and it seems generally useful to me.

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

I'm happy to just customize my own tile.php - but I would be surprised if nobody else would find this useful.  Even if you can't imagine a use for variable substitution, does it make sense to anybody that the client side scripts should be able to decide whether tile.php needs to be called at all (use case #1) - and if so, whether it should force the re-rendering of tiles or not (case #3 or #2)? 

Tim

> 
> 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
> >
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.1.0/269 - Release 
> Date: 2/24/2006
>  
> 

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