[ka-Map-dev] purpose of tile.php
Lorenzo Becchi
lorenzo at ominiverdi.com
Mon Feb 27 15:50:16 EST 2006
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:
http://149.139.8.29/~rischio/cappu-kamap/ka-map/htdocs/
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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 6670 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/ka-map-dev/attachments/20060227/e2e6fad7/attachment-0001.bin
More information about the ka-Map-dev
mailing list