[ka-Map-users] ka-Map and OpenLayers

Fischer, Brian bfischer at houstonengineeringinc.com
Wed Jun 21 12:34:47 EDT 2006


Aaron - I don't think it is a silly question at all.  Rather an obvious
one that needs to be asked.

 

I too would like to hear what people think are the differences between
community mapbuilder, OpenLayers and the client-side Ka-map code.  All
three projects seem to have very similar goals, to create a client-side
library that is easy to use and independent of the server-side map
engine.

 

Brian Fischer

Houston Engineering, Inc.

Maple Grove, MN

(763) 493-4522

________________________________

From: ka-map-users-bounces at lists.maptools.org
[mailto:ka-map-users-bounces at lists.maptools.org] On Behalf Of Aaron
Koning
Sent: Wednesday, June 21, 2006 11:02 AM
To: ka-map-users at lists.maptools.org
Subject: Re: [ka-Map-users] ka-Map and OpenLayers

 

Let me ask a silly question. As Tim has described the 2 components
below, how similar would number 1 (Merge ka-Map client side
functionality with OpenLayers) be when compared to Community Mapbuilder?
is there potential for a three way merge and/or concentration on the
most robust client side mapper of the three? Just trying to make life
more complicated... or simpler...

Aaron

On 6/21/06, Tim Schaub <tim at commenspace.org> wrote:

Hi All-

I like the idea of a merger and look forward to more discussion.  In
general, I think pushing as much functionality as possible to the client
side is a good idea.  For ka-Map, I'm imagining that a merger would mean

all client side niceties could be retained (or improved) and all server
side functionality would be OGC spec.  So, the server side tiling,
caching, etc could be retained as long as it conformed to the yet to be
determined WMS-C specifications.

Maybe it would make more sense to say that this is really a proposal to
split ka-Map in half - so the two part proposal would be:
1) Merge ka-Map client side functionality with OpenLayers. 
2) Create a WMS-C compliant tile server out of the server side
functionality of ka-Map.

I imagine that people who used the results of #1 above (let's say it's
still called OpenLayers), would choose from a variety of tile services. 
The results of #2 above (say it's still called ka-Map, or maybe ka-Tile)
would only be one of the options for a server side solution.

So, limitations come up when you want to add functionality to the client
side that relies on custom server side functionality (that wouldn't be
shared by all WMS-C options).  An example limitation would be a nice
print to PDF tool.  I think this can easily be addressed by custom
libraries or extensions.  Developing a print to PDF tool would involve 
creating a tool that could plug in to the client side and call custom
code on the server side.  Though this is essentially how things are done
already, it seems a cleaner way to develop - requiring that the
application can stand alone without the custom tools.  I think others 
would probably agree that ka-Map could benefit from more modular
customizations.

In terms of the other differences that Paul brings up:

> * core tiling engine is very similar, but it is not quite as 
> optimal (doesn't reuse images for instance)

I think you mean the client side tile handling here.  If so, the merged
client-side application would use the most optimal scheme.

> * overlay stuff is point/text only 

Again, the merged client-side application would make use of the most
mature stuff.

> * lacking tools (layer controls, scale bar etc) and the
> windowing stuff

I'm planning on rewriting the scale bar for prototype.js and
contributing it to OpenLayers - so that's one small piece.

> * lacking query capability

I don't know enough about WFS querying to know what the real limitations
might be.  It seems like this one deserves some more consideration. 
Though, I do like the idea of having all "template" style stuff (to
handle query responses) on the client side.

> * tile caching

If a WMS-C specification is decided upon, the current tile.php 
functionality could be modified to conform to that.  In developing the
specification, a better cache design might arise too.

Looking forward to more,
Tim

_______________________________________________ 
ka-Map-users mailing list
ka-Map-users at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/ka-map-users 




-- 
+--------------------------------------------
|  Aaron Koning
|  Information Technologist
|  Prince George, BC, Canada.
+-------------------------------------------- 
|  http://datashare.gis.unbc.ca/fist/
|  http://datashare.gis.unbc.ca/gctp-js/
+-------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/ka-map-users/attachments/20060621/e14792fc/attachment-0001.html


More information about the ka-Map-users mailing list