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
("TArialhree 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) < - 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@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