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...<br>
<br>
Aaron<br><br><div><span class="gmail_quote">On 6/21/06, <b class="gmail_sendername">Tim Schaub</b> <<a href="mailto:tim@commenspace.org">tim@commenspace.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi All-<br><br>I like the idea of a merger and look forward to more discussion. In<br>general, I think pushing as much functionality as possible to the client<br>side is a good idea. For ka-Map, I'm imagining that a merger would mean
<br>all client side niceties could be retained (or improved) and all server<br>side functionality would be OGC spec. So, the server side tiling,<br>caching, etc could be retained as long as it conformed to the yet to be<br>
determined WMS-C specifications.<br><br>Maybe it would make more sense to say that this is really a proposal to<br>split ka-Map in half - so the two part proposal would be:<br>1) Merge ka-Map client side functionality with OpenLayers.
<br>2) Create a WMS-C compliant tile server out of the server side<br>functionality of ka-Map.<br><br>I imagine that people who used the results of #1 above (let's say it's<br>still called OpenLayers), would choose from a variety of tile services.
<br>The results of #2 above (say it's still called ka-Map, or maybe ka-Tile)<br>would only be one of the options for a server side solution.<br><br>So, limitations come up when you want to add functionality to the client<br>
side that relies on custom server side functionality (that wouldn't be<br>shared by all WMS-C options). An example limitation would be a nice<br>print to PDF tool. I think this can easily be addressed by custom<br>libraries or extensions. Developing a print to PDF tool would involve
<br>creating a tool that could plug in to the client side and call custom<br>code on the server side. Though this is essentially how things are done<br>already, it seems a cleaner way to develop - requiring that the<br>application can stand alone without the custom tools. I think others
<br>would probably agree that ka-Map could benefit from more modular<br>customizations.<br><br>In terms of the other differences that Paul brings up:<br><br>> * core tiling engine is very similar, but it is not quite as
<br>> optimal (doesn't reuse images for instance)<br><br>I think you mean the client side tile handling here. If so, the merged<br>client-side application would use the most optimal scheme.<br><br>> * overlay stuff is point/text only
<br><br>Again, the merged client-side application would make use of the most<br>mature stuff.<br><br>> * lacking tools (layer controls, scale bar etc) and the<br>> windowing stuff<br><br>I'm planning on rewriting the scale bar for
prototype.js and<br>contributing it to OpenLayers - so that's one small piece.<br><br>> * lacking query capability<br><br>I don't know enough about WFS querying to know what the real limitations<br>might be. It seems like this one deserves some more consideration.
<br>Though, I do like the idea of having all "template" style stuff (to<br>handle query responses) on the client side.<br><br>> * tile caching<br><br>If a WMS-C specification is decided upon, the current tile.php
<br>functionality could be modified to conform to that. In developing the<br>specification, a better cache design might arise too.<br><br>Looking forward to more,<br>Tim<br><br>_______________________________________________
<br>ka-Map-users mailing list<br><a href="mailto:ka-Map-users@lists.maptools.org">ka-Map-users@lists.maptools.org</a><br><a href="http://lists.maptools.org/mailman/listinfo/ka-map-users">http://lists.maptools.org/mailman/listinfo/ka-map-users
</a><br></blockquote></div><br><br clear="all"><br>-- <br>+--------------------------------------------<br>| Aaron Koning<br>| Information Technologist<br>| Prince George, BC, Canada.<br>+--------------------------------------------
<br>| <a href="http://datashare.gis.unbc.ca/fist/">http://datashare.gis.unbc.ca/fist/</a><br>| <a href="http://datashare.gis.unbc.ca/gctp-js/">http://datashare.gis.unbc.ca/gctp-js/</a><br>+--------------------------------------------