Amongst us Paleo-geographers, there's an old saying:<br><br>"Vector's better but raster's faster."<br><br>I just finished writing a paper for a conference in February where I had my programmer look at doing some basic geoprocessing of vector data in the browser with OpenLayers. We encountered a number of issues forced upon upon us by the JavaScript interpreter. <br>
<br>Firstly, JavaScript doesn't do a good job of managing the stack. If you ever write code to manipulate geospatial data, you'll find that many operations are very, very naturally recursive. We had to flatten out these algorithms and avoid recursion.<br>
<br>Second, at least in FF2, FF3, Opera and IE, arrays don't seem to be stored as consequtive objects in memory. There was a noticeable "lag" when trying to access elements of an large array the farther you got from "zero". It was like JavaScript was storing all arrays as associative arrays. It took 5 times longer to get the fifth element as it did the first. Safari specifically didn't have this problem. Our soultion: use linked lists and write the code to avoid random access into the array of vertices.<br>
<br>Finally, of course, IE is just b0rk3n. Even the new IE8 JavaScript interpreter was slower than FF2 (!) and only when we were able to finally get the code massaged into a form that it would accept. We couldn't get half of the tests to work at all.<br>
<br>We were fortunate to see Google Chrome and FF3.1 with TraceMonkey appear right before the due date for the paper. This meant a couple late nights but we were able to determine that these newer JavaScript interpreters are a little more "ready for primetime" when it comes to manipulating vector data in the browser.<br>
<br>What does this mean? If you look at Google, you see tiles. If you look at Yahoo, you see tiles. Tiles work well because raster is, indeed, faster. Also, every brower since Mosaic 1.0 has been able to display a raster tile. We still have 75%+ of the internet incapable of executing well-written JavaScript to manipulate vector.<br>
<br>-Eric<br><br><div class="gmail_quote">On Fri, Oct 31, 2008 at 6:07 AM, Thomas Wood <span dir="ltr"><<a href="mailto:grand.edgemaster@gmail.com">grand.edgemaster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/10/31 Stephan Schildberg <<a href="mailto:schildberg@scoid.de">schildberg@scoid.de</a>>:<br>
<div class="Ih2E3d">> I would suggest to inform yourself about <a href="http://openlayers.org/" target="_blank">http://openlayers.org/</a> , which<br>
> solve some of your demands, although not with SVG.<br>
><br>
<br>
</div>It does use SVG, and has VML support for IE, however, nice rendering<br>
is beyond the scope of the project. Its current limits are essentially<br>
what we already have implemented on the Data layer of the <a href="http://osm.org" target="_blank">osm.org</a><br>
slippy map.<br>
<div><div></div><div class="Wj3C7c"><br>
><br>
> regards, Stephan.<br>
>><br>
>><br>
>> I think I'm on safe ground with my presumption that maps are recorded and<br>
>> stored in vector format. I observe that whan I try to _use_ the map (on<br>
>> Firefox 3 on SuSE 10.3/Linux) it takes a looooong time to render and does so<br>
>> in a bitmap format.<br>
>><br>
>> Since my browser is able to render SVG natively (albeit a subset of the full<br>
>> SVG spec), is there a way to offload some of the processing burden from the<br>
>> server and retrieve maps in vector format.<br>
>><br>
>> It strikes me that there should be some considerable advantages to doing this<br>
>> (if it's not already available :o) ) Not least would be resolution<br>
>> independence. quicker zooming and, of particular interest to me, the ability<br>
>> to show/hide/make-translucent chosen features by category/name/layer/type/&c.<br>
>><br>
>> Clearly there are some technical issues, such as how much of the detail to<br>
>> download at each zoomed level (Don't need to specify the pavement widths or<br>
>> even the existence of their host roads on a view of a continent) but I<br>
>> presume AJAXy technology can incrementally add/remove detail into/from the<br>
>> SVG DOM, on the zoom request<br>
>><br>
>> <excuse>I guess I'm being a bit lazy and putting in a feature request without<br>
>> the prior research</excuse> but <hope>I'm sure you'll be kind and let me know<br>
>> in a kind and considerate way </hope><br>
>><br>
>> Cheers<br>
>><br>
>> Greg<br>
>> (UK)<br>
>><br>
>><br>
>> _______________________________________________<br>
>> talk mailing list<br>
>> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
>> <a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> talk mailing list<br>
> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Regards,<br>
Thomas Wood<br>
(Edgemaster)<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-=--=---=----=----=---=--=-=--=---=----=---=--=-=-<br>Eric B. Wolf 720-209-6818<br>USGS Geographer<br>Center of Excellence in GIScience<br>
PhD Student <br>CU-Boulder - Geography<br><br>