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

[Aaron Koning]

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/e10a2381/attachment.html