[OpenLayers-Users] vector layers optimization?

Wed Oct 8 03:40:18 EDT 2008

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:gilles.bassiere at makina-corpus.com
>> 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
>> Users at openlayers.org
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gilles_bassiere.vcf
Type: text/x-vcard
Size: 368 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/openlayers-users/attachments/20081008/6f92c705/gilles_bassiere.vcf