[ka-Map-dev] Overlay Objects
Lorenzo Becchi
lorenzo at ominiverdi.com
Wed Feb 8 10:32:42 EST 2006
Ok it seems we are tuned.
I agree with everything you've said so i go on with puntualizations:
# I think that we have to focus on mode 1 and 3. We do the 1, you do
the 3 (anyway we can help each other). With respect to Stephen his
solution is quite heavy: what happens if you in a world map you ask to
overlay russia and then you start zooming? russia overlay start to
became enormous. Is it the point?
# You can start from point 3. It seems we just need to set a variable
to enable or not client side vector drawing. Maybe a mode? (mode:
standard, standard + VML, standard + VML + SVG). Or a number? (like in
chmod... he he). You choose, I'll agree.
I've never seen convincing solutions made with wz_graphics, that's why
we abandoned it. I'll be please to change my mind if there's a good
solution
#XML
I've not yet studied KML but I agree with you that's the good starting
point. I've already seen GeoRSS but is seems not complete to me. I'll
like google compatibility (anyway, we will not post advertising!).
# developing point 1
I'm happy you understood on the fly my idea. I was not so convinced how
I explained.
The list on points you did is quite like I think it.
I'll use just one tileOverlayLayer. If we can optimize the idea Andrea
had to change only needed tiles it would be really quick to add an
object and render it on the fly (server would need to print just few
tiles).
#server-side session
it could be an idea. We'll think it soon.
Another problem PG questioned was the caching cleanup. It seems is not
a major problem as well.
#image map
I really love this idea. When it pop up in my brain I had to talk to
Andrea, it took me a while to explain the entire idea with logic. he he
The mapguide solution seem interesting but I want to try a diffferent
way. Do you remember the coordinate printer function? it was really
slowing down the client (I was not happy 'cause I wrote it...).
--------
Now
let starts studying KML
I would be better if both we try to think a nice solution to implement
the switch, in the API, from version 1 to version 3 (3.1,3.2,3.3, ecc).
It can be automatic or not; or both....
I working on some ideas on layout solution too... I'll post you
something once I've clear ideas about it
ciao
Lorenzo
Il giorno 08/feb/06, alle 15:13, Paul Spencer ha scritto:
> 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