[ka-Map-users] Architectural questions.

[Paul Spencer]

On 7-Nov-07, at 6:37 AM, The Bun wrote:
>
>> TileCache is a seperate software package which can be used, not
>> explicitly tied to OpenLayers. (Users have used it with WorldWind and
>> other similar code in the past.)
>
>> ka-Map is clientside code which is primarily designed to talk to its
>> server side API and configuration, in tile.php / config.php .
>>
>> OpenLayers can talk to the tile.php part of ka-Map via its KaMap  
>> layer.
>
> OK I assume I need to read more about tilecache and OpenLayers, time
> allowing.
> I understood ( but please tell me if I am wrong ) that kaMap has a  
> server
> side part
> and this is tile.php/config.php while OL hasn't a server part and  
> then need
> rely on
> something which may be tilecache or kaMap ( the server side ) , right?

correct about kaMap.  OL can also use mapserver directly (CGI), WMS,  
and a wide variety of other sources.

>
>>> On the other side I see that from OL you can actually working with
>>> kaMap layers ( although I couldn't test it), I really don't  
>>> understand
>>> what
>>> is the utility for doing that.
>
>> So that if you already have a working ka-Map cache, you can use that
>> instead of creating a new one.
>
> Are we talking about using the server side of kaMap, are we?

yes, the OL KaMap.js layer type can talk to a kaMap tile.php to get  
tiles.

> <snip>

> Is the OpenLayers map drawing better of the one already implemented in
> kaMap?
> If it is not good enough like OL, at this stage, is it not better  
> to try to
> improve kaMap instead of adding an extra layer?
>
> This make me quite confused. I appreciate the "future"  
> architecture, with
> kaMap that integrate OL but I am also concerned about it "now". It  
> seems
> that currently your second scenario:
>
> TileCache <-- OpenLayers
>
> is better than the first but the first scenario:
>
> Tile.php <-- kaMap
>
> is better for the future scenario:
>
> Tile.php <-- OpenLayers <-- kaMap
>
> as it seems to me that the second scenario doesn't give you an easy  
> U-turn
> chance while the first scenario will evolve naturally but it is  
> still a
> Future Scenario, if you know what I mean.

OpenLayers is arguably better depending on what you think better is.   
kaMap certainly isn't as configurable, and you cannot include other  
data sources easily.  On the other hand, it is probably a little  
easier to get started with and perhaps a bit lighter in the browser.

If you are looking for a Google-like replacement, OL has much more to  
offer.  If you are looking for a really basic tiled map engine that  
you can build on (and are willing to read the code to learn) then  
kaMap might do the trick.

>
>> This is the route that MapBuilder has taken, using OWS-Context for
>> configuration, creating a UI on top of OpenLayers using XML as a
>> description language.
>
> This makes my choice still more complicated, then we have another  
> scenario?
>
> Server <-- OpenLayers <-- MapBuilder

It gets worse.  There is also MapFish and Fusion which are  
application frameworks being built around OpenLayers.

Server <-- OpenLayers <-- MapFish

Server <-- OpenLayers <-- Fusion

Cheers

Paul

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+