[ka-Map-users] Same API, but map images instead of tiles
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Sep 19 13:53:26 EDT 2005
Brent Pedersen wrote:
> hi, re your perl port:
> the extra options in the setup in tmap-config.pm
> <http://tmap-config.pm> to allow initial zoom extent and center are a
> great idea.
>
> other than that, was there any benefit? why not just use the php stuff?
> i do prefer perl, but i had been sticking with php for mapserver because
> better support and docs.
Use whatever. We are primarily a perl shop and it was an exercise to see
if it would work and what issues it might present. In general the code
is pretty simple for the most part. Also, if I ask on of the developers
to add a feature it would be easier for a Perl programmer to make
changes to Perl code rather than PHP.
> re no tiles:
> wouldn't that have a similar effect as increasing the tile size in
> config.php? because when i do that, there is a drastic decrease in
> performance. will your implementation avoid that?
A lot of people seem to be missing the point on this. ka-map loads lots
of tiles that are off screen so when you pan initially, it already has
all the tiles it needs and it looks seamless. But you pay a bandwidth
and cpu cost for computing and loading the extra tiles if the user never
pans or only pans in one direction because you have loaded tiles in all
the other directions also. My proposal was to only compute and load the
visible portion of the map and on pan you would slide it partially off
the view and request a new image of just the new visible map and replace
the partially obscured image. You would not generate metatiles, you
would not chop the tiles, etc, only request what you need when you need
it, if you need it.
Why? One API for both image generation models, common API for
applications development, etc. I think ka-map is a good API that allows
for a rich development environment.
-Steve W.
> -brent
>
> On 9/19/05, *Stephen Woodbridge* <woodbri at swoodbridge.com
> <mailto:woodbri at swoodbridge.com>> wrote:
>
> 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> [mailto:ka-map-
> <mailto:ka-map->
> >>>> users-bounces at lists.maptools.org
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:ka-Map-users at lists.maptools.org>
> >> http://lists.maptools.org/mailman/listinfo/ka-map-users
> >>
> >
> > +-----------------------------------------------------------------+
> > |Paul Spencer pspencer at dmsolutions.ca
> <mailto:pspencer at dmsolutions.ca> |
> > +-----------------------------------------------------------------+
> > |Applications & Software Development |
> > |DM Solutions Group Inc http://www.dmsolutions.ca/|
> > +-----------------------------------------------------------------+
> >
> >
> >
> >
> >
>
> _______________________________________________
> ka-Map-users mailing list
> ka-Map-users at lists.maptools.org <mailto:ka-Map-users at lists.maptools.org>
> http://lists.maptools.org/mailman/listinfo/ka-map-users
> <http://lists.maptools.org/mailman/listinfo/ka-map-users>
>
>
More information about the ka-Map-users
mailing list