Posts Tagged KML
Validating against the OGC KML Schema in jEdit
Posted by Jason Birch in Formats, KML on January 25, 2009
The Google Earth Outreach team has a good little tutorial on validating KML as you type in jEdit. Unfortunately, it’s a little bit out-of-date, so here are some pointers for validating against the newer OGC 2.2 schema, using the current version of jEdit.
Follow the video instructions above for setting up jEdit, with the following exception: when you go to dock Sidekick, you click on Sidekick instead of Structure Browser and then, in order to start parsing the document, you need to select XML mode:
Once you have loaded your KML file, replace the root kml entity with the following instead of the older Google schemas, and you will be able to validate against the OGC’s KML and partial Atom schemas as you work:
<kml
xmlns="http://www.opengis.net/kml/2.2"
xmlns:kml="http://www.opengis.net/kml/2.2"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.opengis.net/kml/2.2 http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd
http://www.w3.org/2005/Atom http://schemas.opengis.net/kml/2.2.0/atom-author-link.xsd"
>
One odd thing that I noticed in validating my KML. When I placed the <name> entity anywhere other than right after its parent entity (such as Document or Placemark) the parser complained that it was not valid. I don’t know if not having the <name> as the first entity is truly invalid, or if this is just a little quirk of the schema or the parser. The Galdos KML Validator throws the same error.
The main reason I went through setting this up is that I decided that I had to, in good conscience, ignore the part of the OGC KML written standard that constrains Atom relation types to "related". Not specifying the correct type of relationship means that I am contributing to the downfall of society, or at least to a less meaningful GeoWeb. See my previous post and some follow-up at Sean Gillies’ blog for more on this. Using jEdit allows me to ensure that my documents validate against the schema, which gives me at least some level of comfort when ignoring the online validator.
-J
KML Spec Bizarro?
Posted by Jason Birch in Formats, Google Earth on January 20, 2009
I’m working on some new KML resources and, just as I try to do for my HTML, I want to at least attempt to get it to validate against an official specification. For KML, this means the OGC KML specification.
These resources will be single-feature, and will each be related to exactly one HTML representation of the same feature. Now, it seems logical to me that I would specify an atom:link with rel="alternate" inside of these KML files, either at the Document level or perhaps at the Placemark level.
Unfortunately, from section 9.1.3.5.1 of the official OGC KML specification:
The atom:link rel attribute shall be present and its value shall be related.
What the heck? I’m not an XML guy by any means, but I think this means that the best I can do is specify a "I think I met that guy in a bar a couple years ago" kind of relationship, when what I really want is something more like "hey, that’s me in a dress shirt."
Now, if I’m right, the question is: do I exclude the atom:link element from my KML, do I include the element and settle for a generic relationship, or do I intentionally break compliance with the OGC specification. Tough choice.
-J
KML FDO Provider!
Posted by Jason Birch in FDO, Google, Open Source on July 29, 2008
Just a quick note… Haris Kurtagic at SL-King just mentioned that he has put up a very alpha release of a KML FDO provider along with a new release of FDO2FDO which supports it.
With this tool, you can read KML files from MapGuide, and read/write KML using FDO2FDO or Autodesk Map 3D. This provider is still early in development, so get your feedback in now while you can still have an impact on how it works when it’s released.
As an aside, this is the first (soon to be) open source project I know of which uses Google’s libkml.
-J
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
User Map
Recent Comments