[ka-Map-dev] Overlay Objects
Paul Spencer
pspencer at dmsolutions.ca
Wed Feb 8 09:13:48 EST 2006
Lorenzo,
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
there.
Lorenzo and Andrea seem to be favouring option 1 and that would be
great.
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
directly
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
sort.
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 ...
Cheers
Paul
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