writing lots of data to kml file (efficiently)

[ziashan]

My apologies if this has already been covered and my searches just haven't turned it up. Lets say i have 1000 lat,lon pairs with time stamps and i want to write them to kml as placemarks with a custom icon for each. If i understand libkml correctly, i need to:

1. construct 1000 coordinate objects
2. construct 1000 point objects (as parents to the coordinates)
3. construct 1000 timestamp objects
4. construct 1000 icon objects
5. construct 1000 placemark objects (as parents to all the above)
6. finally i can serialize the xml and write to a file

That seems like a lot of overhead to me. Once i create and populate a placemark object, i'd like to discard all of the children objects to free up the memory. But since everything is referenced by "smart pointers" all 4000 children objects have to hang around until the very end. Am i missing something? Do i need to just create arrays of pointers for everything, or is there a better way?

Thanks in advance for your insight.

[Joel Odom]

Your placemark holds pointers to the children, not copies, so it is
memory efficient.

> --
> You received this message because you are subscribed to the Google Groups
> "libkml" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libkml+un...@googlegroups.com.
> To post to this group, send email to lib...@googlegroups.com.
> Visit this group at http://groups.google.com/group/libkml.
> For more options, visit https://groups.google.com/groups/opt_out.



--
http://www.falconview.org/

[ziashan]

If the placemark held copies, i could discard the originals. Either way, that's still 4000 children objects hanging around. When i've generated kml by writing to a file stream, the data can be discarded as soon as the placemark is written to the file. Since libkml does the serialization at the end, it has to be held in memory. Perhaps it's little memory and just the price for ensuring valid kml. I was just wondering if what i described was the normal approach.

As a new user, it seems to me that libkml is better suited for parsing kml than generating it. The kmlconvenience namespace could use more creation classes, IMHO.

[Michael Ashbridge]

Yes, that's the normal approach. Like Joel says,  the xxxPtr objects are reference-counted smart pointers (boost::intrusive_ptr's) that significantly ease the burden of memory management. (If you really want to own the raw pointers you can .get() on those xxxPtr objects, but I wouldn't recommend it.)

On Tue, Oct 8, 2013 at 8:19 AM, ziashan <zia...@gmail.com> wrote:

If the placemark held copies, i could discard the originals. Either way, that's still 4000 children objects hanging around. When i've generated kml by writing to a file stream, the data can be discarded as soon as the placemark is written to the file. Since libkml does the serialization at the end, it has to be held in memory. Perhaps it's little memory and just the price for ensuring valid kml. I was just wondering if what i described was the normal approach.

As a new user, it seems to me that libkml is better suited for parsing kml than generating it. The kmlconvenience namespace could use more creation classes, IMHO.

--

[Brian Case]

ziashan,

it seems to me if this is a concern you should be working with multiple
kml files.

<Region>

like a super overlay does

Brian