[OSM-ja] Fwd: [OSM-talk] Vector rendering on the client?

[Hiroshi Miura]

三浦です。

ジオデータをブラウザでベクターのまま処理する方式についての興味深い議論が展開しています。
ソフトウエアの研究として、面白そうです。



---------- Forwarded message ----------
From: Eric Wolf <ebwolf ＠ gmail.com>
Date: Fri, 31 Oct 2008 08:42:22 -0600
Subject: Re: [OSM-talk] Vector rendering on the client?
To: talk ＠ openstreetmap.org

Amongst us Paleo-geographers, there's an old saying:

"Vector's better but raster's faster."

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.

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.

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.

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.

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.

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.

-Eric

On Fri, Oct 31, 2008 at 6:07 AM, Thomas Wood <grand.edgemaster ＠ gmail.com>wrote:

> 2008/10/31 Stephan Schildberg <schildberg ＠ scoid.de>:
> > I would suggest to inform yourself about http://openlayers.org/ , which
> > solve some of your demands, although not with SVG.
> >
>
> It does use SVG, and has VML support for IE, however, nice rendering
> is beyond the scope of the project. Its current limits are essentially
> what we already have implemented on the Data layer of the osm.org
> slippy map.
>
> >
> > regards, Stephan.
> >>
> >>
> >> I think I'm on safe ground with my presumption that maps are recorded
> and
> >> stored in vector format. I observe that whan I try to _use_ the map (on
> >> Firefox 3 on SuSE 10.3/Linux) it takes a looooong time to render and
> does so
> >> in a bitmap format.
> >>
> >> Since my browser is able to render SVG natively (albeit a subset of the
> full
> >> SVG spec), is there a way to offload some of the processing burden from
> the
> >> server and retrieve maps in vector format.
> >>
> >> It strikes me that there should be some considerable advantages to doing
> this
> >> (if it's not already available :o)   ) Not least would be resolution
> >> independence. quicker zooming and, of particular interest to me, the
> ability
> >> to show/hide/make-translucent chosen features by
> category/name/layer/type/&c.
> >>
> >> Clearly there are some technical issues, such as how much of the detail
> to
> >> download at each zoomed level (Don't need to specify the pavement widths
> or
> >> even the existence of their host roads on a view of a continent) but I
> >> presume AJAXy technology can incrementally add/remove detail into/from
> the
> >> SVG DOM, on the zoom request
> >>
> >> <excuse>I guess I'm being a bit lazy and putting in a feature request
> without
> >> the prior research</excuse> but <hope>I'm sure you'll be kind and let me
> know
> >> in a kind and considerate way </hope>
> >>
> >> Cheers
> >>
> >> Greg
> >> (UK)
> >>
> >>
> >> _______________________________________________
> >> talk mailing list
> >> talk ＠ openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > talk mailing list
> > talk ＠ openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk
> >
> >
>
>
>
> --
> Regards,
> Thomas Wood
> (Edgemaster)
>
> _______________________________________________
> talk mailing list
> talk ＠ openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>



-- 
-=--=---=----=----=---=--=-=--=---=----=---=--=-=-
Eric B. Wolf                          720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography

-- 
Sent from Gmail for mobile | mobile.google.com

HIroshi Miura
NTT DATA Corp. and IPA OSS center
（株）NTTデータ /（独）情報処理推進機構
三浦広志