[ka-Map-users] Same API, but map images instead of tiles

[Stephen Woodbridge]

Paul Spencer wrote:
> Hi Steve,
> 
> my feeling on this is that by the time you've done all the changes  
> necessary to make it work without tiles, you won't have much ka-Map  
> left.  I understand your rationale, but ... as you acknowledged, ka- Map 
> is for certain types of applications only.

OK, so I guess that raises the following questions to the community:

What are other people doing with respect to server side tile management?
Are you managing it? How?

How are you pruning the tile cache?

What kind of algorithm are you using to decide what tiles to keep and 
what tiles to remove and is this tied to a total max. cache size.

> If you can come up with an alternate implementation that would bypass  
> the tiling stuff, I'd be willing to at least consider it, but it is  
> certainly not high on my priority list to look into it or support it.

I will consider that if I have some time to work on ka-map. Javascript 
makes me crazy and as you probably know I don't need more help pushing 
me in that direction! :)

Thanks,
   -Steve

> Cheers
> 
> Paul
> 
> PS what ever happened to the perl port of the tiling code?

It is here if anyone wants to use or work on it.
   http://www.where2getit.com/mum3/
Since it was done as part of an evaluation, I have not kept the port up 
to date. If anyone wants to feel free to do that and contribute it to 
the ka-map site.

> On 19-Sep-05, at 12:09 AM, Stephen Woodbridge wrote:
> 
>> Delfos, Jacob wrote:
>>
>>> Steve,
>>> I can see your point of view, in the sense that when using a few  heavy
>>> raster layers, it's easy to get your server overloaded by tile- 
>>> requests.
>>> But what would such a solution have to improve over Chameleon (and
>>> others), which can be used in an almost no-page-refresh way? Also,
>>>
>>
>> Simplicity for for one and an application that can be deployed with  
>> either tiles or not depending on the javascript loaded.
>>
>>
>>> generating and serving out an image as large as a Ka-Map viewport for
>>> every redraw is quite CPU and Bandwidth expensive... The client-side
>>>
>>
>> I am thinking of generating the image of just the viewed portion of  
>> the viewport because in many applications the user does not need to  
>> pan. So if you user usage patterns are goto location, zoom in, zoom  
>> out, zoom out, pan, zoom in, zoom in, then you are not getting much  
>> use of the cache and you are loading way more tiles into the  viewport 
>> than 7 mapserver image requests. If you done have the  tiles already 
>> cached on the server, you still have to generate  them, and bandwidth 
>> is higher for the tiles because of all the non- viewed tiles that are 
>> loaded.
>>
>> It really makes sense for some application but clearly not for all.  
>> If it is just a matter of changing the javascript that is loaded,  the 
>> it can be switchable by the user if you want to export the  control 
>> for that.
>>
>> Thank you for your comments.
>>
>> Anyway something to think about,
>>   -Steve
>>
>>
>>> caching of tiles helps reduce this issue significantly.
>>> But I agree that keeping application development separate from
>>> deployment issues is beneficial.
>>> Regards,
>>> Jacob
>>>
>>>
>>>> -----Original Message-----
>>>> From: ka-map-users-bounces at lists.maptools.org [mailto:ka-map- 
>>>> users-bounces at lists.maptools.org] On Behalf Of Stephen Woodbridge
>>>> Sent: 19 September 2005 02:50
>>>> To: ka-map-users at lists.maptools.org
>>>> Subject: [ka-Map-users] Same API, but map images instead of tiles
>>>>
>>>> Hi Paul,
>>>>
>>>> I really like a lot of what is happening with ka-map. It is great  
>>>> to see all the community effort going into ka-map.
>>>>
>>>> I was wondering what it would take to make it work without tiles  as 
>>>> an option. The idea would be that most of the code and logic  would 
>>>> be the same but instead of pulling tiles it would just  request a 
>>>> single image. On a pan the current image would slide  like the 
>>>> current code and a new image would be requested and  replace the 
>>>> partially obstructed image from the pan operation  when it is ready. 
>>>> I was thinking that this part (ie: tile vs map  image rendering) 
>>>> could be broken into two separate models with a  common API and then 
>>>> depending on which was used you would get  different rendering 
>>>> behavior.
>>>>
>>>> Why would anyone want this?
>>>>
>>>> 1) less server requests
>>>> 2) no need for tiles and managing the tiles and disk space
>>>> 3) maintains the rich no page refresh UI
>>>> 4) would allow richer server side image manipulation than exists  
>>>> today because of the need to generate generic tiles.
>>>> 5) separates application development from deploy concerns and issues
>>>> 6) would allow ka-map to do something that google can not do
>>>>
>>>> Anyway, I thought I would float the idea and see what you had to  
>>>> say. Also I'm interested if others on the list think there would  be 
>>>> value for something like this.
>>>>
>>>> -Steve W.
>>>> _______________________________________________
>>>> ka-Map-users mailing list
>>>> ka-Map-users at lists.maptools.org
>>>> http://lists.maptools.org/mailman/listinfo/ka-map-users
>>>>
>>>>
>>
>> _______________________________________________
>> ka-Map-users mailing list
>> ka-Map-users at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/ka-map-users
>>
> 
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> +-----------------------------------------------------------------+
> 
> 
> 
> 
>