Archive for category Google Earth

I’m waiting for FOSS4G…

… 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:

Marine disaster at Duke Point?  Maybe not...

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

1 Comment

KML Schema Rides Again

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:

Sammy in the sky with diamonds...

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?

4 Comments

Google Sky TNG?

I think UserFriendly’s got it right.

-J

No Comments

BC Electoral Boundaries Commission is Geo-Savvy

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:

Download Options for EBC-BC Geo

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.

EBC-BC Google Maps

The Google Earth representation allows you to see the boundary without attributes:

EBC-BC Google Earth

And the Shapefile version has the boundaries and all of the summary attributes (shown in FME viewer, link is to a zipfile):

EBC-BC ShapeFile

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):

EBC-BC Gerrymandering? :)

3 Comments

I Heart KML Schema!

Update: this information is now out of date because of improvements to the KML format in version 2.2. You can read about this in a later post and in Google’s great tutorial on extended data.

Recently, Chris over at FortiusOne has written a couple articles, focusing largely on the Schema tag in KML. One thing in particular from this article got me thinking:

Google Earth will display your custom fields in the markers that get displayed in a Schema-based KML file, but it’s still up to you to make a pretty-looking description if you want, and if you want to include some of the data in your custom fields, you’ll have to duplicate the information which isn’t ideal.

This certainly seems like a bit of a roadblock for the good old Schema tag. It really breaks the whole separation of content from style idea, which surprised me because this separation had been accommodated in other KML tags. So I started hacking… and found that this isn’t really a limitation. One word: BalloonStyle.

Using this tag, you can easily use Schema to transport relatively pure attributes, while pointing to style information located elsewhere in the document or, if you’re in the mood, in a different document entirely.

Here’s some data in a relatively simple schema:

 <Newt>
   <name>Sammy G</name>
   <styleUrl>http://www.jasonbirch.com/files/kml_schema_style.kml#newt_style</styleUrl>
   <Point>
     <coordinates>1.75,1.75,0</coordinates>
   </Point>
   <newt_id>36</newt_id>
   <newt_breed>Common Orange Slitherer</newt_breed>
   <newt_slime_factor>7.2</newt_slime_factor>
   <newt_tail_length>6</newt_tail_length>
 </Newt>

Which can be combined with the following BalloonStyle:

 <Style id="newt_style">
  <BalloonStyle>
   <text><![CDATA[
    <h1>$[name]</h1>
    <table>
     <tr>
      <td>Breed:</td>
      <td>$[newt_breed]</td>
     </tr>
     <tr>
      <td>Tail Length:</td>
      <td>$[newt_tail_length]</td>
     </tr>
     <tr>
      <td>Slime Factor:</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>
   ]]></text>
  </BalloonStyle>
 </Style>

To give you the fully separated content/style shown below:

Sammy G Meets World

Now, I think that’s downright cool. I can have my cake and eat it too. If you want to see this example live in Google Earth ™, just click on the image above. You can also view the source of the content document, or of the style document. I’ll leave it as an exercise for the reader to determine whether this technique can be used with more complex tags than SimpleField, such as SimpleArrayField and ObjField :)

I am aware of one other application (Safe Software’s FME) that is using the Schema tag to pass around attributes, and have really liked the idea ever since I first saw it in Rebecca Moore’s anti-logging KML file. It’s easy to use, doesn’t require external documents, and combined with other KML goodness allows you to pack styling around with your fully attributed data.

There is a nasty rumour floating around that Schema has been deprecated. It isn’t listed as such in the KML docs yet, and I certainly hope that it isn’t too late to ensure continued support for this handy tag from Google.

-J

7 Comments