[Freegis-list] Re: Compressing GML

[Gabriel Roldán]

We did something like an implementation of a bxml codec. Just at the lower 
layer of functionality, that is, the codec itself, not a JAXP adapter.

We based our work on the same dataset that CubeWerx used  for demostration of 
its C based parser, though we wanted to go far than that parser, since it is 
very limited and does not complains with the BXML discussion paper in the 
sense that is unable to handle different char encodings.

So we used java nio classes and implemented our codec. Then found that the 
gain in parsing a bxml stream is considerable, as well as the reduction in 
content size. But encoding time isn't far better than using jaxp, since 
almost 80% the time is consumed by the caracter encoding classes.

Anyway, I'm just hoping to find the time to continue the development of the 
parser and integrate it with the geotools gml stuff to support encoding well 
known gml elements (mostly geometries) in an optimal packagins (foe example, 
encoding the coordinates as a real array of doubles or float instead of a 
long string), and may be finding a way of optimizing characted encoding at 
least for the most common used ones.

My impression: bxml would be a huge gain for WFS inter-communication, and my 
testings shows that at least at the extent I was able to test, the gain in 
bxml production is not so considerable, but in parsing a bxml encoded stram 
will be.

gabriel.

On Thursday 21 July 2005 13:46, Chris Holmes wrote:
> > I am curious if people out there have made any progress in the area of
> > compression/decompression of GML for transport. ( I recall a while
> > back someone complaining of GML’s verbosity, and others replying
> > that’s ok, you can always gZip it
)
> >
> > Our case: my people are testing all sorts of permutations of clients
> > seeking data from WMS and WFS, and are making a series of Excel charts
> > documenting what happens in each case, varying the number of
> > simultaneous users (they generate multiple user threads to attack the
> > server), the server characteristics (RAM, O.S.), and the data size as
> > retrieved. Among other things they are finding that retrieving a
> > several megabyte GML as generated by MapServer’s WFS, is not possible
> > under the generous 10 minute timeout limitation
with client and server
> > on machines in the same laboratory and connected via 100 Mbit switch.
> > However, when they fast-Zip a 100+ MB file (manually) they find that
> > it is reduced to about 5MB. So it would seem to be a good idea for the
> > server to do this, under certain circumstances.
> >
> > So, who is doing this? Is there code available?  How are we on the
> > issue of GML compression? Or on the occasional use of GML-binary?
>
> Yes, we wrestled with this in GeoServer for awhile.  Some said that it
> should always just be the http server that you set up in front of your
> WFS to deal with.  Like Daniel says, Apache is easily configured to do
> this, and then you can use a connector to tomcat, or whatever servlet
> container you like.  Browsers will transparently handle the requests.
> And then wfs clients could also be coded to do it at the level of http
> transport.
>
> In GeoServer we also support gzipped gml2 as an output format (use
> 'GML2-GZIP' for the outputformat param), and the gml production will go
> through a gzipping output stream.  Some thought it might be useful, so
> it's just an extra format.  No one's asked about this for awhile, but I
> think it should work.  We no longer advertise it in the capabilities
> document, because it breaks the CITE conformance tests, which is a bit
> annoying to say the least.  I think the schema can support additional
> output formats, but CITE only recognizes a certain subset.  Or at least
> that's what I recall, it's been awhile.
>
> Gabriel Roldan (cced) was the author of the capability, and he also
> looked into bxml encodings for GeoServer.  If I recall correctly it
> wasn't as big of a performance win as we were hoping.  He may be able
> to tell you more.
>
> But if MapServer is taking too long to generate the GML file, then I
> don't think gzipping on the fly will help - I assume your networks are
> fast and it's not the transport, but the making of the GML file.
>
> Chris
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/