search

PiRSquared17 / libkml

Automatically exported from code.google.com/p/libkml
Other
0 stars 0 forks source link

Better large file support for KMZ #145

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The practice of serializing KML trees to large strings before writing to
disk is (1) inefficient and (2) very bad when the KML tree is sufficiently
large. Is it not unusual for our users to produce KLM files in excess of
20MB, which caused the creation of some unfortunately large strings. To
remedy this I wrote my own serializer that streamed the tree to disk
directly, bypassing the intermediate string (though this means I lost some
of the nice stuff your built-in serializer does like flattening empty
tag-pairs into a proper XML single-tag). This has greatly improved the KML
output's speed & memory footprint, but unfortunately KMZ is proving to be a
larger problem.

The trouble is that there is currently no way to stream a KML tree into the
zip file. I will probably end up cobbling something together from the
source of libkml's zip_file.cc & kmz_file.cc but it'd be nice if when you
passed a KmlFilePr or ElementPr to the KMZ API if it didn't immediately
convert those into a (potentially large) string and then write that out.
Furthermore, you can't specify the serializer you want to use for that step
of the process.

So to sum what this long-winded feature request is asking for:

1. Some way to stream the Kml tree directly into the ZIP/KMZ file.
2. Ability to specify the Serializer when writing something to KMZ

The former could be implemented through some variation of the latter, if an
abstract Serializer class that was provided the pointer to the internally
created 'zipFile' pointer.

Original issue reported on code.google.com by ajpatter...@gmail.com on 15 Apr 2010 at 8:50

GoogleCodeExporter commented 9 years ago 
r823 introduced a kmdom::SerializeToOstream
(there is also a kmlengine::KmlFile::SerializeToOstream

Yes, this does not address KMZ directly, but may
help enable it assuming an ostream-compat KMZ
streamer is written.

At the very least this improves performance of writing
the KML to an fstream by about 2-3x vs serializing to
string and then writing to KML file.

Changing this to an enhancement request for a KMZ ostream

Original comment by kml.b...@gmail.com on 6 May 2010 at 9:08