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

[Paul Spencer]

Thanks everyone for the excellent discussion on the list yesterday.   
Apologies for the slowness of the maptools mail server, it seems to  
have created some confusion but I think it all got sorted out in the  
end.  I have some comments on most of the emails from yesterday.   
Rather than writing individual responses, though, I am going to  
summarize them into a single email (this one :)).  I've probably  
missed some points as well.  Hopefully we can pick those up in IRC.

Steve asked what does OpenLayers offer that ka-Map doesn't?  I don't  
think it offers much to me that ka-Map doesn't already do in terms of  
functionality.  In fact, I think it has less functionality.  What it  
does offer is more from an architectural point of view.  I have not  
been happy with the ka-Map code since I wrote it ... not because of  
the functional aspect, but because I never took the opportunity to  
work out a decent architecture.  The code more-or-less fell in place  
around the original core tiling engine.  It lacks organization and is  
not very readable.  It is also difficult to follow the math, as some  
of you have heard me say.  But that is somewhat irrelevant.  I think  
the real point of this is that a combination of the two projects can  
offer more than each project can individually.  We could combine  
developers and user communities to create more momentum for a joint  
project I think.

Chris pointed out that there are 2 camps (and someone else said 3) of  
users and that ka-Map serves one while OpenLayers serves the other.   
My goal would be to produce a project that meets all these needs  
without compromising anything in each particular use case.  I don't  
think two separate releases would be needed, but there may be some  
part of the API that is optional that provides the extra capability  
so that if you don't need it, you don't have to load it.

Splitting ka-Map in half and keeping the tile server as a separate  
project is an option that I would consider.  The tile cache server is  
really quite separate from the UI code and having both in ka-Map  
generated some confusion about the ka-Map API.  Let's leave the tile  
caching part out of the discussion (or at least start a separate  
discussion for it).

Prototype is bad.  The big argument against prototype is its  
modification of the array object ... which is bad and breaks the 'for  
(var i in a)' syntax but ... I'm willing to live with it because of  
everything else it does.  I'm addicted to the crack cocaine of  
javascript :)  Actually, I've read other critiques of prototype that  
are more compelling (from a software engineering point of view) than  
this one.  And the author of prototype is taking steps to address  
those issues, so its really a moot point as far as I'm concerned.

Community MapBuilder, ka-Map and OpenLayers ... my take on this (and  
this isn't everyone's point of view) is that ka-Map is an API you can  
use to get a tiled map engine in a web page.  OpenLayers seems to be  
essentially the same to me.  MapBuilder is about creating  
applications and is more similar in purpose to Chameleon and  
MapBender (why didn't anyone ask about those I wonder?).  I think the  
question comes up because these projects provide for an (almost)  
client-side only capability.  I would hope that ka-Map (and/or  
OpenLayers) could be used to provide the Map control inside a  
Community MapBuilder application.  And inside Chameleon and  
MapBender, if those projects want it.

Forking ... the intention is to build a stronger developer and user  
community by merging them.  If this process ends up in a fork then  
we've failed.  But if you think about it, this is about a reverse  
fork.  The communities and developers are currently separate.  We  
want to combine them.  If we start down this road and move a bunch of  
stuff into OpenLayers, ka-Map doesn't really change (although it  
won't move ahead for a while).  If the merge fails, we haven't really  
lost anything on the ka-Map side (except some time perhaps) and  
OpenLayers may be improved by the process (or I would like to think so).

MapGuide is not a driver for this.  It has its own tile generation  
and caching.  It has its own tile client code.  I haven't looked at  
either.  Thinking out loud, it might be nice to be able to use  
MapGuide's tiles in a combined ka-Map/OpenLayers ... but MapGuide is  
still pretty much an unknown in this equation.

Level of effort to integrate and get back to current functionality is  
difficult to judge.  There are several aspects to this that require  
more thought.  Its probably a couple of man-weeks.  My sense is that  
it would be more effort to make ka-Map do the OpenLayers things than  
the other way around though.  I could be wrong on that.

The prospect of re-writing ka-Map to use prototype.js was one of the  
drivers for this discussion.  I am addicted to the prototype crack :)  
so it was going to happen.  I was expecting this to be several (+)  
days of effort.  It would likely have resulted in an architecture  
quite similar to OpenLayers.  It probably would not have incorporated  
the idea of being able to use the Google/VE/Yahoo mapping engines  
directly without violating their terms of use as I (personally) don't  
have a use-case for that.

I don't expect the merger to happen overnight.  A lot of effort has  
gone into ka-Map recently and I think we (the developers  
collectively) would want to get a release out the door (0.3 is  
planned).  There is also an issue with FOSS4G and the planned ka-Map  
workshop which we need to think about.

What I do expect is to have this very healthy discussion and reach a  
conclusion as to whether this is a 'Good Thing' or not, and if it is,  
under what conditions should the merge happen.  I think if we decide  
that a merge is a good thing, I will not go ahead with my planned  
core refactoring of ka-Map.  Instead, I will focus on starting to  
port over the core stuff to OpenLayers that I feel could help (some  
of the tiling stuff that is very internal).  Once that is done, I  
will start evaluating the delta in the client API and client  
interface and start porting that over.

As with most of the ka-Map folks, I have a vested interest in the  
existing ka-Map code (several clients and our commercial MapSherpa  
service).  I want to get a decision quickly so that I don't waste  
effort on stuff that won't be needed, but I don't want it to move too  
quickly either.  I think the total process should take up to 6 months.

One final parting note.  It was my plan at some point to propose that  
ka-Map join OSGeo.  I hesitated to jump on the initial bandwagon  
because ka-Map's development community is relatively immature as a  
project (we lack an organized decision making process and formal  
project management structure).  I think one of the objectives of a  
merge would be to create a project that could migrate into the OSGeo  
Foundation smoothly.  As an active member of the Incubation  
committee, I have a very good insight into what is required.  Part of  
the merge process would be to start creating the type of project that  
could migrate into OSGeo, including project oversight and code  
provence etc.

See you in #ka-Map

Paul

+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+