merging KML and KMZ files into a single KMZ

840 views
Skip to first unread message

David J. Burger

unread,
Jan 18, 2008, 4:03:29 PM1/18/08
to KML Developer Support - KML Server Side Scripting
I am attempting to write server side code that allows the user to
select several KML and KMZ files and then download a single KMZ file
that merges all of the selected files together. My strategy has been
to write a doc.kml file with NetworkLinks in it pointing on the
included files. When a KMZ is chosen for inclusion I unzip the KMZ
and write it into a directory structure within my new KMZ. So say
they have selected one KML file and one KMZ file to download as a
single KMZ file, the zip structure will then end up looking something
like this:

doc.kml
nested/file0/some.kml
nested/file1/doc.kml
nested/file1/files/image.png

Here the root level doc.kml file has network links pointing at the
other two KML files. some.kml was an individual KML file and was
placed in nested/file0. Within nested/file1 the contents of a KMZ
have been unzipped and resulted in writing out nested/file1/doc.kml
and nested/file1/image.png.

I can open this resultant KMZ file in Google Earth and everything
works fine. The content of the included KML and KMZ files is visible.

The problem comes when I then try to save this file from within Google
Earth. Google Earth will seem to flatten out the file to a structure
like this:

doc.kml
files/some.kml
files/doc.kml

and will throw away the nested resource image.png. Thus the file is
no longer correct.

I haven't been able to find the definitive guide to what constitutes a
valid KMZ file format but according to this page:

http://code.google.com/apis/kml/documentation/kml_21tutorial.html

"you can arrange the files in any structure that seems logical to you"

I find it strange that Google Earth is able to read my file correctly
but then destroys it when you try to save it from Google Earth. Any
advice on this matter would be appreciated.

ManoM

unread,
Jan 19, 2008, 1:37:33 PM1/19/08
to KML Developer Support - KML Server Side Scripting
Hi David,

Could you upload a copy of the KMZ file to the File section of this
group, so that we can try to replicate the problem?

ManoM

David J. Burger

unread,
Jan 19, 2008, 6:31:22 PM1/19/08
to KML Developer Support - KML Server Side Scripting
Ok, I've uploaded merged_before.kmz and merged_after.kmz.
merged_before.kmz is the KMZ file my application produces and it
consists of two KML files and one KMZ file that have been merged in a
single file. If you zoom to Axtell, KS you will see placemarks in the
northwest and northeast corners of the small town with a red cross
image in the southern area of the tiny town. merged_after.kmz is the
result of me opening merged_before.kmz and then saving it from within
Google Earth. The file is viewable as expected in merged_before.kmz
and is messed up in merged_after.kmz.

Andy Mitchell

unread,
Jan 30, 2008, 2:51:24 AM1/30/08
to KML Developer Support - KML Server Side Scripting
Agreed. The same thing happens for me.

I found a partial workaround until Google Earth is fixed. I saved the
file as merged_before_v2.kmz.

The changes are:

a) store all of the subordinate documents (northeast.kml,
northwest.kml, cross.png) in the /files directory. Google Earth
appears to save NetworkLink objects in .kmz's only to /files.

b) keep any styles in the subordinate documents. For example, David
has a style in a subordinate called "sn_cross" that references
cross.png. Keep that style.

c) create a "fake" style in the top-level doc.xml file that mimics the
subordinate style. For example, create a style called "xxx" in the
top-level doc.xml that looks the same as "sn_cross". The only
difference is that it should point to files/cross.png instead of
cross.png. If you do not do this step, Google Earth will not save the
cross.png file to the new .kmz file when you save the NetworkLink
objects.

Note: I tried to move the styles to the top-level doc.xml and simply
reference them from the subordinate .kml files. That would save some
of the pain/kludge of the workaround. I couldn't get it to work. I
tried referencing the style as ../doc.xml#sn_cross. I didn't spend
much time on it, though.


The other workarounds I tried were:

1) one of David's root images is stored in a /files directory. When
Google Earth flattens the merged_after.kmz, the sub-files are created
in /files. I wondered if Google Earth took the image /file. I
renamed it to /filesxxx. Did not make a difference.

2) I removed the intermediate /network folder. That moved /file0, /
file1, and /file2 up a level. Did not make a difference. It still
flattened into /files.

3) The top level kml file is called doc.kml. One of the subordinate
files is also called doc.kml. I renamed the subordinate file to
sub.kml. Did not make a difference.

4) I opened doc.kml. Assigned an id to each <NetworkLink> tag. Added
a <name> to each NetworkLink. Didn't make a difference.

5) I tried saving from My Places. Didn't make a difference.

6) I recreated the file from Google Earth. I created NetworkLinks to
the files on the hard drive. Google Earth stored them in the /files
directory in the kmz file.

7) Recreated the .kmz with all files in the /files directory. When I
saved, the cross.png file was lost.

8) I added an image tag (img src="../images/cross.png") to one of the
placemarks. I saved all three NetworkLinks as a kmz file. The
NetworkLinks saved in the /files directory. The image did not save.

9) I saved the individual Placemark (not NetworkLink) with the
cross.png image as a kmz file. Both the file and the image were
saved. The cross.png image saved in the /files directory.

10) I saved a single NetworkLink node for that same placemark as a kmz
file. Only the Placemark was stored in the /files directory. The
images file did not save.

11) I moved the cross.png style to the top document, doc.xml. When I
save the root, all of the NetworkLinks save to /files. The cross.png
file also saves to /files. However, the style does not work/show in
the subordinate NetworkLink object.

I'm using Google Earth 4.2.205.5730 on Linux.
Reply all
Reply to author
Forward
0 new messages