KML javascript utilities

Have you ever wondered what time a particular image was captured? Google Earth does not show times, only dates. We noticed in the Google Earth Enterprise documentation that ‘Acquisition date’ only accepts a date and not a time. We assume that Google’s equivalent software for Google Earth has the same limitation.

So, we wondered how easy it would be to tell the time based on shadows in the imagery. Google Earth has the option to show the sun, and if you are lucky, you can adjust the time until the sun lines up with a shadow. However, Google Earth does not allow you to look upwards except in the Flight Simulator, so if the sun is too high in the sky you cannot get it in the view.

[ Update: Frank pointed out to me that you can look up using the ‘eye’ tool in the centre of the compass. I am so used to my 3D connexion mouse that I forget there is any other way to navigate.]

Also, accurately lining it up is tricky.

Note that the time on the ‘time’ toolbar appears to be shown in the computer’s ‘local time’. So the above image was captured at about 1:15 am CAT (UTC +2) which is 11:15 pm UTC or 4:15 pm in California (where the image was captured). (We didn’t check that for daylight savings time complications).

We thought it would be fun to write a tool to calculate time based on shadow angle. As a bonus, the shadow length can tell you the height of the object. We found some open source code here that was created for the ‘Suncalc.net’ website. The code isn’t ideal as it converts time to the sun’s angle above the horizon and azimuth whereas we need the reverse, so we run it for each minute of the day and find the closest match. To use it, first switch to ‘historical imagery’ and find an appropriate image and some shadows. Draw a path in Google Earth from the base of an object to the end of its shadow. Use only two points in the path as only the first two points are used by the code. Next, right-click on the path and select ‘Snapshot View’. This stores the date from the historical imagery time bar in the path. Make sure you selected the appropriate date on the time bar first. Now save the path, or a collection of such paths, as a KML file. Upload the file below, and it should show a table listing the approximate time the image was taken in UTC and the estimated height of the object. Unfortunately, we do not know of an easy way to convert time to the correct time zone based on latitude and longitude. Using the tool below for the location in California shown above, we got 11:06 pm UTC, and a height of 14 m for the street light.

 
Ideally, do a number of shadows in the same image for greater accuracy. We found variations of over 10 minutes due to the difficulty of accurately marking the shadow angle.

St George Wharf, London, UK.
Image captured on 2015-10-08 at approximately 11:01 am UTC. The tallest building measured 182 m based on its shadow. Using Google Earth Pro’s 3D measuring tool and 3D imagery we got 179 m. According to Wikipedia it is 181 m.

As usual, let us know in the comments if you find any bugs or have ideas for improvements.

We maintain a map of the 3D areas in Google Earth. This is achieved with the help of GEB readers who send in KML outlines of new areas. However, we often receive outlines that are not ideal and need some manipulation before inserting into our KML file. We have created a number of scripts that help us combine various combinations of Polygons and Paths to deal with most situations. But, there are still some cases where manual intervention is required. Possibly the most tedious task is when a Polygon or Path needs to be split into two. In Google Earth, this requires duplicating the feature with copy/paste, and then deleting half the points in each copy. For features with a large number or points this can take a while.

So, we decided to make a simple tool that splits Polygons or Paths.

For best results, just save from Google Earth a single Polygon or Path that you wish to split as a KML file then upload it below. It should show the feature on the map. If there is more than one feature in the KML then click on its name in the left hand column. It should then highlight the vertices. If it is a Polygon, click on a vertex to split it at that point and convert it into a path. Click any point on a Path to split it into two Paths. Click ‘Save’ to download the result as a KML file.

Load

Save

 
If you submit KMLs of new 3D areas, please follow the guidelines found here. Essentially, the ideal format is a single Polygon for independent new areas, Paths for extensions, only covering the new areas and only on the outer edge.

[ Update: 2017-02-04 Updated the code to also handle MultiGeometries. ]

It is often useful to be able to get Google Earth placemarks into Excel (or other spreadsheet application or even a database). One way to do this is to save your placemarks as a .KML file (do not use .KMZ) then rename the file to .XML. Then it will open in Excel. However, it will typically need quite a lot of cleaning up after that. So, we thought it might be useful to have a simple converter that takes a .KML or .KMZ and extracts all the placemarks (points only, ignoring polygons, paths and other features) and converts it to csv for easy import into Excel or other application. So, here it is:

Convert

 

It only extracts the placemark name, description, latitude and longitude.

If you need other fields, or features, or encounter any bugs, please let us know in the comments.

To convert the other way (Excel to Google Earth), the easiest method is to use Google Earth Pro’s import feature described here. Another more complicated technique can be found here.

Our KML map of 3D areas has been steadily growing in size as new areas are added. We have considered converting it to KMZ format, which is the compressed version of KML files. KMZ uses standard ZIP compression and in many cases provides significant compression ratios. In our case it would shrink our KML file by over 60%. We have held back because this would mean changing the link to the file and as most users access it via a network linked KML we would also have to notify them to re-download the original KML with a new link. There are workarounds to this problem, so it might be worth doing. The other downside is that it adds an extra step to the process of updating the file as we would have to convert it to a KMZ file before uploading it.

Because of the above complications we have been giving some thought to other methods of making the file smaller. One thing we have noticed is that Google Earth saves KML files with an unnecessary amount of precision for latitudes and longitudes. It typically saves latitudes and longitudes using 16 significant digits. If you configure Google Earth to use decimal degrees then edit a placemark in Google Earth, it only actually shows 5 decimal places.

So how many decimal places are actually needed? We calculated that rounding to five decimal places results in a maximum error of just under a metre. Rounding to six decimal places gives an error of less than 10 centimetres. 14 decimal places gives an accuracy of less than a nanometre. Given that most Google Earth data such as altitude data or even image alignment can be off by many metres, having nanometre resolution in your KMLs is just wasting space. For our KML file five decimal places should be more than enough.

As you can see below, the results were quite impressive. Simply discarding unnecessary decimal places reduces the file size by almost half. We also show the effects of using the KMZ format.

We thought that other people with large KML files might find the idea useful. So, below is a JavaScript tool that will take a KML file and reduce the precision of the latitudes and longitudes.

Notes:

• The current version only reduces precision in placemarks, polygons and lines, it does not affect some other KML elements that include latitudes and longitudes.

• To achieve the reduction of precision the code parses the KML and recreates it using our in-development KML library, so we can’t guarantee that it will properly handle unusual KML elements. If you use it, double-check that the resulting file still has everything in it that you require, and let us know in the comments if you encounter any bugs.

• Unnecessary white-space is also removed which makes the file smaller but less human-readable.

Precision: (decimal places)

Reduce precision