Archive for the Google Earth Category
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
Related posts
… 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
Related posts
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?
Related posts
What do electoral boundaries and geography have in common? Lots, of course, but we rarely see this side of redistricting publicly exposed. This has changed drastically in British Columbia with the launch of the latest official Electoral Boundaries Commission website.
Despite the complexity of two distinct sets of boundaries, they have risen to the geographical challenge. On the BC-EBC website you can find the proposed boundaries and supporting information available in multiple formats, including Google Maps, Google Earth, and good old Shapefile:
Visiting the Google Maps link for my home riding takes you to a search interface showing the district outline and some basic information on population, area, and divergence from the provincial average. Be careful with this app, it’s pretty memory-intensive.
The Google Earth representation allows you to see the boundary without attributes:
And the Shapefile version has the boundaries and all of the summary attributes (shown in FME viewer, link is to a zipfile):
This is a GREAT job. Congratulations Daniel Hirner and crew, and to BC-EBC as a whole for supporting this kind of transparency!
Now, I just need to find a source of historical voting by postal code, and I’ll know the results before the voting even starts
-J
P.S. I think I spotted some gerrymandering (just kidding):
