Google Maps with Google Earth Plugin



Fig 1 – Google Map with Google Earth plugin –

Google announced a new GE plugin for use inside Google Maps:
http://code.google.com/apis/earth/documentation/

This is an interesting development since it allows Google Earth to be used inside a browser. Google’s Map object can be programmed using their javascript api for user interaction control which was not available inside standalone Google Earth. The api documents have plenty of examples but the very simplest way to use the Google Earth Plugin is to simply load their plugin api javascript like this:

<script
	src="http://maps.google.com/maps?file=api&v=2.x&key=**************"
	type="text/javascript">
	google.load("earth", "1");
</script>

Then add a Map Type G_SATELLITE_3D_MAP to the Map control in the initialization code.

function initialize() {
	if (GBrowserIsCompatible()) {
		map = new GMap2(document.getElementById("map_canvas"));
		map.setCenter(new GLatLng(39.43551, -104.91207), 9);
     		var mapControl = new GMapTypeControl();
     		map.addControl(mapControl);
     		map.addControl(new GLargeMapControl());
     		map.addMapType(G_SATELLITE_3D_MAP);
	}
}

This adds a fourth map type, “Earth”, to the control shown over the Google map base.

Fig 2 – Google Map with Google Earth plugin showing map overlays

Now a user can switch to a GE type viewing frame with full 3D camera action. Unfortunately the Maptype control is hidden so returning back to a Map view requires an additional button and piece of javascript code:

function resetMapType(evt){
	map.setMapType(G_NORMAL_MAP);
}

In order to show how useful this might be I added a button to read kml from a url:

function  LoadKML(){
	var geoXml = new GGeoXml(document.getElementById('txtKML').value);
	GEvent.addListener(geoXml, 'load', function() {
		if (geoXml.loadedCorrectly()) {
			geoXml.gotoDefaultViewport(map);
			document.getElementById("status").innerHTML = "";
		}
	});
	map.addOverlay(geoXml);
	document.getElementById("status").innerHTML = "Loading...";
}

Now I simply coded up a servlet to proxy PostGIS datasources into kml for me and I can add mapOverlays to my hearts content. If I want to be a bit more SOA it would be simple to configure a Geoserver FeatureType and let Geoserver produce kml for me.

My LoadKML script lets me copy any url that produces kml into a text box, which then loads the results into the Google Map object. With the GE plugin enabled I can view my kml inside a GE viewer, inside my browser. By stacking these overlays onto the map I can see multiple layers. The javascript api gives me pretty complete control of what goes on. However, there are still some rough edges. In addition to overwriting the map control that would allow the user to click back to a map, satellite, or hybrid view, there are some very odd things going on with the kml description balloons. Since I’m using IE8beta I can’t really vouch for this being a universal oddity or some glitch in the IE8 situation. After all IE8 beta on Vista really does strange things to the Google Map website making it more or less unuseable.

Here are some items I ran across in the little bit of experimetation I’ve done:

  • plugin loading is slow and doesn’t appear to be cached
  • returning from Earth view requires javascript code
  • click descriptions are only available on point placemarks
  • the balloon descriptions show up only sometimes in an earth view
  • There appears to be a limit on the number of kml features which can be added. Over 5000 seems to choke

The rendering in the new Google Earth plugin view is quite useful and provides at least a subset of kml functionality. This evolution distinctly shows the advantage of a competitive market. The Microsoft Google competition significantly speeds the evolution of browser map technology. Microsoft is approaching this same type of browser merged capability as well with their pre announcement of Virtual Earth elements inside Silverlight. 3D buildings, Street view, Deep Zoom, Photosynth, Panoramio …. are all technologies racing into the browser. Virtual parallel worlds are fascinating especially when they overlap the real world. Kml feeds, map games, and live cameras coupled with GPS streams seem to be transforming map paradigms into more or less virtual life worlds.

GIS savvy developers already have a wealth of technology to expose into user applications. Many potential users, though, are still quite unaware of the possibilities. The ramp up of these new capabilities in the enterprise should make business tools very powerful, if not downright entertaining!

More Google Earth – Time Animation



Fig 1 – Google Earth Time Animation tool visible in the upper part of the view frame –

I was out of town for a trip back to Washington DC the last couple of weeks, but now that I’m back I wanted to play with some more KML features in Google Earth 4.3. One of the more interesting elements offered by KML inside Google Earth is the use of timestamps for animated sequences.
KML offers a couple of time elements:

<TimeStamp>

        <TimeStamp>
	<when>2002-09-27T21:44:41.087Z</when>
        </TimeStamp>

<TimeSpan>

        <TimeSpan>
	<begin>2002-09-27T21:44:41.087Z</begin>
                <end>2002-09-27T21:45:41.087Z</end>
        </TimeSpan>

By attaching a time stamp element to kml rendered elements it is possible to make use of the built in Google Earth time animation tool. I have a table of GMTI events for a few simulated missions that is ideal for this type of viewing. The time stamp deltas are in the millisecond range and work best as timestamp elements.

KML time formats are defined as dateTime (YYYY-MM-DDThh:mm:ssZ) which translates to a Java formatter:

SimpleDateFormat timeout = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");

In KML the T char delimits date from time, while the Z indicates UTC. In my case using simulated mission data I am more interested in delta time effects than actual time.

By adding the appropriately formatted <TimeStamp> to each <Placemark> from the GMTI data set I can create a KML data stream with the time animation tool enabled.

<Placemark id="gmti_target.80916">
        <TimeStamp>
          <when>2002-09-27T21:00:06Z</when>
        </TimeStamp>
         <description><![CDATA[<table border='1'>
           <tr>
             <th colspan='8' scope='col'>gmti_target</th>
           </tr>
           <tr>
             <td>targetid</td>
             <td>missionid</td>
             <td>dwellid</td>
             <td>name</td>
             <td>time</td>
             <td>the_geom</td>
             <td>classification</td>
             <td>dwellindex</td>
             <td>trackindex</td>
             <td>geom</td>
           </tr>
           <tr>
             <td>78840</td>
             <td>16</td>
             <td>135417</td>
             <td>gh1_v4bt.cgmti</td>
             <td>75606708</td>
             <td></td>
             <td>Unknown, Simulated Target</td>
             <td>1476</td>
             <td>0</td>
             <td>SRID=4269;POINT(-111.89313294366 35.1604509260505 2180)</td>
           </tr>
           </table>
           ]]></description>
         <LookAt>
            <longitude>-111.89313294366002</longitude>
            <latitude>35.160450926050544</latitude>
            <range>700</range>
            <tilt>10.0</tilt>
            <heading>10.0</heading>
         </LookAt>
         <styleUrl>#Stylegmti_target.634</styleUrl>
         <Point>
            <coordinates-111.89313294366002,35.160450926050544</coordinates>
         </Point>
      </Placemark>

For this experiment I utilized a mission with a relatively small number of gmti targets in the 6000 point range. The time to load is still a bit slow even with only 6000 points to load. In order to boost performance I switched from a simple kml stream to a zipped kmz stream for the servlet response.·····

Response.setContentType("application/vnd.google-earth.kmz");
ZipOutputStream out = new ZipOutputStream(response.getOutputStream());

This helps with bandspeed latency by reducing the data stream from 5Mb to 0.25Mb, however, the biggest latency on my system is the Google Earth load rendering rather than the download. Im using a medium 5Mb DSL connection here on an Intel Core2 Quad CPU Q6600 2.39Ghz. The download of the kmz is about 5sec but the Google Earth ingest and rendering, complete with blanked viewport, is around 50sec.

Once rendered the point icons are available for time sequence animation. Google Earth furnishes a built in tool that automates this process. The time tool includes option settings for adjusting speed, time range view, a setting to keep or discard points from the beginning, as well as repeat, stop, or reverse selection for end of time range event. The animation is helpful for visual analysis of target association. The tool provides step and slider views as well as animation.


Fig 2 – Google Earth time animation

The built in tools provided by Google Earth are quite helpful. Virtual Earth or WPF tools can be used for time sequence as well but require writing the necessary client javascript or C# to step through the set of elements in sequence. Having the tool already available makes simple view animation much easier to create. The potential for customization and interaction is a bit limited, but many applications are well served by the prebuilt viewing tools provided by default in GE. The large terrain and imagery infrastructure behind Google Earth is a real asset to viewing. Additional high resolution imagery can be added as GroundOverlay elements for enhancing specific gmti view areas.

For classification and analysis the simple view capability is somewhat limited. What is needed is a mode of selection to group and classify point data to create track associations. This requires more interactive events than afforded by GE. WPF is more difficult to work with, but the ability to add a variety of selection tools and change classification interactively may make the effort worthwhile from a GMTI analyst’s point of view. Any background imagery, terrain, or mapping layers need to be added to the WPF UI so there would be quite a bit more effort involved.


Fig 3 – Google Earth time animationviewed from above

GMTI is only one of a number of time sequence vehicle tracking data resources. The increasing use of GPS and fleet tracking software makes these types of data sets fairly common. The use of timestamp animation is a nice addition to the viewing capability of historical tracks, of course live tracks generally retain a history tail as well, so a live tracking databases could also make good use of this timestamp element. NetworkLinkControl refresh events can keep the track synchronized with the live data feeds.

The lack of interactive UI capability in Google Earth limits its use for operator classification and analysis. However, GE is just one viewing possibility. A UI system using a FOSS GIS stack such as PostGIS, Java, and Geoserver can be accessed in a number of ways through the browser. For example one browser tool could view the data set through a WPF UI, which allows operator reclassification and filtering using a variety of selection tools, while simultaneously a GE viewer with a NetworkLinkControl refreshed from the serverside backing datastore can be open from the same client. One aspect of the power of Browser based UIs is the ability to access multiple heterogeneous views simultaneously.


Fig 4 – Multiple browser views of gmti data source – WPF xbap UI and GE Time animation