Hi Deli,
Thanks for your consideration on WMS caching. I already use TileCache.
My point here was more about _vector_ data format like GML or GeoJSON.
Such data don't come to the browser as images but as textual file,
therefore they need client-side parsing and are rendered based on SVG
browser capacities.
Using vector data could provide better user interaction since you can
re-style the geometries, read/write attribute data and so on without any
single HTTP request. Have a look at OpenLayers examples about vector
rendering to get an idea.
Unfortunately, the parsing and rendering of such data is an heavy
_client-side_ process and that's make it difficult to use vectors for
applications where the number of geometries exceeds a few dozens.
Regards
Gilles
Deli Soetiawan wrote:
What gis server you use as wms? is it umn mapserver? mapguide? geoserver?
You could precache (render the image first) using Kamap & KamapCache layer
as a baselayer, Kamap works by creating tiled images in several scale, at
first it might be slow (since it generate many images) but after that tiled
images are cached on server so next time you (user) request the tile it only
send the image without additional process (it don't regenerate image
everytime you request the tile).
Ofcourse you need to able to use .map files as a baselayer inorder to use it
(it would be great if your application is on same server with your gis
server).
Gilles Bassière-2 wrote:
Hi list,
In a recent post about hiking trails, I can read: "Be aware though that
using vector data in a browser can lead to serious performance problems
when the data becomes large."
Well, I ran into this same problem a few days ago and eventually choose
a WMS-based solution. Anyway, I remain very interested in client-side
vector rendering. Before exploring further, I wonder if anyone has
experience to share regarding large vector dataset.
In my case, my vector layer featured up to several hundreds geometries
(and the user may overlay more vector layers!). Such data volume seems
definitely too high for vector rendering but still, I guess it's
possible to enhance performance with a clever configuration.
I can see 3 ways to reduce the load on browser (please feel free to
correct if I'm wrong):
1) reduce the file size
2) use a format that is efficiently parsed
3) reduce the data extent
I attempted to switch my layers format to GeoJSON instead of GML. I
expected smaller file size and faster interpretation (given that JSON is
native Javascript). Unfortunately, I can't see any real performance
improvement. The file size is half as much but my browser still hang for
a while (transfer time not taken into account). I confess I haven't been
into rigourous tests or preformance benchmark.
I haven't investigate much about reducing data extent. In both case the
whole dataset (full layer extent) is fetched and parsed. Anyway, loading
only the visible extent is not useful at small scale and I wonder if
it's a good idea at large scale: file size would be dramatically reduced
but merging existing data with new data might be too complex, moreover
downloading and parsing data on each pan or zoom might break smooth
navigation.
Regarding strict impact of vector data volume on browser capacities, is
there a "best configuration"? Any difference between WFS and GeoRSS OL
layers? Is there a recommanded way to use GeoJSON (other than
Layers.Vector+Format.GeoJSON)?
Also, I know that MapBuilder used the Sarissa library to deleguate GML
parsing to the browser XML engine. As far as I remember, the performance
were not too bad. How could this be possible in OL, should I try to wrap
the library in an alternate Format.XML?
Regards,
Gilles
--
Gilles Bassiere
MAKINA CORPUS
30 rue des Jeuneurs
FR-75002 PARIS
+33 (0) 1 44 82 00 80
http://www.makina-corpus.com
begin:vcard
fn;quoted-printable:Gilles Bassi=C3=A8re
n;quoted-printable:Bassi=C3=A8re;Gilles
org:Makina Corpus;GIS
adr;quoted-printable:;;30 rue des Je=C3=BBneurs;Paris;;FR-75011;France
email;internet:[EMAIL PROTECTED]
title:Web GIS developper
tel;work:+33 (0) 1 44 82 00 80
x-mozilla-html:FALSE
url:http://www.makina-corpus.com
version:2.1
end:vcard
_______________________________________________
Users mailing list
[email protected]
http://openlayers.org/mailman/listinfo/users
--
Gilles Bassiere
MAKINA CORPUS
30 rue des Jeuneurs
FR-75002 PARIS
+33 (0) 1 44 82 00 80
http://www.makina-corpus.com
begin:vcard
fn;quoted-printable:Gilles Bassi=C3=A8re
n;quoted-printable:Bassi=C3=A8re;Gilles
org:Makina Corpus;GIS
adr;quoted-printable:;;30 rue des Je=C3=BBneurs;Paris;;FR-75011;France
email;internet:[EMAIL PROTECTED]
title:Web GIS developper
tel;work:+33 (0) 1 44 82 00 80
x-mozilla-html:FALSE
url:http://www.makina-corpus.com
version:2.1
end:vcard
_______________________________________________
Users mailing list
[email protected]
http://openlayers.org/mailman/listinfo/users
