<span class="gmail_quote"></span>Frankly, I have one use for which what Steve W's approach would be
genius. If you could have all your static layers which are going
to be cached once and rarely if ever change, then for folks who have
layers that are time specific or are changing day to day, then just
drawing those for the screen without any kind of cacheing would be
great. <br>
<br>
The behaviour to the end user would be transparent since ka-map hides
all but the base layers during dragging so if we had a mouseup event
that fired off a request just for the one dynamic layer (think weather,
vehicle locations, flight tracks ...) you would get the instant
feedback that makes ka-map wonderful without being limited to datasets
that play well with that type of interface.<br><span class="sg">
<br>
David</span><div><span class="e" id="q_1066eba5728ebdbd_2"><br><br><div><span class="gmail_quote">On 9/19/05, <b class="gmail_sendername">Steve Lime</b> <<a href="mailto:steve.lime@dnr.state.mn.us" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
steve.lime@dnr.state.mn.us</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;">
I
can see the rationale but there are many other interfaces that give you
this in one way or another now so is it worth bothering with? Seems to
me that ka-map has a pretty well-defined niche carved out and it should
stick to it, as opposed to making it do everything
ROSA/jbox/mapbender/... already do.<br><br>Steve<br><br>>>> Stephen Woodbridge <<a href="mailto:woodbri@swoodbridge.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">woodbri@swoodbridge.com
</a>> 09/18/05 1:50 PM >>><br>Hi Paul,<br><br>I really like a lot of what is happening with ka-map. It is great to see
<br>all the community effort going into ka-map.<br><br>I was wondering what it would take to make it work without tiles as an<br>option. The idea would be that most of the code and logic would be the<br>same but instead of pulling tiles it would just request a single image.
<br>On a pan the current image would slide like the current code and a new<br>image would be requested and replace the partially obstructed image from<br>the pan operation when it is ready. I was thinking that this part (ie:
<br>tile vs map image rendering) could be broken into two separate models<br>with a common API and then depending on which was used you would get<br>different rendering 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 today<br>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 say.<br>Also I'm interested if others on the list think there would be value for
<br>something like this.<br><br>-Steve W.<br>_______________________________________________<br>ka-Map-users mailing list<br><a href="mailto:ka-Map-users@lists.maptools.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ka-Map-users@lists.maptools.org</a><br><a href="http://lists.maptools.org/mailman/listinfo/ka-map-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.maptools.org/mailman/listinfo/ka-map-users</a><br><br><br>_______________________________________________<br>ka-Map-users mailing list<br><a href="mailto:ka-Map-users@lists.maptools.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ka-Map-users@lists.maptools.org
</a><br><a href="http://lists.maptools.org/mailman/listinfo/ka-map-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.maptools.org/mailman/listinfo/ka-map-users</a><br></blockquote>
</div><br>
</span></div>