Archive for category Google Earth
KML Goodness from the FME User Conference
Posted by Jason Birch in FME, Google Earth on March 13, 2008
The FME User Conference is always great value. You get to see interesting presentations, learn about new technologies, and talk to bright people from all across the industry. This last point is probably the most important to me. Mixed in with other great conversations, I got to chat at length with Ed Katibah about SQL Server Spatial, and Don Cooke told me I dressed too well to be a neogeographer :)
It is also the best place to corner an FME developer. I managed to grab Tom Weir, Safe’s KML guru, and go over some of the changes in KML support with FME 2008. During a presentation on the first day of the conference I had included an “easter egg” where I spoke about how to enable active mouse-overs in KML using FME. To my chagrin, after a couple minutes with Tom I realized that my advice was not exactly best practice, and with FME2008 becomes downright ridiculous.
Here’s the before shot from my slide deck (zipped workspace):
And the after shot once I applied what Tom showed me (zipped workspace):
Obviously, the FME 2008 press release should read: “KML Support in FME: Now with 50% less fat!”
KML FME has been generating multi-geometry for information points for quite some time, so that cuts most of the data wrangling out to generate the info point and merge the features into multi-geometry. And FME 2008 will automatically generate StyleMap elements for you if you follow a couple sneaky tricks.
First, when you create each KMLStyler, set its name to the style ID you want it to receive:
And second, on your geometry set the kml_target_style_normal and kml_target_style_highlight attributes to the IDs that you created in the KMLStylers:
That gets my embarrassment out of the way, but doesn’t even begin to touch on the extent of KML 2.2 support in FME 2008. Another issue that I have written about is extended data or schema support, and I am happy to say that FME deals with this. Attributes are stored in your output KML as extended data by default, and it is easy to generate a BalloonStyle template. Here’s my first take on this support, which does a great job of separating data from presentation (zipped workspace):
And a quick look at the new basic editor which is included in FME and used for modifying BalloonStyle templates:
Which gives us this KML output (source).
There is a going to be a lot more to the KML 2.2 support in FME 2008, including generation of image pyramids for PhotoOverlays, but I’ll leave it to you to explore those on your own.
-J
I’m on National TV :)
Posted by Jason Birch in Google Earth on October 30, 2007
OK, maybe not the same nation as y’all, but it’s still pretty cool.
This morning, a segment on CTV’s Canada AM called "Canadians on the Cutting Edge" featured the work I’ve done with Google Earth for my employer, the City of Nanaimo.
(click image for video, or follow this link: http://tinyurl.com/2oshr7 )
I’m still playing on my 15 minutes of fame from some articles in the Vancouver Sun and Globe and Mail (paid content, but there’s an excerpt on Carsons Post). At the time, local papers picked it up, as well as local broadcast and cable TV.
I think that this puts me over the 15-minute mark, so hopefully it’s over now :)
-J
Circular Reference: Google Earth and YouTube
Posted by Jason Birch in Google Earth on October 11, 2007
I wonder how wrong the infamous 80% rule is. It seems like more and more content which has not been thought of as geospatial is getting added to the world’s most popular geo-browser.
Here’s a funny shot, it’s me and my boss talking about Google Earth in a YouTube video, inside of Google Earth. Don’t look too close or you’ll get sucked in by the infinite recursion :)
Sorry for jumping on the “everyone posts about Google announcements” bandwagon… I usually try to avoid it.
-J
I’m waiting for FOSS4G…
Posted by Jason Birch in Google Earth on September 21, 2007
… surrounded by workshop hardware and getting a bit antsy, so thought I’d post about something totally unrelated during my coffee break. The most recent imagery for my city in Google contains this gem:
At first glance, it appears that the ferry has done a nose-dive. Having taken those old beasts every weekend for eight months when I was working in Surrey, if there was no loss of life I’d be cheering… but in this case it’s just some creative editing on the Google data integrator’s part. They clipped the new (2006, 10cm) orthos so that the old (2003, 70cm) stuff would show in that area. The feathering width created an interesting effect though :)
-J
KML Schema Rides Again
Posted by Jason Birch in Formats, Google Earth, Tutorial on September 8, 2007
I just read the news about the new ExtendedData tag in KML 2.2. With one mighty stroke of the pen, Google has saved the Schema tag, and my sanity along with it!
What does it mean? Basically: KML can still act as a self-contained data exchange format, while getting rid of the nasty part of the original <Schema> tag that defined new elements on the fly.
To illustrate the changes, I’ll take you through my previous example of Sammy G Newt. Here he is in glorious colour under the new ExtendedData system:
The first part of this new system is defining the schema; you can see how to do this here:
<Schema name="newt" id="newt_schema">
<SimpleField name="id" type="int">
<displayName><![CDATA[<b>ID</b>:]]></displayName>
</SimpleField>
<SimpleField name="breed" type="string">
<displayName><![CDATA[<b>Breed</b>:]]></displayName>
</SimpleField>
<SimpleField name="slime_factor" type="double">
<displayName><![CDATA[<b>Slime Factor</b>:]]></displayName>
</SimpleField>
<SimpleField name="tail_length" type="int">
<displayName><![CDATA[<b>Tail Length</b>:]]></displayName>
</SimpleField>
<SimpleField name="relative_id" type="string" />
</Schema>
Looks pretty basic, right? Not much has changed in the Schema tag, except that has name and id attributes, and there is now an optional displayName element for each field.
OK, now that you’ve got the schema, you want to create a BalloonStyle that takes advantage of that schema. Here’s mine:
<BalloonStyle>
<bgColor>ffffaa90</bgColor>
<textColor>ffffffff</textColor>
<text><![CDATA[
<h1>$[name]</h1>
<table>
<tr>
<td>$[newt/breed/displayName]</td>
<td>$[newt/breed]</td>
</tr>
<tr>
<td>$[newt/tail_length/displayName]</td>
<td>$[newt/tail_length]</td>
</tr>
<tr>
<td>$[newt/slime_factor/displayName]</td>
<td>$[newt/slime_factor]</td>
</tr>
<tr>
<td colspan="2"><img src="http://www.jasonbirch.com/files/jason_small.jpg?id=$[newt/id]" /></td>
</tr>
</table>
<a href="#$[newt/relative_id];balloonFlyto">Please visit my Sister!</a>
]]></text>
</BalloonStyle>
Can I hear the ah-ha’s?
There are a couple neat things here. First, it’s pretty obvious that if you want the data, you use the format $[nodeName/fieldName], and if you want the display name you use $[nodeName/fieldName/displayName]. Look close at the <a> tag though… I am using an identifier stored in the extended data area to link to a different record in the same KML file, using its ID. This will be great for “previous” and “next” applications among other things. This could just as easily have been used to point to a different Placemark within a remote KML file.
Now that we have a schema and a style, we can create some some content that references these:
<Placemark id="sammyg">
<name>Sammy G</name>
<styleUrl>#newt_style_boy</styleUrl>
<ExtendedData>
<SchemaData schemaUrl="#newt_schema">
<SimpleData name="id">36</SimpleData>
<SimpleData name="breed">Common Orange Slitherer</SimpleData>
<SimpleData name="slime_factor">7.2</SimpleData>
<SimpleData name="tail_length">6</SimpleData>
<SimpleData name="relative_id">phyllisk</SimpleData>
</SchemaData>
</ExtendedData>
<Point>
<coordinates>1.75,1.75,0</coordinates>
</Point>
</Placemark>
So, what’s special about this? Two things. First, I didn’t magically create any new KML tags on the fly. Second, you can see that I am referencing both the style and the schema by URL. This means that you can either store all of your schema, markup, and code in one file, or you can break them out into as many individual files as you would like. You can have a look at my completed example here:
One File:
Three files:
Anyway, this last-minute addition to KML 2.2 has made me pretty happy. If you have any questions or comments about it, be sure to chime in on the official thread.
-J
P.S. Another thing that I noticed in perusing the documentation is the ability to use atom tags to link from a KML entity back to its web representation. This is important because it adds another vector for Google to use when assigning relevance to KML files in spatial search. I’m not an AtomPub expert, but I would imagine that it could also be used to allow a smart client to update features on the fly?
-
You are currently browsing the archives for the Google Earth category.
User Map
Recent Comments