[ka-Map-dev] purpose of tile.php
tim at commenspace.org
Mon Feb 27 14:48:33 EST 2006
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)?
> 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.
> > 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
More information about the ka-Map-dev