How feasible to extract data from KML/KMZ files

Question

We have a large bunch of KML files, they are basically global cable maps. In our company they are wide-spread and everybody uses them with Google Earth.

Now there is an interest to extract information from these files, e.g. Cable Lengths. With Google Earth extracting Cable Length is a very tedious task because you need to look at each tiny segment's height profile. So I started writing a software to read those files, problem is: the quality of most of those KML/KMZs is really low. Sometimes linestrings contain too many or even duplicate coordinate-sequences. You can even see that in Google Earth.

So question: does it make sense to try to parse these KMLs to calculate cables' total length? Or is this too much asked from KML format?

Answer 1

You can convert kml to other GIS formats such as shape using ogr2ogr, part of gdal. If there are too many points or double points this should not really cause problems: calculating a length is a fast progress.

Although they work with any GIS program, calculating the actual length is not that straightforward: most of them only work with projected data, and if you have global cables they should work with unprojected data as well.

BTW: a google search turned up with this tool to measure lengths in kml files: http://freegeographytools.com/2007/determining-google-earth-path-lengths

Answer 2

If you can come up with a set of rules, such as vertices much travel in the positive X direction, or distance between vertices must be less than some tolerance, I can forsee a way to accomplish your task using the osgeo.ogr python module.

pseudo-code:

break line into a list of points
iterate over list, check against rules, remove bad vertices, maybe
reconstruct line
add a field, with a flag to indicate vertices were removed
export to any ogr format you want

repeat for all lines, in all kmls (and/or unzipped kmzs)

Answer 3

I was about to add a comment but apparently I have not enough reputation:-)

I'm not sure how you are writing your program. You may consider using XPATH ans XSLT transformation as KML is essentially an XML file. You can calculate standard deviation to see if there are apparent glitches with entered data. If you go XML way, XSLT processor will take care of iterations, and you'll need to implement just transformation rules.

While 300km segment is quite long, is your current approach projection aware? Depending on the projection, you may get slightly different results... though not 5000 km :-)