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

Paul Spencer pspencer at dmsolutions.ca
Mon Feb 27 19:01:34 EST 2006


on reflection, I think that your proposal of three separate cases is  
a good one.

One way of approaching this would be to provide different '_layer'  
objects that provide alternate setTile methods.  These could hit  
different versions of tile.php on the server.

Option 1 will only work if the tile cache is web-accessible.  It  
would require configuring the url to the tile cache in config.php or  
some other location.  I can see a _staticLayer object in javascript  
that would know the url to the cache and could append the appropriate  
subdirectories to get the actual tile

Option 2 is the existing _layer and tile.php.  This could benefit  
from the FORCE_CACHE option and map file versioning.  Other than  
that, its pretty good as is

Option 3 could use a _dynamicLayer object that would hit  
dynamictile.php which would be your implementation of allowing  
variables.  Note that we will need to be quite careful to avoid sql  
injection problems and other similar attacks that could leave people  
exposed in ways they don't understand.

Lorenzo and Andrea have been working on a similar thing, although I  
think it is targetted at dynamically created features.  Its a slight  
difference from Option 3 that would deserve its own _xxxxLayer type  
and supporting xxxxtile.php.



On 27-Feb-06, at 3:50 PM, Lorenzo Becchi wrote:

> Ok Tim,
> it seems to me we are talking about the same thing.
> That's what me and Andrea are trying to do with the overlay object  
> function.
> At the moment we start getting data from an XML file because is the  
> hardest data-set but we already know that is simple to cut a  
> database related interface.
> Have a look to our implementation. It is not complete and maybe  
> you'll find some problems using it. I think we'll offers something  
> useful in two weeks.
> go here:
> index_overlay.html
> and click on "call overlay"
> you'll see three green polygon drawn on a new layer ("Three objects  
> Polygon"). If you cut away how it is called it is just another  
> layer drawn on the fly that appears and can be managed as all other  
> layers (more other it has onmouseclick function related to objects).
> The code is not proper but if you watch inside the XMLOverlay/ 
> overlay.php and in kaOverlay.js, it seems to me, you can find all  
> functions you need to do what you are looking for.
> If you agree with my opinion and you are not in an hurry, wait  
> until we present our work and we can perhaps (if all of you agree)  
> create a generic class that get a layer obj and inject the js layer  
> code back to kamap.
> it seems to me this is a good debate
> comment freely and let me know if I'm losing something
> ciao
> Lorenzo
> Il giorno 27/feb/06, alle 20:48, Tim Schaub ha scritto:
>> 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
> _______________________________________________
> ka-Map-dev mailing list
> ka-Map-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/ka-map-dev

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

More information about the ka-Map-dev mailing list