It has happened to everyone who uses GIS. You're minding your own business, enjoying a strong cup of coffee and happily opening your shapefiles and saving them into proprietary formats so that only those who are 'in the club' can open... oh wait, I mean saving your files into a flexible and friendly
database when a co-worker or client sends you a KML file... and you have the same well-practiced response:
Because you know more often than not, it won't work and you'll spend the rest of your day futzing around with it, only to have moderate success with elaborate joins or editing in a text-editor. Or you could just hit delete and pretend you never received it...
In the past I've had limited success with
converting from KML to SHP after the 1.8 GDAL update BUT I never understood the underlying issue (or why it - seemingly - worked randomly). I recently received a KML file that threw this error when opening in QGIS:
So I tried GlobalMapper, which opened the file but didn't preserve any attributes just the geometry and then ArcMap (because what better way to store your data than a layer file....) and that too only offered a "
" - ArcMap's cousin to the lovely "Segmentation Violation" - so informative. So I turned to the University of Google and discovered
post by Dane Springmeyer (who I find frequently ferrets out the weirdest little issues).
He describes an issue with the encoding of KML files as they get exported where the KML claims it is encoded in UTF-8 but is actually encoded in iso-8859-1 (or Latin-1). If you have files with unknown - or inaccurate - encoding, he also shares a tool to identify the likely encoding called
. Once you know the encoding you can re-encode the KML with
and it will open properly with all the attributes properly preserved. Here is the re-encoding applied to my KML file:
Dane's simple explanation and the easy to use
library might just save you hours of tinkering and frustration. That way you can get back to work fighting the good fight against data silos...