GeoSpatial Training Services will be releasing a new instructor guided, Internet based course in the near future.
Most local government agencies have large collections of GIS data in various formats including shapefiles, geodatabases, grids, tins, CAD, and others. Sharing this data with colleagues and the public is often a challenge. Before distributing data you have to answer many questions. Does my end user have the appropriate software to view the data? Do they know how to use the software? Do they understand how to add the data into the viewer? Should I create a web mapping application for end users? Converting your existing GIS data to a Google Earth KML format offers many advantages in terms of data distribution to end users and it also offers many new ways of presenting information. This course, geared specifically for local government GIS specialists, will teach you techniques for converting your datasets, creating compelling and interactive Google Earth displays, and sharing the data with your end users.
- Register your entire GIS group for $199.00 (up to 8 people)
- This course makes extensive use of Arc2Earth. You will be provided with an evaluation copy of Arc2Earth to use during the course
- Exercises and data will focus on typical local government datasets
- Benefits of Converting ArcGIS Data to Google Earth Format
- What Google Earth Version Should I Use?
- KML: The Language of Google Earth
- Tools for Converting ArcGIS Data to Google Earth
- The Easy Stuff: Convering Points, Lines, Polygons, and Graphics
- The Not So Easy Stuff: Displaying Spatial Analyst Grids, Aerial Imagery, and Other Image Files
- The Hard Stuff: Techniques for Displaying Large Datasets
- The Fun Stuff: 3D Data Displays, Geography with a Time Element, Info Balloons with HTML, Images, and Video, Guided Tours
- Eye Candy: Creating Legends and Logos
- Google Earth without an Internet Connection
- Techniques and Tools for Sharing Google Earth Data with End Users
I just wanted to share a cool way that you can display your existing KML files inside a Google Maps application using the GGeoXML class from the Maps API. Many organizations have pre-existing KML files that were created for use within Google Earth, and the GGeoXml Maps API class provides a really simple means for also displaying this data in Google Maps as a GOverlay. Although we are specifically using this class to read a KML file in this example it is worth noting that this class can be used to read any XML file.
In this example, we’re displaying an auto-updating KML file containing Global MODIS Hotspots provided by the Fire Information for Resource Management System (FIRMS) at the University of Maryland. FIRMS integrates remote sensing and GIS technologies to deliver global MODIS hotspot/fire locations to natural resource manager and other stakeholders around the world. FIRMS is funded by NASA and builds on Web Fire Mapper, a web mapping interface that displays hotspots/fires detected by the MODIS Rapid Response System and delivers near real-time hotspot/fire information to international users.
FIRMS provides several auto-updating KML files for regions around the world. Any of these files can be loaded into Google Earth. What I’ve done is take the Continental USA KML file which is updated every four hours (as are the other files) and dynamically loaded the file into a simple Google Maps application using the GGeoXML class in the Maps API.
Take a look at this example and then I’ll describe how this is done within Google Maps.
From a code standpoint, the Maps API makes this a really easy task which can be done with only a few lines of code. To see the full code for this simple Maps application you can simply right click the web page and click View –> Source. I’ve posted the relevant code below. The initialize function is called when the web page loads. We create a new instance of the GGeoXML class and pass in a parameter to the constructor which contains a pointer to a KML file located on a remote web server. In this case we’re pointing to the Continental USA KML file located on the FIRMS web server. Once we’ve created an instance of GGeoXML we then add it to the map using the addOverlay( ) method on the GMap2 class. In between we have some additional Maps API code which creates the underlying map, centers the map, and adds the map controls.
As you can see, using the GGeoXML class to add pre-existing KML files to your Google Maps application is quite simple and very useful. Even the descriptive balloons contained within the KML file have been ported to info windows in Google Earth. Click one of the fire locations to return specific information about a particular fire.
For more information on the Google Maps API or GeoSpatial Training Services please see our e-learning course entitled “Google Maps For Your Apps” or our “Google Maps Developer Bundle” which is currently on sale as part of our 3rd Year Anniversary Sale.Read Full Post | Make a Comment ( None so far )
The <Camera> element, new to KML 2.2, provides a way to define your observer’s viewpoint in terms of position and viewing direction, and is a child element of any <Feature>. Features can include Placemark, NetworkLink, Folder, Document, PhotoOverlay, ScreenOverlay, and GroundOverlay. In previous KML versions (2.1 and earlier) a similar element, <LookAt> was used to define the placement and orientation of the camera.
Differences Between <Camera> and <LookAt>
Let’s take a look at these two elements to determine how they differ.
As you can see from these figures the two elements look quite similar, but they have some fundamental differences. Let’s start with the <longitude> and <latitude> child elements. In <LookAt>, these elements refer to the point the camera is looking at, whereas in <Camera> these elements refer to the virtual camera (eye point). This is an important distinction. <LookAt> specifies the view in terms of the point of interest while <Camera> specifies the view in terms of the viewer’s position and orientation. Similarly, the <altitude> element refers to the altitude of the point of interest for <LookAt> whereas it refers to the distance of the camera from the earth’s surface for <Camera>.
There are some additional differences between the two elements. For instance, <LookAt> contains a <range> child element that specifies the distance in meters from the point of interest specified by <longitude>, <latitude>, and <altitude> to the LookAt position. The <Camera> element does not contain this particular element. In addition, the <Camera> element also provides additional functionality for controlling the tilt of the camera view. The <tilt> element in <Camera> can be any value between 0 and 180 which gives you the ability to tilt the camera above the horizon into the sky, whereas in <LookAt> you are limited to a value between 0 and 90. In either element, a value of 0 indicates that viewing is from directly above, while a value of 90 indicates viewing along the horizon. Because <LookAt> can contain only values between 0 and 90 you are limited to viewing from directly above through a horizontal view. As I mentioned above, the <tilt> values for <Camera> can range from 0 to 180 with values greater than 90 indicating a view that is pointed above the horizon toward the sky. Finally, the <roll> element on Camera gives you the ability to rotate the camera around the Z axis and can contain any value between -180 and +180 degrees.
Now we’ll take a look at a few examples that illustrate different <Camera> settings taken from the San Diego Convention Center and Petco Park. You can download the file containing all examples here. You’ll want to make sure you turn on the 3D buildings in the Google Earth layers panel before opening the file.
This first example shows a <Camera> with a heading of 90 degree (East) and a tilt of 90 degrees (toward horizon). Remember that headings can be any value between 0 (north) and 360. The default is 0 or north. The Camera in this case is placed at an altitude of 100 meters.
In the next example, we set the <tilt> value to 0 which will set the camera to look straight down toward the earth. We’re also setting the <heading> to north and the <altitude> to 500 meters.
Now let’s try something a little different. In this next example, we’re going to take a look inside Petco Park from the viewpoint of a major league baseball platter in the batter’s box. In this case we are setting the <tilt> to 110 which points slightly up into the sky. We’re also setting the altitude to slightly above sea level.
Finally, we’ll examine the <roll> element which rotates the camera around the Z axis with values ranging from -180 to +180. Sticking with our Petco Park example, assume that the pitcher has thrown a wild pitch and hit the batter! The batter has subsequently fall down. Ouch! Using the <roll> element with a value of 45 which will roll the camera to the left we can simulate the viewpoint of the batter who is now lying on the ground.
Hopefully these examples have helped illustrate how you can use the Google Earth <Camera> element to control the user viewport and using your imagination you can come up with some creative ways to use these features in your analysis of geographic data.
For detailed information about KML, Google Earth, or Google Maps please see the following e-learning courses provided by GeoSpatial Training Services.
- Mastering KML in Google Earth
- Dynamic Google Earth Applications
- Introduction to the Google Maps API
- Integrating ArcGIS Desktop and Google Earth
In this post I’m going to cover the topic of creating compelling Google Earth description balloons for your placemarks. These descriptive balloons are a fantastic way of communicating information to your users, and can include HTML, text, images, videos, hyperlinks, and pretty much anything else that you would like to portray to users. Because of the diversity of content that can be included in a description balloon, they tend to make excellent teaching tools, and have been used as such by National Geographic, Greenpeace, Global Heritage Fund, Earthwatch, and many others.
KML for Balloons
We’ll start with some basic information about how these balloons are created in KML. Descriptive balloons are attached to Placemarks in Google Earth, and are displayed when clicked. The creation of a description balloon for a placemark is accomplished with the use of the <BalloonStyle> KML element. A <BalloonStyle> is a ‘type of’ or child of the <Style> element so it is common practice to define a balloon style within the context of a <Style>. Therefore, you could have something like this:
Notice that we are assigning an id of ‘sn_ywl-blank’ to the <Style> element. This is just a descriptive name that we’ll user later to refer back to this content. Inside <Style> we have our <BalloonStyle> element which contains the details of our balloon. For simplicity, we are only using the <text> element in this case. Now let’s cover the details of what can be included inside <BalloonStyle>.
The <BalloonStyle> element has a number of child elements that are used to control the content and display characteristics of the items including in our descriptive balloon. The background color <bgColor>, text color <textColor>, text <text>, and display mode <displayMode> can be used within <BalloonStyle>. The background color and text color elements are self explanatory, but the <text> element in particular deserves more attention.
The <text> element contains the content that will be displayed in the balloon. In the event that you do not specify any text, Google Earth will draw a default balloon with the feature name, feature description, links for driving directions, a white background, and a tail that is attached to the point coordinates of the feature. But we’re really not interested in the default behavior since we are pursuing the creation of informative, compelling description balloons.
Inside the <text> element you can embed HTML along with various entities that are used refer to a child element of the placemark. These entities include $[name], $[description], $[address], $[id], $[Snippet], and $[geDirections]. An example is in order here to more clearly explain this. In the code example below you’ll notice that the <text> element contains a $[description] entity.
What this means is that the description contained within the <description> element of a placemark will be substituted in this place and thus allowing for unique content associated with each placemark. This description can contain HTML, hyperlinks, images, and videos.
For example, in the image below I’ve right clicked on a placemark and selected Properties. The Description tab displays the content of the <description> tag inside a placemark. Click here to see the actual file. What you’re looking for is the <description> tag inside the <Placemark> element. You should also look for the <styleUrl> element toward the bottom of the file. This element contains the text ‘#sn_ylw-blank’ which is used to point back to the <Style> element that we defined earlier.
As I mentioned above, there are a number of other entities that you can add to the <text> element. The same concept applies for these entities. Each of these entities can be used to obtain the information stored in the corresponding element found on the placemark.
One other point should be made here. When embedding HTML inside the <text> element you can use a CDATA section to ensure that the parser will ignore your markup characters. Between the start and end of a CDATA section, all character data is passed directly to the application without interpretation as you can see in the example below.
At this point we’ve covered the basic elements that you’ll use to create descriptive balloons. However, if you’re like me and have little to no graphic design skills you’re probably wondering how to go about creating attractive content for your balloons. Fortunately, Google has provided a number of templates that we can use as a starting point. You can make copies from these templates and then add in your own text, images, and other content.
You can’t update the content of your description balloons in Google Earth so you’ll need to use a text editor or an HTML editor such as Dreamweaver or NVU. You can copy the HTML from the templates into your favorite editor, edit the content as necessary, and then replace the existing template code.
Other Cool Stuff – Adding YouTube Videos
In addition to being able to customize your description balloons by adding text, images, and hyperlinks you can also embed a YouTube video into your balloon. This Google Outreach tutorial will walk you through the process of adding YouTube videos to your descriptive placemark balloons.
The Global Awareness folder inside the Layer panel contains many examples of compelling placemark balloons that you can use as a guide when you begin developing your own content.
For detailed information about KML, Google Earth, or Google Maps please see the following e-learning courses provided by GeoSpatial Training Services.