In this thread, I would like to describe a swift method, which allowed us to make some changes within the .kml files. I am focusing on the names of columns inherited from the .shp files, although the described method can be applied for other texts and even some values too. What is most important, we can make bulk changes within a multitude of .kml files without the programming at all.
I can’t conceal, that this article is mostly an answer for the shapefile filename character limit (especially if you want to use your data in Google Earth), which can’t be bypassed. Saving our job as the .shp file restricts all the field names to 10 characters only. It also results in shortened names of fields for any other file type saved from this shapefile layer.
Firstly let’s have a look at how our problematic columns could look like yet in the QGIS data attribute table (Pic. 1).
Within the cut text fields, we can find some of them, for which we still know what’s going on. Anyhow, even in this case they might don’t look right enough if we want to use them externally after saving it as the .kml file.
After saving our .shp file as the .kml file ad opening it, we can see very restricted information in our balloon, driven by the 10 characters limit set earlier at the ESRI shapefile step (Pic. 2).
The quick alteration of our field names can be done in Notepad ++ software, which is able to open and edit the .kml files, what was mentioned several times before.
When Notepad ++ opened and our .kml file loaded, we can see all our field names populated. It depends on our area size, but I am convinced, that you will have more than 1 set of these text fields. Each set corresponds to one single placemark visible both in QGIS and later in Google Earth (Pic. 2). If you, for instance, have 20, 30, or even 100 placemarks in the area, these sets are replicated accordingly. I am assuming, that you got all this data i.e. from the .csv file, where all of them were bound as a big table and finally were transferred to QGIS thereafter. If that was so, then this solution will be very quick for you.
In the Notepad ++, you should see how it looks. All our field names have been bounded in the <SimpleField></SimpleField> tag. They repeat roughly across our .kml file down to the end (Pic. 3). As discussed earlier, these descriptions are the same.
Before I start to explain to you how to change these names quickly, I would like to mention, that this method will also work if your other .kml files are pretty much the same. If, for example, you have a huge project, which includes analog data from at least a few separate areas (and separate files effectively), probably these field names are generic for all the areas. In this case, we can change them across all the .kml files at once! In order to do this, we should open all our working areas in the Notepad ++. It can be done quickly by selecting all our .kml files from the folder and simply drag them to the Notepad ++, where the last one of them in order will be populated next to other ones that appeared as tabs (Pic. 4).
Now, since you have them all opened, you can start bringing back the original texts for all the field names.
Regardless of the .kml file opened right now, you should click Ctrl+F, and from the populated pop-up window toggle “Replace” mode. Next, you are typing the name, you want to alter. Here I would advise you to not include the quotes. Just select the name string, which is included within the quotes. The text fields you concern about, applies not only to the <SimpleField></SimpleField> tag but also for the <text></text> including the <![CDATA]> stuff, and finally the naming table, where quotes not occur. Including quotes in our replacing step might make our .kml file corrupted, because some names will be affected and some of them not, making the discrepancy within the whole file code. If you have set the proper string, then click the “Replace All in All Opened Documents” option (Pic. 5).
Just a single click on this button can resolve one of your issues, which you probably have at least several. Afterward, the name of your string has changed. Meanwhile, 2 other things are noticeable. First of all, all your files populated in the program as the tabs have already changed the “Save” icons. They were highlighted in order to alert you, that the new changes occurred for these files. Another thing, probably easier to spot is the general information about the total number of strings changed (Pic. 6). It obviously applies both to all the same names that occurred throughout the opened file as well as the other files being included in the Notepad ++ application.
To prevent from changing another, similar strings accidentally select “Match whole word only” as shown above (Pic. 6). However in my opinion it shouldn’t happen, as you can read about it below.
Now, if you are still unsure, you can toggle between some other files already opened in Notepad ++ and see the result. It should be the same across all your files provided (Pic. 6).
When you are on the way to making all these changes, there are still things, about which we should remember. First of all, you should be cautious when encounters some symbols like “&“. Some of them might be not accepted. In turn, Google Earth will throw an error (Pic. 7).
The error might have also other reasons, but in this case, it definitely comes from the wrong symbol provided (Pic. 8).
We must carefully read, what line the problem applies to. If it was 14 (as in my case), then we should fix the issue in line 14 as shown below (Pic. 9).
Another prevention from an error such as this is checking the general file encoding, which should be always UTF-8.
Another issue might be caused by a comma, especially when it falls at the end of our current text field.
The operation is pretty much the same, but we have to remember not to include any additional options. Since we have been using the “Match the whole word only” till now, we should untick it. The tool will cover our whole string containing also the accompanying symbols. In turn, we can carry on our way of replacing the text fields as easily as we can (Pic. 10).
For our situation, when we decide to keep the “Matching a whole word only” the quickest approach is by toggling our search mode to “Extended” (Pic. 11), but it won’t solve our issue, as the comma will still appear at the end of our new name (Pic. 11).
So, finally, I would advise stick to the approach described earlier. The “Matching a whole word only” option you should tick again afterward, in order to avoid some unforeseen changes throughout the whole .kml file, if some similar texts occur.
However, as the example shows we shouldn’t worry so much about the text field repeat across our former data attribute table column. The shapefile restriction prevents this. If, for example, we have some repeatable strings in the effect of the cut, we effectively have our text field description squeezed down to 8 characters only. The last two characters in this event will be reserved for the order number across a whole our <SimpleData></Simpledata> group as shown below (Pic. 12).
After a dozen or so amendments, we are finally getting the result. There are no cut text fields anymore, as most of them were superseded in Notepad ++. It was left only a few, where this operation wasn’t needed (Pic. 13).
You can also see the effect in Google Earth (Pic. 14).
Exactly the same situation applies to all the files you opened and edited simultaneously in Notepad ++.
Obviously, the method I have shown you can vary across individual situations. The search mode in Notepad++ is a well-built feature, where you can i.e. remove commas from all your strings, replace them with some regular expressions, and so on. They can be applied in the situation when you need to change some values instead of the text fields. Possibly I will explain it to you in the future on the basis of a different exercise. The solution presented in this article should help you manage quite quickly by bringing back the original naming of your text fields. What is more important, you can deal with it without any programming knowledge. Remember, that it’s only an exemplary approach, which can be varied in relation to the situation we found ourselves in. Nevertheless, you are aware, that solution such as this is possible. I hope, that it will solve the problem of reduced text strings for you, taking into account that your data is going to be used in Google Earth.
- Notepad ++ user manual – searching
- Advanced Find & Replace in Notepad++
- Notepad++: A guide to using regular expressions and extended search mode
- Notepad++ – Replace with Regular Expression
- Error: Open of file “filename.kmz” failed: Parse error at line x, column y : not well-formed (invalid token)
- Choosing & applying a character encoding
- Notepad++AdvancedSearch.txt (including the In Selection” option)
- Why transparency options in find-and-replace dialog?
- not well-formed(invalid token) – reasons? – Google groups
- how to fix google earth failed: Parse error at line 62934, column 43: not well-formed (invalid token
- Error parsing KML with accented characters non-local files
- Parse error – Google Earth – Invalid token