[OpenLayers-Users] compressed and/or binary GML to make the client side happy

[Tim Schaub]

Hey-

darrepac wrote:
> thanks for this information and recommendation.
> Is there no way without going into geoserver?
> If parsing is not the problem, if I set correctly the bounded box of each
> feature, OL is smart enough to only threat the ones which are visible (and
> ignore the rest?)?
> 

As Chris mentioned, there are several bottlenecks - and you cannot 
really get around one of them: the browser parsing the whole document 
and constructing a Document object.  We (OpenLayers) don't even get to 
touch the data until this happens (you could fool the browser by 
misrepresenting the content type to avoid the Document creation, but 
you'd either have to know exactly how many characters to seek to in the 
string or you'd have to write a streaming parser yourself to deal with it).

So, drag your GML (uncompressed, the way the browser gets it before 
creating the Document) into Firefox.  Count the seconds that it takes to 
display a rendered DOM tree.  Check your memory usage.  All these are 
tolls that must be paid before we even touch the G part of your GML.

The parser can be made to ignore geometries (and other attributes of 
course) until they are needed for rendering, but I'm guessing that at 
4000 features in GML, by the time the data transfers and is parsed into 
a Document, your users will be getting pretty bored.

If you don't mind the wait (for the whole doc to be read as a Document), 
I like the idea of just-in-time geometry parsing, and would like to 
upgrade our parsers to do that.

Tim


> 
> 
> Christopher Schmidt-4 wrote:
>> On Tue, Oct 28, 2008 at 02:17:06PM -0700, darrepac wrote:
>>> XML is not the most efficient method to transmit data and, on the client
>>> side, when the application try to open the GML, it slows down heavily the
>>> machine and it takes age to render.
>> The parsing of the GML is unlikely to be the majority of the time here.
>> Keep in mind that all of that GML is parsed, and then turned right back
>> into XML to display in your browser (SVG is XML-based). In addition, the
>> way that OpenLayers works is to constantly update the DOM to change the
>> properties of that XML.
>>
>> In general, you can't display more than about 50 (IE) - 150 (FF2) - 500
>> (FF3/Safari3) vectors at once in a browser. Any more than that, and you
>> run into the rendering slowness that you're seeing.
>>
>>> I was thinking to compress or at least put in binary the GML file to be
>>> more
>>> efficient.
>> This would be significantly less efficient, since Javascript doesn't
>> have any real way to interact with binary data. 
>>
>> If you want to try a more efficient transfer format, I recommend
>> GeoJSON, which transfers in a format which is very lcose to the
>> browser's internal representation. However, with 4000 features, you're
>> still going to be completely screwed on performance. You really need to
>> look into rendering your data with a server: I recommend GeoServer at
>> this point for beginners, because it's relatively easy to get started
>> with.
>>
>> If you only need to show a few features at a time -- say, you don't mind
>> limiting yourself to 200 -- you could put the data behind GeoSErver or
>> some other WFS server, and serve with a maxfeatures setting. This would
>> limit the number of features displayed at once, and you can generally
>> choose the ordering (so you display highest population areas first, for
>> example). This would let you maintain your use of vectors, but limit the
>> performance headaches, with a "zoom in for more info" (to limit the area
>> of the map further, and therefore request fewer features).
>>
>> Best of luck,
>> -- 
>> Christopher Schmidt
>> MetaCarta
>> _______________________________________________
>> Users mailing list
>> Users at openlayers.org
>> http://openlayers.org/mailman/listinfo/users
>>
>>
> 


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.