Advertisements

MkrGeo

An original point of view

GIS

Content management in KML files

BalloonStyle placemark in Google Earth

Pic. 34 Our BalloonStyle placemark in Google Earth.

In my previous article, where I clarified the link management in the relation between Google MyMaps – .kml files – Google Earth and another way around. Now, as a continuation, I would like to bend down on content in .kml files. At first glance, it sounds simple, because each .kml file has content, written in XML language.
As long as you input any information into your .kml balloon, this is the content. Previously I discussed all possibilities to embed a graphic and linked stuff as content in .kml file.
In this article, I would like to focus mostly on text content itself, balloon styling and additional elements, that we can input inside the .kml file description, about which maybe you didn’t know yet.
First of all, I would like to mention, that KML Balloon can render both HTML and CSS language. With JavaScript is a more difficult situation, because the Google Earth API has been retired since December 2015, which results, that dialogue boxes cannot be created and some functions won’t work. It doesn’t mean, that JavaScript should be definitely ditched. There are still a lot of things, which are supported.
Before we will be seriously involved with this whole stuff I would like to start from basic ways of .kml content manipulation, as we can get through simple interactive map builders.

1. INTERACTIVE MAP BUILDER EDITORS

There are quite a few interactive map builders in the Web, but some of them are based on JavaScript API solutions, other ones don’t support .kml files. To be said I mostly getting around with Google MyMaps and Scribble Maps, from where these examples will come from.
Google MyMaps content editor is really poor. This platform neither supports links (at least directly, which was explained previously here) nor any styles. All, what you can input there is only a plain text.

Google MyMaps KML file content plain text

Pic. 1 An .kml file content edition options available in Google MyMaps platform.

Much better situation is in another one, the Scribble Maps, where you have got at least a basic tool kit for your content management in .kml files.
Scribble Map has a small interface, where next to the link or embed image/movie options you can obviously input the text, but moreover instantly change the placemark coordinates, set object shrinking when zoom (object is only faint in Google Earth) out or (what’s the most important) make an advanced edition. This is the thing, which I would like to mention then.
By clicking an advanced editing option you are being redirected to another, bigger toolbox, where you can customize your content.
This interface includes a few major things to manipulate your text. You can: make it bold, italic, bigger and coloured. On top of that, you can align the text or make some paragraphs. Looks amazing. Let’s go through some samples then.

KML content management in Scribble Maps

Pic. 2 Placemark description styling in Scribble Maps.

In the meantime I must mention, that next to the visual toolbox, the Scribble Maps allows you to make editions directly in HTML code. Unfortunately, the platform doesn’t support much HTML, as only the commands possible to use in visual mode, at least in the free version. Nevertheless it’s enough for some basic styling.

Scribble Maps HTML editor for placemark

Pic. 3 Scribble Maps HTML editor for placemark.

Scribble Maps font colour changes

Pic. 4 Scribble Maps font colour changes.

Scribble Maps text underline option

Pic. 5 Scribble Maps text underline options.

Scribble Maps text coloured and underlined

Pic. 6 Ready prepared and underlined text in Scribble Maps.

Scribble Maps HTML editor for placemark 2

Pic. 8 And all stuff how it looks in HTML code editor.

At the finish we can get pretty nice styled .kml file description as per below:

KML file balloon description made with Scribble Maps

Pic. 9 .kml file description made with the Scribble Maps interactive map builder.

All things above are basic and they will work, however, if you still want something more to do with your placemark description, then you must jump to serious editions.
Being honest I mean at least XML-based editions, through a relevant software such a Notepad++.

2. INPUT HTML ELEMENTS INTO PLACEMARK DESCRIPTION

Apart from a few basic HTML elements, which we can input via Scribble Maps interactive map builder, which obviously can be not enough, we have most of HTML codes, available to adopt inside the .kml file.

I will illustrate it on a single examples.
In example 1 we want to add up some table, where we place some basic information about the population of the town (Pic. 10, 11), adding up some very basic stylization too.

KML adding HTML table into XML code

Pic. 10 Adding a HTML table with simple CSS stylization into .kml file, where: 1 – stuff already done in Scribble Maps; 2 – CSS stylization; 3 HTML code with table.

Adding HTML table into KML file

Pic. 11 Adding HTML table into .kml file, Andernach town in Germany.

To be fair, the stylization is an inherent element of HTML code not only in webmastering but also in simple .kml file edition. In the picture above all stuff except the table underneath has been prepared in Scribble Maps. The main feature of HTML as coming from this interactive map builder is unfortunately very packed. It makes the code reading more difficult. Unlike to Scribble Maps I will show a clear and easily readable code.
Staying by tables I would like also to demonstrate an another way to get the data into .kml. This data is external and not in HTML code, so it must be manipulated first.
Let’s create a .kml file with weather data for New York. What we need is basic data, which we can get from Wikipedia (Pic. 12). Next, we must copy it into Excel or Google Sheets and save it in .csv file. Make sure, that cells where you input the data are formatted properly. Otherwise, you can get some sad surprises somewhere. (Pic. 13). I intentionally come round this issue, because it comes outside of this article purpose. Further process will be conversion from .csv to .html extension, possibly to do via ConverttoCsv tool (Pic. 14).  Afterwards, we should get a .html version of our data (crude table with weather datasets)(Pic. 15).

New York climate data Wikipedia

Pic. 12 The climate data for New York (Wikipedia.org).

New York weather data in Excel

Pic. 13 New York climate data from Wikipedia are now in Excel. Red boxes indicate errors caused by wrong default cell formatting in Excel .

New York climate data from Wikipedia converted to html

Pic. 14 Converting from .csv to .html in the tool.

New York climate data from Wikipedia ready for download in html

Pic. 15 The New York climate data from Wikipedia are already converted into a crude .html table, which we can download easily.

Once we download our data, let’s open in Notepad ++. At first glance, it won’t look small. I propose to leave it as it stands, select all and copy inside our [![CDATA]] space in .kml file (Pic. 16, 17).

New York weather data from Wikipedia now in Notepad++

Pic. 16 New York climate data from Wikipedia already as an HTML file opened in Notepad++.

New York weather data from Wikipedia in Notepad++

Pic. 17 New York climate data from Wikipedia now embedded in .kml file with some simple CSS styling, marked yellow.

After some simple styling, we can enjoy our informative .kml file in Google Earth (Pic. 18).

New York climate data from Wikipedia in Google Earth

Pic. 18 New York climate data now on Google Earth.

In the HTML code, we have really wide possibilities to fill up our .kml content. We can input images (also with description), tables, create buttons or even embed some external websites.

HTML code in .kml file

Pic. 19 Wider HTML and CSS code in .kml file, including i.e picture and displacement.

Truskavec map embedded into .kml file

Truskavec info in .kml file

Pic. 20, 21 An .kml file with information about Truskavec in Ukraine. Even Google Map can be embedded in the placemark description.

So, as you saw each examples. HTML is surely viable within .kml file description. HTML along with CSS and JavaScript language consists of front-end development, known with webmastering. These three languages are basically integral with each other if we want to create a good website. It is also translated into [![CDATA]] space, where these languages can built the .kml file description.

2. INPUT JAVASCRIPT ELEMENTS INTO PLACEMARK DESCRIPTION

As I mentioned above, some JavaScript codes are restricted in .kml file as a result of Google Earth Api retirement. However, we still can enjoy some simple solutions, tweaking up our .kml file functionality. One of the basic tools, that we can see in .kml balloon is clock (Pic. 22, 23).

JavaScript clock in the .kml file

Pic. 22 The .kml file description including JavaScript code, where: 1 – CSS basic stylization; 2 – JavaScript code (likewise CSS placed in ‘<head>’ zone; 3 – an HTML code in ‘<body>’.

Pen Y Fan with JavaScript clock

Pic. 23 JavaScript clock presented in Pen Y Fan .kml placemark in Google Earth.

In general, the .kml placemark content within [![CDATA]] command features a website-looking layout, divided into 2 major pieces: head and body. In the ‘<head>’, we put the stuff affecting for a whole .kml balloon appearance such CSS style or JavaScript code. In the ‘<body>’, the HTML content mainly.
When looking at the picture above, you can see the elements, which can annoy you. There is information about the direction, which is not always needed. In this moment we are entering into another way to customize a .kml content, through the ‘<BalloonStyle>’. I will describe it widely below. Now I would like to mention how to get rid of this information about direction. We must create a new space in our .kml file as per below (Pic. 24), making this stuff invisible for future (Pic. 25).

Input BalloonStyle into .kml file

Pic. 24 A place in our .kml file, where the ‘<BalloonStyle>’ space should be placed. As you may have noticed there is also the [![CDATA]] command, setting the text properties for a particular part of the .kml content (description).

BalloonStyle implemented into .kml file

Pic. 25 The implemented ‘<BalloonStyle>’ into .kml file results dissapearing the title and info about directions.

KML World time zones

Pic. 26 World time zones presented in .kml file (Barnabu.co.uk).

The clock function in JavaScript is the best to present World time zones in .kml. It has been already presented here and looks excellent (Pic. 26).
Another JavaScript appliance in .kml files can be a text twinkling, in order to draw someone’s attention (Pic. 27).

Javascript text twinkling in .kml file

Pic. 27 The JavaScript code (highlighted) causing the text twinkle in .kml file description, presented in Google Earth.

The JavaScript in .kml can come directly from the ‘<script>’ command, placed in the .kml file as well as from an external script file. It means, that some simple JQuery elements will work too (Pic. 28), although be careful with it, again! Google Earth API has been depreciated.

Javascript filterable table in .kml file

Pic. 28 Javascript code for filterable table, placed in .kml file, where: 1 – code embedded into the XML code; 2 – link to external JavaScript source.

If you want to see a result of my work, see this short video below:

All code editions, which I am showing you in Notepad++ you can make straight through the “description” label in Google Earth when your placemark has been loaded (Pic. 29).

Google Earth placemark edition

Pic. 29 The .kml placemark content edition straight in Google Earth software.

Remember, that your code in the Google Earth “description” label is not highlighted at all. It means that is quite easy to make a mistake, and what is worth, not easy to find it. So personally I would recommend you use some designated software instead, at least in order to highlight the code or some debug options.

3. WORK WITH THE BALLOONSTYLE

A BalloonStyle is tailored for bulk .kml file style customization. We can style our .kml file on basic and much wider way.
Basically the Balloonstyle requires to input a separate command, which doesn’t appear as a default in standard .kml file created by tools (like Google MyMaps). The code can look as per below:

<BalloonStyle>
<bgColor>ffffffbb</bgColor>
<text><![CDATA[
<font face=”Courier New”>$[description]</font>
]]></text>
</BalloonStyle>

I used this simple code in order to customize the .kml balloon about the World’s highest arc dam (Pic. 30, 31).

Inguri Dam XML code

Inguri Dam .kml BalloonStyle

Pic. 31 Basic information about World’s highest arc dam – Inguri Dam in Georgia.

In the result of this simple balloonstyle presented above, the colour changed and the font family remains the same for the whole content. This is a basic example of BalloonStyle edition.
For more wide purposes the BalloonStyle can be used likewise “Description”, which will make our .kml presence a bit better (Pic. 32-34). We gained an another frame with different colour, our Balloon layout, standard for all places included in this .kml file. Moreover, the “Description” field remains almost empty, which at same point can be important, about which more underneath.

.kml file baloon style code

Pic. 32 Our front-end stuff placed within the ‘<BalloonStyle>’ code.

Balloon style description in .kml file

Pic. 33 A highlighted ‘<Description>’ field with the most important stuff there.

BalloonStyle placemark in Google Earth

Pic. 34 Our BalloonStyle placemark in Google Earth.

4. SUMMARY – DESCRIPTION OR BALLOONSTYLE?

So I have shown you 2 ways of content management in .kml files. Both in the ‘<Description>’ and ‘<BalloonStyle>’ you can input wide front-end elements, which should work without the problem in Google Earth software.
Our the most curious thing at this moment is how it will behave when we take it everywhere i.e back to some interactive map builder or to Google Maps API. Will we enjoy our work? Or what important thing is to be found regarding these two major XML fields?
Checking the files in Google MyMaps, we can see that most of our work has been lost.  However is it the reason to worry about?
Google MyMaps has an interesting option. Each map created there has a “Data Table“, which is something like Excel spreadsheet data composed of 2 basic columns: a name of the placemark and its description.
It means, that we get a simple pack of the data, which can be further manipulated.
If we have data including our HTML or JS work, as before. It will look messy, and basically not really useful for the next job with data manipulation. Else we put everything into ‘<BalloonStyle’> instead, leaving only some important stuff in the description. Let’s compare our 2 jobs below (Pic. 35, 36).

.kml file description in Google MyMaps with data table opened

Pic. 35 One of my previous work, where I tested a JavaScript filterable table in Google Earth, unfortunately, doesn’t look good as a description in Google MyMaps.

.kml placemark description in Google MyMaps with opened data table2

Pic. 36 My job was done in <BalloonStyle>’ section with a piece of basic description information, now seen clearly in Google MyMaps.

As you see above, an HTML or JS edition in the ‘<Description>’ section doesn’t look good in Google MyMaps. The data table looks completely messy and rather not useful for further data manipulation, unlike to lower example, done in ‘<BalloonStyle>’ section. There basic information included in the ‘<Description>’ looks really fine and easy to work with it the future.
This is an important thing, which we should take into account at the very beginning of our work? Will we use our placemark somewhere else than in Google Earth only?
I am not going to highlight here a particular section as a better. It doesn’t mean, that input our whole stuff into ‘<BalloonStyle>’ is a better idea.
If your file is going to show some description with photos, links, some tables, etc it will be better to input it into the ‘<Description>’ space.
However don’t bother with interactive map builder now, which is quite poor and may not show your work properly. I prepared my work in GoogleMaps API in order to see the sense of my previous work.
My last example with ‘<BalloonStyle>’ development looks completely different outside of Google Earth (Pic. 37).

Google Earth vs Google Maps API placemark

Pic. 37 The ‘<BalloonStyle’> customized placemark in Google Earth lose all details in Google Maps API, apart from description content.

We’ve lost everything, converting our .kml file into Google Maps API.
Let’s try another one below (Pic. 38), developed both in ‘<BalloonStyle>’ and ‘<Description>’ fields:

Google Earth vs OpenstreetMap placemark

Pic. 38 A comparison of the .kml placemark content developed both in ” and ” between Google Earth and OpenStreetMap API.

The example above looks much better. We haven’t lost the content. We lost only style, set in ‘<BalloonStyle>’ section. All HTML code with the picture came through.

How about the placemark developed only in ‘<Description>’ field? Let’s see an example below (Pic. 39).  Lack of styling in Google Earth result lack of disappointment when our file is taken outside of this software.

Placemark description in Google Earth and OpenStreetMap API

Pic. 39 The .kml placemark developed only in ” field keeps all stuff when converted into OpenStreetMap API.

In the example above we can see, that all HTML along with CSS layout came through, which is good for us. Unfortunately, the CSS is not supported as well as HTML does. It can be seen especially when set some background colour in XML, which cannot be displayed in the API version.
JavaScript also doesn’t work in Google Maps API (Pic. 40).

.kml placemark with HTML table in OpenStreetMap API

Pic. 40 A .kml file with the filterable table in JavaScript, which doesn’t work in OpenStreetMap API, leaving untouched HTML table with CSS elements.

However, from our job, both HTML and CSS code is displayed.
To sum up this issue it’s up to you, where you want to place your placemark content, however, it will result in its further appearance in external places. If I would advise you something, then if you want to have your ‘<Description>’ data sorted for further manipulation such Google Sheets, SQL, etc. then is much better to do your work in ‘<BalloonStyle>’ field. By the other hand if you want to show some content externally, apart from Google Earth, then will be better to develop it within ‘<Description>’ field.

Mariusz Krukar

 

Links:

  1. KML Reference – description
  2. KML tutorial
  3. KML adding custom data
  4. KML styling and live data feeds
  5. Geoserver.org: KML styling
  6. How to convert to KML and style without loosing your mind?
  7. Customizing the waypoints in KML files
  8. W3Schools colour picker
  9. Announcing deprecation of Google Earth API
  10. KML Touring
  11. KML Balloon style example
  12. CSV to KML conversion
  13. Google Earth World time zones – Javascript in KML

Forums:

  1. KML layer custom icons
  2. CSS in Google Earth plugin
  3. HTML, CSS, JS embedded in Balloon
  4. JavaScript in KML ignored by Google Earth plugin
  5. Use JavaScript inside balloons in the Google Earth client
  6. Use Balloon style without creating empty balloons
  7. Text background colours in Balloon
  8. KML Balloon width
Advertisements

Theme by Anders Norén

Follow

Get the latest posts delivered to your mailbox:

%d bloggers like this: