Random Markers: KML

Showing posts with label KML. Show all posts

Friday, August 12, 2011

Using gx:altitudeOffset to raise polygons during a KML Tour

During the keynote Tuesday at Esto es Google, I showed a demo in Google Earth demo. In the demo, Polygons showing the boundaries of the states of Mexico were raised to relative heights based on their population. The KML is uploaded here if you want to take a look. Basically, I got the boundaries from Natural Earth Data, and then wrote a quick Python script (it's not worth posting here) that helped me create a KML which updated, over 10.5 seconds, the altitudes of the polygons based on the population. I got the populations from Wikipedia. is a Google extension to KML that allows you to say "Hey, change the altitude of this whole polygon by X meters" without having to update each coordinate in the element. By specifying that the takes place over a period of time, you get a nice raising effect. And since they are extruded to the ground, you get a 3D bar chart effect. I also move the camera around so you can see different perspectives and polygons that might otherwise be hidden. I have 3% battery life, so I won't post a screenshot, but you can see if you open up the KML file and play the tour.

Friday, June 3, 2011

Hacking Google Earth to show Earth Interiors

At the Smithsonian today I showed off Declan de Paor's classic interior of Mt. Fuji which uses time animation and SketchUp models to show half Fuji sliding out to reveal the interior cone. I mentioned this to Declan and he pointed me to his recent use of Mars in Google Earth to represent the core of the Earth, and building on top of that. Pretty cool. Here's his more complete write-up.

Wednesday, February 9, 2011

JSON in KML Templates

Since Google Earth 5.0, the description balloon has handled pretty close to full JavaScript. There's some interesting things you can do with this. In this example, I'm showing a very basic use of JSON using KML balloon templates.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <Style id="testStyle">
      <BalloonStyle>
        <text><![CDATA[
          <script type="text/javascript">
             function loadData(){
               var foo = $[foo];
               var myObj = foo.myData[1].value;
               document.getElementById("example").innerHTML = myObj;
             }
           </script>
           <body onload="loadData()">
             <div id="example">test</div>
           </body>
          ]]>
        </text>
      </BalloonStyle>
    </Style>
    <Placemark>
      <styleUrl>#testStyle</styleUrl>
      <ExtendedData>
        <Data name="foo"><value>{"myData":[
          {"value":"1"},{"value":"50"}]
          }</value></Data>
        <Data name = "bar"><value>23094</value></Data>
      </ExtendedData>
      <Point>
        <coordinates>0,0</coordinates>
      </Point>
    </Placemark>
  </Document>
</kml>

Balloon templates are designed to allow you to use a single <Style> element for all or a set of your <Placemark;gt; elements, and then just insert <Feature> specific data into the template. Named <Data> elements inside a <ExtendedData> element provide name/value pairs. However, this can be a little flat. You can put JSON elements inside the <value> element (a child of <Data>, which gives you a lot more flexibility.

The good folks at Secorra provide ObsKML, an ocean observations format, using this technique.

Tuesday, June 15, 2010

Techniques for protecting your data

I was asked in the comments in this post: Maps to KML?, to talk about techniques for protecting your data in Google Maps applications. I'm finally getting around to that.

First off, let's just say that like any part of the web, it is probably impossible to totally protect your data that is published on a Google Map. People can always get access to it at very least by just viewing the data, which you want, and making notes. Screenshots, viewing source, intercepts, and other techniques can be used by the truly ambitious. True data privacy in a completely public page is an oxymoron. Note, I'm not saying privacy on the web is bad or not possible, but we're talking here about displaying data. As long as it's displayed, someone can get at it.

That being said, there are steps you can take to make it harder to get at, to make people work at it.

The most important thing you can do is avoid hard coding any information into the page. That should be fairly obvious, but many people fall into the trap. That means:

Don't have any code in your JavaScript that uses a specific Latitude/Longitude pair, an address, or anything of that nature.
Use calls to server resources to plot only the data necessary to display at that moment. Try to verify the origin of the requests to prevent people from scraping. Generating your data on the fly prevents someone from getting all your data at once.
Obfuscate/compile your Javascript code to make it harder to read.

You can also rasterize your data, or turn it into image overlays. There's a lot of techniques for doing this. This talk by John Coryat is a couple of years old, and was oriented to Maps API V2. However, in it he discusses many techniques that are applicable to V3.

Rasterization makes it difficult to extract the data directly. It can also increase your performance in some cases where you have lots of data.

If you're working with KML, you can distribute the KML to only trusted people to load in their Google Earth instances, but this is subject to trusting them. Any KML used in a Maps API application will be easily findable by someone who can get passed any obfuscation you have.

That's all I've got. Feel free to post any additional techniques in the comments.

Friday, May 21, 2010

Geo Highlights from Day 2 of Google I/O

Wow, Day 1 at I/O was such a big day Geo, it would be hard to top it. But there were some amazing gems. Check out these highlights:

Styled Maps! Probably the biggest news of day 2. Maps API V3 now gives you the option to style your maps. Don't like golden highways and green forests? Change it! Check out our announcement for more details and links.
Matt Lowrie gave a great talk on the SketchUp API and using SketchUp.
Josh Livni and I previewed a whole bunch of additions to the Earth API and a new KML extension. In particular, Earth API now has control over the time slider, and better balloon handling. Now, you can preserve your JS and Flash in the balloons. In KML, we previewed the Track extension, which will allow you to assign multiple way points to a model or point and move it around, rather than recreating them with multiple Timestamps.
Finally, and this was actually announced on Wednesday, you can now add a FusionTable layer to a Maps API V3 app, right from the API.

It's really exciting to see all this. We're closing the loop on a lot of developer requested features, and we're really happy. Thanks for those of you who came or watch it on video.

Wednesday, May 19, 2010

Geo Highlights from Day 1 at Google I/O

Boy, are my feet sore!

Wow, what an amazing day! Geo rocked Day 1 at Google I/O.

First, Daniels Lee announced that the Google Maps API V3 has graduated from labs and now is the recommended version of the Maps API to use. It also means that V3 is part of Google Maps API Premier, which is something people have been asking me about.

That also means that V2 is deprecated. We'll continue to support it, and fix bugs, for at least the next 3 years. Check out the deprecation policy in the terms of service. We're also deprecating Mapplets.

We also announced Street View in the V3 API, Flash-less so you can use it on mobile browsers. See my talk for more details. Videos and slides should post soon.

We announced a Directions web service as well, allowing us to close by far the single most requested feature in the issue tracker.

And finally, we previewed a Places widget, allowing you to show Places nearby your current location. It's built on the Places web service, now in Developer Preview.

There was also a fireside chat with Geo engineers and Product Managers, a Developer Sandbox with lots of great stuff on display, and a talk on Maps Data API by Tom Manshrek.

Plus, there were tons of Geo developers all over the conference. I think I talked to half of them. If you're in the other half, come and talk to me tomorrow!

Friday, April 2, 2010

More thoughts on ARML

Sean Gillies commented on my last post on ARML:

Is there anything in the Wikitude namespace that isn't already provided by KML or Atom (KML uses a bunch of Atom elements already and should probably use more)?

It got me thinking a bit more about the subject. First, yes, he's right, if KML supported more Atom links, then everything could be more readily handled by Atom. Or by their KML equivalents. I'm not sure why there's an ar:description, which could be handled by a KML description, or a wikitude:providerUrl, which could be handled by an Atom link element.

I'm concerned too about the extensions. I'd rather have a larger initial set of tags that are optional than put too much on provider specific extensions. If ARML is to really thrive, it'll be because killer browsers come along early, and standard ARML is robust enough to do what most of them will want to do. And, if developers come up with really awesome ways in which ARML can be used that aren't conceived of by the creators of ARML. I'm not sure that Augmented Reality will thrive yet, but if cross-browser AR apps are going to work, the initial standard needs to be robust enough and flexible enough without extensions. I'm not saying they're can't be extensions, just that it has to be able to stand on it's own. Browsers can choose what to implement.

BTW, despite being a KML fan, I'm not saying that KML is necessarily the only way to specify the location. It's great to see it used this way, and it has a lot of potential for cross-platform integration that way. One option might be to actually wrap things in Atom like the Maps Data API does and have additional AR specific elements surface in the Atom.

Hopefully, we can talk more about this at WhereCamp tomorrow.

Wednesday, March 31, 2010

Initial thoughts on ARML

Yesterday at Where 2.0, I went to a great talk by Derek Smith of SimpleGeo and Martin Lechner of Mobilizy on Augmented Reality.. It was a great talk, but readers of my blog will probably not be surprised that I latched on to document formats as an issue. Here's an example from the ARML Specification:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2"
xmlns:ar="http://www.openarml.org/arml/1.0"
xmlns:wikitude="http://www.openarml.org/wikitude/1.0"
xmlns:wikitudeInternal="http://www.openarml.org/wikitudeInternal/1.0"><Document>
<ar:provider id="mountain-tours-I-love.com">
<ar:name>Mountain Tours I Love</ar:name>
<ar:description>My preferred mountain tours in the alps. Summer and Winter.</ar:description>
<wikitude:providerUrl>http://www.providerhomepage.com </wikitude:providerUrl>
<wikitude:tags>travel, hiking, skiing, mountains</wikitude:tags>
<wikitude:logo>http://www.mountain-tours-I-love.com/wikitude-logo.png </wikitude:logo>
<wikitude:icon>http://www.mountain-tours-I-love.com/wikitude-icon.png </wikitude:icon>
</ar:provider>
...

I love seeing KML used in other markups. However, I'd prefer to see something more like this:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2"
xmlns:ar="http://www.openarml.org/arml/1.0"
xmlns:wikitude="http://www.openarml.org/wikitude/1.0"
xmlns:wikitudeInternal="http://www.openarml.org/wikitudeInternal/1.0"><Document>
<ExtendedData>
<ar:provider id="mountain-tours-I-love.com">
<ar:name>Mountain Tours I Love</ar:name>
<ar:description>My preferred mountain tours in the alps. Summer and Winter.</ar:description>
<wikitude:providerUrl>http://www.providerhomepage.com </wikitude:providerUrl>
<wikitude:tags>travel, hiking, skiing, mountains</wikitude:tags>
<wikitude:logo>http://www.mountain-tours-I-love.com/wikitude-logo.png </wikitude:logo>
<wikitude:icon>http://www.mountain-tours-I-love.com/wikitude-icon.png </wikitude:icon>
</ar:provider>
</ExtendedData>
...

It may seem like a small change, but ExtendedData was explicitly designed to be a bucket of tags that are carried around with any KML Feature. While the current specification "works" in Earth, that's because it is forgiving, and other KML implementers might not parse it as well. Using ExtendedData would stick closer to the KML specification.

Wednesday, September 30, 2009

More Musings on the HTML Model and the GeoWeb

In my last post, I mused about the state of GeoWeb standards and wandered off into a discussion mostly on findability and linking between different files. I've been thinking more about the HTML web and how we use it as a model for what we call the GeoWeb.

The HTML web famously starts with Tim Burners Lee, Robert Cailliau, and their famous 20 tags, 13 of which we still use today. HTML sprang out of SGML, the Standard General Markup Language, but was far simpler, and, well, usable. We all know that the web took off like a rocket, and now the Web is synonymous with the Internet in the eyes of many people. HTML is the vehicle, but as developers know, it is only a part of web. Granted, it's the part that the other parts all depend on, but here's a partial list of the technologies without which the Web as we know it would be fundamentally different:

1) HTML

2) HTTP

3) JavaScript

4) XML

5) JSON

6) Flash

7) CSS

OK, Flash is controversial, I'll give you that, but you have to agree, the Web would be really different without it. Some of you would say better, but very different. Of course, there are other technologies people could put in there, like ASP, PHP, Python, etc. My point isn't the specific technologies, though I'll talk about JavaScript in a minute, but the fact that any developer could come up with this list. I'd like to compare that to a list an enterprise apps developer might come up with:

1) Java

A much shorter list. Again, you could argue about the content of the list, but the fact is, for many other domains, a developer can learn one language, one piece of technology, or perhaps two, and that's it.

So the web is different. It is hard to imagine a serious web designer now who doesn't know JS and HTML and probably PHP or Python or some other server-side scripting language. Maybe Flash instead of JS, but you get the idea. I call it the HTML Web because without HTML the rest couldn't work. But, it's hard to imagine a serious web site without using these other technologies.

I was thinking about this because I am asked all the time, why doesn't Google add JavaScript or some other scripting capabilities to KML. Of course, we no longer own KML, we gave it to the OGC, so we can't just "add" something to KML, aside from our own language extensions. But the question shows that there is a fundamental desire on behalf of developers to have that functionality. Serious GeoWeb developers learn a variety of technologies too. For a basic Google Maps mashup (or Bing, or Yahoo! Maps too), you need at least HTML, CSS, and JavaScript. More complicated mashups will use KML, GeoRSS, or GeoJSON, maybe Flash instead of JS, and wait. Notice the first one of those technologies, HTML. Still fundamentally, the GeoWeb relies on HTML. Sure, with a GeoWeb browser like Google Earth, you don't need HTML, though you can use it in the description balloons. But most mashups require HTML as the carrier.

So for the GeoWeb, we've learned the lessons of the HTML web. The question I'm asking, I guess, is, is this the right thing? Is building on the HTML model, with it's confusing amalgam of technologies, many of which don't work easily together, really the best model for the GeoWeb. I don't have the definitive answer to that question, but I think it's worth asking. Would it be better if we had a single technology to create Maps and distribute them?

OK, I have a preliminary answer, yes it would be better to follow the HTML model, and have an amalgam of technologies than to be locked into a single one.

Saturday, February 21, 2009

Slides from Visualizing the Past

I presented at Visualizing the Past on Google Geo technologies and their use for historical visualization. I didn't get to the part on the Google Visualization API, but the links are in the slides.

Saturday, February 14, 2009

Finding Love Somewhere on Google Earth

For those of you still trying to find love, or who want to get a date for next year, I put together this sample app. Oh, BTW, careful, some of the images might not be safe for work. Sometimes people put risque things in their profiles.

I queried personal ads in Google Base using the Base API. Several different personals sites push their ads into Base to make them more discoverable. Base allows for location based queries, including a bounding box query that looks like this:

http://www.google.com/base/feeds/snippets?bq=[item type:personals][location(location): @+34-086..@+37-092]&content=geocodes

That query returns an Atom feed of personal ads within the bounding box. Don't worry, they don't put addresses in the ads, only City, State/Province, and Postal Code. And Base allows you to directly geocode within the query, returning additional g:latitude and g:longitude elements, to save you the hassle.

KML provides a convenient View Based Refresh. Simply put a viewRefreshMode of in a Link element, and Earth and Maps will send query parameters defining the bounding box of what is visible to a server. So, I put a simply python script up on an App Engine application, let it parse the bounding box parameters, and generate the queries, returning new KML every time the view pauses for more than a few seconds. Then I created a simple Earth API page, nothing fancy since it was getting late and I was tired, and loaded up the KML.

I could have used one of the Google Data Client Libraries, OK really only the Python one because I was using App Engine. But frankly, it was such a simple query, and I really love raw XML, I decided to stay with direct querying and DOM parsing.

If you want more info on View Based Refresh, look at the KML reference for viewFormat.

Random Markers