KML Optimization: Tip # 1 - I need Namespaces?

Rule of thumb: if you do not need, do not use!
This rule is the principle that one should always keep in mind when coding a KML.
So, this is the way we started talking about optimizing content for rendering in Google Earth, Google Earth and Google Maps Plugin.
In this article we'll talk about namespaces and why we should use or not in the KML.

What is a namespace?
Namespace is a way of qualifying XML elements and attributes in order to avoid conflict with elements in XML using the same name. This qualification is the addition of a prefix before the name of element or attribute.

Why there is namespace in KML?
Using Namespaces in KML allows Google to add extensions to the Standard (OGC KML), without compromising the processing of old KMLs, including allowing the use of the same attributes with new values allowed which are not covered in the original specification. An example is the element that after update of Google Earth that gave support to view the ocean, was limited and the use of namespace enabled the element can have new values, without compromising the old versions that did not support.

I must use namespace or can I omit?
It depends.
I recommend you remove the namespace only at the end of the process of developing a new KML, as this will prevent you from receiving warning messages from Google Earth if you do use one feature that uses some extension.

What is the meaning of each namespace in KML?
Let's look at the namespaces we can find in a KML. Below is an excerpt from KML generated by Google Earth version 6.0.1.2032 (beta).

• xmlns = "http://www.opengis.net/kml/2.2"
  This is the default namespace, which means that every element of the file that is not prefixed, will report to this namespace.
• xmlns:kml = "http://www.opengis.net/kml/2.2"
  This namespace is the de facto standard, where all the elements that make up the language are defined in a schema (XSD file).
• xmlns:gx = "http://www.google.com/kml/ext/2.2"
  This namespace refers to the extensions that Google has been doing to KML, after standardization of language (OGC KML). This statement says that all new elements will be prefixed with "gx".
• xmlns:atom = "http://www.w3.org/2005/Atom"
  This namespace refers to elements that can be used to describe the KML generated content authoring.
• xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"
  This namespace refers to element that can be use to geocode in Google Maps (currently not used in Google Earth).

So if we do not use any extension and we use values that are within the OGC KML specification, we can omit these declarations in the XML so that it becomes:



or being more radical:



That's it, folks! Good coding!

Honey, I Shrunk the KML !

In this post I will initiate a series of articles to provide tips on how to optimize content rendering (KML) viewed in Google Earth, Google Earth Plugin and Google Maps.
KML format is XML-based, so it tends to be very verbose and therefore the more features are generated in this format, the higher tends to be the final size of the generated content.

Why optimize?

1. To reduce bandwidth consumption
   In a corporate environment where the server that provides the data and Google Earth are on different computers on the same network, save on bandwidth consumption is a good practice to enable up to other computers on the same network also consuming the same data and not create an impact in other applications.
2. To reduce processing time
   A non-optimized KML consumes more processing (and hence the computer) than an optimized. This processing is reflected in the speed with which information is updated on Google Earth / Maps.
3. To reduce battery consumption (mobile)
   Less processing will result in less battery consumption, therefore, more autonomy for the battery

What we will see:

• KML optimization
• Optimization for display in Google Earth
• Optimization for display in Google Earth Plugin

Stay tuned !