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…

Firstly, there’s definitely going to have to be a “part three” of this now, as this post clearly raised a lot of questions and has generated more confusion than I intended (although that’s not all bad).

Despite the fact that I was alright with the examples and content of the post after reading through it a few times and publishing it, I have since decided I really don’t like it, not because I think the premise I put forward is invalid, but because I don’t think I gave enough context, background, and explanation.

In response to Matthew’s comment re: presentational data alongside strictly geographic data — I agree. One of the other things I had intended to bring forward (which will probably make its way into part three) is that if we’re going to have potentially multi-file/more complex parsing logic or various external, potentially complex schemas to deal with, they should be kept on the presentation side as much as possible — your average “styling client” — if you will, is running client side, is probably doing a bunch of stuff behind the scenes anyway, and has not nearly the problems that, say, a server side process handling requests for gobs of simultaneous users would have in needing to parse multiple documents to extract what it needs out of any given set of data.

That being said, I’m still very strongly advocating that everything either side of the fence really needs, strictly speaking, should be contained in a single file.

In response to Mookie, Re: “what we lose with microformats” –

I’m pretty much in agreement with a lot of what you said, which I see as a failing of my original post, although I’m not sure I’m quite catching the point about Cardinal Richelieu losing his identity. My examples could have been better, but if I use my microformat example and change “Leader” to “Inquisitor” (which doesn’t really break the meaning of the feature, whatever that might mean in this context), I can still XPathily deduce that there are several Inquisitors with parent features in the document, and what their names are.

This does, however, lead to the potential problem I cited in “…you won’t know for sure which attributes are present in the features until you parse all of them, or at least run some sort of XPath query over the document to figure it out”.

Clearly, this isn’t the most efficient way of doing things from many points of view. And I would be fully in favor of a hybrid Schema/Microformat/Something else approach, although I’m still a little wary of requiring the hybrid approach.

The rationale behind this is that marking up these features should be about as simple and brainless as possible in the majority of cases, and not potentially break existing workflows where that is unnecessary. The beauty of microformats is that you’re still pretty much just making HTML, but just like you might italicize a word for emphasis, you can similarly throw another tag in there to… umm… “featurize” a geographic location you were textually describing already anyway.

I’m also fully aware we’re still a ways off from having a solid solution, and I’m basically on the verge of changing my mind about the requiring of an explicit schema definition, but I haven’t quite jumped off that ledge yet

Thanks for all the feedback and comments so far, keep ‘em coming!

Incidentally, I submitted a proposal for FOSS4G earlier today that uses my last two blog posts on this topic as a starting point for discussion, so if you’re interested in exploring the topic further, you should be able to review and vote for it soon for a chance to hear me blab incoherently in person!

I wrote up a little response here:

http://www.fortiusforge.com/2007/6/28/kml-with-microformats-what-would-we-lose

Let me know what you think.

“The dog is located at 40.498951,74.684669in the spatial reference system of EPSG:4326″.

Mostly I just wanted to make fun of that RFC.

The flip-side, of course, is that you shouldn’t discount the benefits of keeping styling logic *separated* from data. For example being able to easily reclassify data and apply the same styling rules to other datasets.

Thanks for the comment. Although I’m not 100% sure I’m on the same page here. The coordinates given in my examples were intended to be KML document fragments, and while it’s quite possible that I screwed something up in my haste, they appear to be more or less correct according to KML. The examples were intended to show the use of feature markup inside of KML, and not the markup of locational/coordinate data specifically.

I could probably launch into a rant re: projections/SRS/etc. but this probably isn’t the time or place.

I might have also completely misinterpreted your comment, if so, please step in and correct me.

-Chris

“The value specifies latitude and longitude, in that order (i.e., “LAT LON” ordering). The longitude represents the location east and west of the prime meridian as a positive or negative real number, respectively. The latitude represents the location north and south of the equator as a positive or negative real number, respectively. The longitude and latitude values MUST be specified as decimal degrees and should be specified to six decimal places. This will allow for granularity within a meter of the geographical position.”

While this clearly specifies a coordinate system, and even a easting and northing, this does not specify an ellipsoid (and therefore spatial reference system). You’d need to know the SRS (NAD83, WGS84, etc.) for lat/long *not* to be meaningless. That “one meter” reference may be true given a particular SRS, but is totally off otherwise. If your standard clearly defines this, fine, but generally this is why we don’t look to Netscape for geodata standards.

http://www.sharpgis.net/2007/05/05/SpatialReferencesCoordinateSystemsProjectionsDatumsEllipsoidsConfusing.aspx