[ka-Map-dev] Overlay Objects

Paul Spencer pspencer at dmsolutions.ca
Wed Feb 8 09:13:48 EST 2006


this is a great start.  I can see the benefits of this approach ...  
I'll outline quickly some alternatives:

1. tiled overlay layer (proposed by Lorenzo).  See below.

2. non-tiled overlay layer (Stephen Woodbridge proposed this, and it  
is used in MapGuide Open Source).  In this mode, an overlay image is  
rendered just big enough to fill the viewport.  If the user pans, the  
image is repositioned and regenerated when the pan stops.

3. client side overlays using existing canvas functions (Pg and  
myself are in this camp).  There are alternatives to this approach

3.1 use client side library to render features - SVG, <canvas>, VML,  
wz_jsgraphics are all alternatives

3.2 use images generated by server side

Have I missed any reasonable alternatives?

I think ka-Map should support both 1 and 3.  I personally don't like  
2 for reasons I probably can't explain well, but if someone is  
willing to contribute it, it would be ok.

My interest is currently in 3.1 using <canvas> and VML with a fall- 
back on unsupported browsers to 3.2 so I will be investing my time  

Lorenzo and Andrea seem to be favouring option 1 and that would be  

What we need is a common architecture to render overlay features that  
can use either back end depending on the application designer's choice.

I think that we should not re-invent the wheel on xml formats.  With  
that in mind, I think we should consider the following formats:

1. KML
2. GeoRSS
3. GML

For Google compatibility, KML would be very nice to support.  It is  
also the richest in terms of expressing presentation of the data.   
And there is potentially lots of data being served up via KML

GeoRSS is essentially a simple subset of GML making it somewhat  
lighter.  Its good for the spatial part of features but doesn't  
capture the styling.

GML ... well, that's my third choice but it could probably be  
supported quite easily once we have an architecture in place.

To support any of these, we need an API and some objects to represent  
the things we need.  Pg's documentation of kaXmlOverlay seems to be a  
pretty reasonable start at this.  I haven't investigated his code,  
but it could be the best place to start.

For supporting option 1, I think the best approach is to create an  
new _layer object in javascript that loads tiles from a different  
script than tile.php.  wmsLayer is an example of sub-classing _layer  
and bypassing the tile cache.  I would propose the following as a  
possible approach:

1. client loads xml document containing overlays OR adds primitives  

2 (a). new tiledOverlayLayer is created.  This calls an  
initOverlay.php function through XmlHttpRequest that creates a  
sessionid on the server side and returns it to the client.  The  
sessionid is stored in the tiledOverlayLayer object and is used in  
all subsequent requests (including tile requests).

2 (b). existing tiledOverlayLayer is used.

3. changes to the style of the overlay are sent to  
setOverlayStyle.php through XmlHttpRequest with the sessionid and  
stored on the server side for rendering

4. features are sent to setOverlayFeatures.php using XmlHttpRequest  
(in POST mode to avoid url length problems) along with the  
sessionid.  This script could also be used to remove overlay features  
or change them.  Each feature should have a unique feature id of some  

5. tile source for tiles in the layer is set to overlayTile.php which  
gets the session id in addition to the regular tile.php paramaters.   
overlayTile.php returns an image of the overlay from the session  
cache of the overlay features rendered using the overlay style.

The disadvantage to this approach is the need for some sort of server- 
side session.  Realistically, if you want to take advantage of  
mapscript to render stuff (for projection support) then you will need  
some sort of server-side session I think.   It may be possible to  
send everything to the server from the client on each request, but  
this could get very large very quickly.

I have not started thinking about an architecture for option 3  
really, but it would not be much different from the existing approach  
except for providing alternate rendering on the client side depending  
on the browser support.

For supporting client side interaction with option 1 where the  
features do not have a life of their own, imagemap support is one  
approach that could work well.  I think we could generate imagemaps  
on the fly for each overlay tile as it is created by using  
XmlHttpRequest to getOverlayImagemap.php or something like that.

An alternate approach (used by MapGuide Open Source) is to track  
mouse movement and when the mouse hovers over a tile, make an  
XmlHttpRequest to retrieve information about the current location ...  
I'm not sure how well this would work, but it does work reasonably  
well in MapGuide Open Source.

okay, I think I should stop typing now :)  Looking forward to  
continuing the discussions ...



On 8-Feb-06, at 6:10 AM, Lorenzo Becchi wrote:

> Today I've started talking with Andrea about push a little bit on  
> the Overlay System.
> Next week we'll be together developing only on ka-map (maybe...)
> Starting point is PG work:
> http://ka-map.ominiverdi.org/wiki/index.php?OverlayApiDiscussion
> His API seems to me a good starting point.
> About Point, Symbol, Icon and Label implementation I've nothing to  
> say (maybe we can change little things before starting coding).
> What we have in mind is about Linestring and Polygon. We want to  
> start from ka-map core function: tiling.
> We hope to offer a solution that could work on any AJAX compliant  
> browser avoiding, for the moment, vectorial implementations as IE  
> Canvas or SVG or WZ_jsgraphics.
> First of all we think to create a layer (we can call it Canvas, or  
> a better name) in the Viewport where, starting from XML, objects  
> can be designed by the server, then tiled and finally back to the  
> client.
> In contrary to wz_jsgraphics, this system permits managing Lines  
> and Polygons of big size and let us use pan and zoom functions  
> without charging the client (wz_graphics could really slow the  
> client). For the client is like another layer over the others: it  
> can be very light if well optimized (few kb for tile).
> If there's an updating procedure we would like to try to implement  
> a solution that update only changed tiles (es: a point that moves  
> on the map).
> now the problem is to give this drawn objects some life.
> We think to create a "special" level (trying to call it  
> CanvasProxy, or a better name).
> We are not sure about this implementation, maybe somebody can  
> contribute with a better idea.
> Anyway we want to use, inside the CanvasProxy, a transparent image  
> (1px height & width) and force his dimensions to the map extent (so  
> it changes depending on zoom level) then let it pan as layers below.
> The hazard is: an imagemap.
> Imagemap is the only HTML object that permits to design  irregular  
> polygons (not just rectangles) and simply attach event listeners  
> (es: onclick, onmouseover). Moreover it can be easily manage with  
> DOM scripting (+ or -).
> Now, for each polygon drawn in the Canvas there will be an AREA tag  
> with his shape (rectangle, circ, circle, poly, polygon; maybe just  
> polygons) for the CanvasProxy transparent image. Then for each  
> polygon we can associate onclick and mouseover events extending ka- 
> map ones.
> In a future we can extend this method to edit objects just drugging  
> polygon extremes, alter the XML on the fly and send it back to the  
> server to render the Canvas layer.
> To start working on this we need to choose the XML schema we want  
> to use. Maybe Paul already decided (let us know).
> please, send comments
> ciao
> Lorenzo
> _______________________________________________
> 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