hi, re your perl port:<br>
the extra options in the setup in <a href="http://tmap-config.pm">tmap-config.pm</a> to allow initial zoom extent and center are a great idea. <br>
<br>
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. <br>
<br>
re no tiles:<br>
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? <br>
<br>
-brent<br><br><div><span class="gmail_quote">On 9/19/05, <b class="gmail_sendername">Stephen Woodbridge</b> <<a href="mailto:woodbri@swoodbridge.com">woodbri@swoodbridge.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Paul Spencer wrote:<br>> Hi Steve,<br>><br>> my feeling on this is that by the time you've done all the changes<br>> necessary to make it work without tiles, you won't have much ka-Map<br>> left. I understand your rationale, but ... as you acknowledged, ka- Map
<br>> is for certain types of applications only.<br><br>OK, so I guess that raises the following questions to the community:<br><br>What are other people doing with respect to server side tile management?<br>Are you managing it? How?
<br><br>How are you pruning the tile cache?<br><br>What kind of algorithm are you using to decide what tiles to keep and<br>what tiles to remove and is this tied to a total max. cache size.<br><br>> If you can come up with an alternate implementation that would bypass
<br>> the tiling stuff, I'd be willing to at least consider it, but it is<br>> certainly not high on my priority list to look into it or support it.<br><br>I will consider that if I have some time to work on ka-map. Javascript
<br>makes me crazy and as you probably know I don't need more help pushing<br>me in that direction! :)<br><br>Thanks,<br> -Steve<br><br>> Cheers<br>><br>> Paul<br>><br>> PS what ever happened to the perl port of the tiling code?
<br><br>It is here if anyone wants to use or work on it.<br> <a href="http://www.where2getit.com/mum3/">http://www.where2getit.com/mum3/</a><br>Since it was done as part of an evaluation, I have not kept the port up<br>
to date. If anyone wants to feel free to do that and contribute it to<br>the ka-map site.<br><br>> On 19-Sep-05, at 12:09 AM, Stephen Woodbridge wrote:<br>><br>>> Delfos, Jacob wrote:<br>>><br>>>> Steve,
<br>>>> I can see your point of view, in the sense that when using a few heavy<br>>>> raster layers, it's easy to get your server overloaded by tile-<br>>>> requests.<br>>>> But what would such a solution have to improve over Chameleon (and
<br>>>> others), which can be used in an almost no-page-refresh way? Also,<br>>>><br>>><br>>> Simplicity for for one and an application that can be deployed with<br>>> either tiles or not depending on the javascript loaded.
<br>>><br>>><br>>>> generating and serving out an image as large as a Ka-Map viewport for<br>>>> every redraw is quite CPU and Bandwidth expensive... The client-side<br>>>><br>>>
<br>>> I am thinking of generating the image of just the viewed portion of<br>>> the viewport because in many applications the user does not need to<br>>> pan. So if you user usage patterns are goto location, zoom in, zoom
<br>>> out, zoom out, pan, zoom in, zoom in, then you are not getting much<br>>> use of the cache and you are loading way more tiles into the viewport<br>>> than 7 mapserver image requests. If you done have the tiles already
<br>>> cached on the server, you still have to generate them, and bandwidth<br>>> is higher for the tiles because of all the non- viewed tiles that are<br>>> loaded.<br>>><br>>> It really makes sense for some application but clearly not for all.
<br>>> If it is just a matter of changing the javascript that is loaded, the<br>>> it can be switchable by the user if you want to export the control<br>>> for that.<br>>><br>>> Thank you for your comments.
<br>>><br>>> Anyway something to think about,<br>>> -Steve<br>>><br>>><br>>>> caching of tiles helps reduce this issue significantly.<br>>>> But I agree that keeping application development separate from
<br>>>> deployment issues is beneficial.<br>>>> Regards,<br>>>> Jacob<br>>>><br>>>><br>>>>> -----Original Message-----<br>>>>> From: <a href="mailto:ka-map-users-bounces@lists.maptools.org">
ka-map-users-bounces@lists.maptools.org</a> [mailto:<a href="mailto:ka-map-">ka-map-</a><br>>>>> <a href="mailto:users-bounces@lists.maptools.org">users-bounces@lists.maptools.org</a>] On Behalf Of Stephen Woodbridge
<br>>>>> Sent: 19 September 2005 02:50<br>>>>> To: <a href="mailto:ka-map-users@lists.maptools.org">ka-map-users@lists.maptools.org</a><br>>>>> Subject: [ka-Map-users] Same API, but map images instead of tiles
<br>>>>><br>>>>> Hi Paul,<br>>>>><br>>>>> I really like a lot of what is happening with ka-map. It is great<br>>>>> to see all the community effort going into ka-map.
<br>>>>><br>>>>> I was wondering what it would take to make it work without tiles as<br>>>>> an option. The idea would be that most of the code and logic would<br>>>>> be the same but instead of pulling tiles it would just request a
<br>>>>> single image. On a pan the current image would slide like the<br>>>>> current code and a new image would be requested and replace the<br>>>>> partially obstructed image from the pan operation when it is ready.
<br>>>>> I was thinking that this part (ie: tile vs map image rendering)<br>>>>> could be broken into two separate models with a common API and then<br>>>>> depending on which was used you would get different rendering
<br>>>>> behavior.<br>>>>><br>>>>> Why would anyone want this?<br>>>>><br>>>>> 1) less server requests<br>>>>> 2) no need for tiles and managing the tiles and disk space
<br>>>>> 3) maintains the rich no page refresh UI<br>>>>> 4) would allow richer server side image manipulation than exists<br>>>>> today because of the need to generate generic tiles.<br>
>>>> 5) separates application development from deploy concerns and issues<br>>>>> 6) would allow ka-map to do something that google can not do<br>>>>><br>>>>> Anyway, I thought I would float the idea and see what you had to
<br>>>>> say. Also I'm interested if others on the list think there would be<br>>>>> value for something like this.<br>>>>><br>>>>> -Steve W.<br>>>>> _______________________________________________
<br>>>>> ka-Map-users mailing list<br>>>>> <a href="mailto:ka-Map-users@lists.maptools.org">ka-Map-users@lists.maptools.org</a><br>>>>> <a href="http://lists.maptools.org/mailman/listinfo/ka-map-users">
http://lists.maptools.org/mailman/listinfo/ka-map-users</a><br>>>>><br>>>>><br>>><br>>> _______________________________________________<br>>> ka-Map-users mailing list<br>>>
<a href="mailto:ka-Map-users@lists.maptools.org">ka-Map-users@lists.maptools.org</a><br>>> <a href="http://lists.maptools.org/mailman/listinfo/ka-map-users">http://lists.maptools.org/mailman/listinfo/ka-map-users</a>
<br>>><br>><br>> +-----------------------------------------------------------------+<br>>
|Paul
Spencer
<a href="mailto:pspencer@dmsolutions.ca">pspencer@dmsolutions.ca</a> |<br>> +-----------------------------------------------------------------+<br>>
|Applications & Software
Development |<br>>
|DM Solutions Group
Inc
<a href="http://www.dmsolutions.ca/|">http://www.dmsolutions.ca/|</a><br>> +-----------------------------------------------------------------+<br>><br>><br>><br>><br>><br><br>_______________________________________________
<br>ka-Map-users mailing list<br><a href="mailto:ka-Map-users@lists.maptools.org">ka-Map-users@lists.maptools.org</a><br><a href="http://lists.maptools.org/mailman/listinfo/ka-map-users">http://lists.maptools.org/mailman/listinfo/ka-map-users
</a><br></blockquote></div><br>