[ka-Map-users] Same API, but map images instead of tiles
jacob.delfos at maunsell.com
Sun Sep 18 22:40:40 EDT 2005
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,
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
caching of tiles helps reduce this issue significantly.
But I agree that keeping application development separate from
deployment issues is beneficial.
> -----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
More information about the ka-Map-users