Comments on: EPA KML a great step, but both forward and backward

By: Pawan Kumar

Pawan Kumar — Mon, 07 Sep 2009 12:18:16 +0000

Hi,
I want to know that i can imort the kml file into Bing epa if it is possible please tell what is the process to imort kml file into Bing epa

thanks
Pawan Kumar

By: Jeremy Cothran

Jeremy Cothran — Tue, 11 Dec 2007 20:19:43 +0000

Like Jason, I also see KML as a facilitating data exchange as well as data styling – my frustration with the ExtendedData element is that it seems to handle only a very simple case of listing the same attribute at multiple locations – a common situation I see in obsevation systems is that several redundant/different observation types are measured at the same location(approximately) with mainly differentiations in elevation measured. The simplest metadata schema that I developed to handle this situation is detailed at http://carocoops.org/twiki_dmcc/bin/view/Main/ObsKML

An alternative(but file intensive) approach that fits the single attribute per placemark approach using the EPA example would be for EPA to list separate KML files for each observationType(say NOx) and unitOfMeasure(say ppm), leaving only the measurementValue, etc in the ExtendedData schema. Doing this still leaves establishing the observationType and unitOfMeasure per file as a best practice than part of an xml schema.

By: Andrew

Andrew — Tue, 04 Dec 2007 13:57:36 +0000

That’s a very good point Brian – the responsibility typically lay with the tool developers rather than the user.

The common argument I’ve heard in favor of this type of behavior (mixing attribute data as Altitude), and as Jason points out, is that it “looks good in Google Earth” – however, 1) Google Earth isn’t the only KML client, so if we permit “mixing” of arbitrary bits and representations then we’re going to get the ‘GeoBrowser’ incompatibilies like we have in browsers (how should I render an extruded marker?) and 2) is KML really just a ‘drawing format’ like SVG in a different canvas space? That’s what the “it’s good enough for viz” seem to be saying.

By: Brian Hamlin

Brian Hamlin — Mon, 03 Dec 2007 06:30:59 +0000

thanks for the heads up.. I am guessing the EPA is using GDAL to generate the KML, because not too many generators mark the KML as v2.0 anymore. Also, yes, it is kind of wacky that they use altitude this way. But hey, KML is a display format. You are going to see all kinds of things. I’m glad they have a CSV/HTML output listed right near by, too..

This data isn’t for hard-core analysis, this is public outreach for techies. And there is a place for that. Overall, thumbs up

By: Jason Birch

Jason Birch — Sun, 02 Dec 2007 22:33:05 +0000

Interesting take Andrew. I see KML as filling two roles: data presentation and data exchange (if you’re not willing to take the time to develop a GML schema).

I sometimes have a hard time maintaining semantic goodness while achieving the level of creative and attractive results in Google Earth that I desire. For instance, the work that I’ve been doing recently with panoramic photos and earlier using a multigeometry for polygonal mouse-overs really makes the data not suitable for import into a GIS. …and in these cases I care less about that than I do about it looking good and working well in Google Earth.

Those are relatively extreme cases though. I agree that it would be great if styling was suitable divorced from attributes so that we are less tempted to make the data ineffective outside of its intended purpose. This is one of the reasons I am glad to see KML get pushed into a standards track; in many ways this is similar to the browser wars around HTML that we are just starting to recover from now. I see great value in KML as an information dissemination format, and the more “standard” it can be, the wider its reach.

Hmm. What was my point? Good thing this is just a comment.