The escaping mechanism for angle brackets eluded me ..

So that 3 gravel should read without the angle brackets.

Road gml:id=”t21″
numberLanes 3
surfaceType gravel

AND I mean including GML within the Metadata tag.

Sorry for the creaky posting!

This is a most cool discussion. Please see the blog rollover at http:www.geoblog.org.

We are evaluating point GML inside the KML Metadata tag as means of structuring the content. Very simple approaches are suggested to start with – i.e. GML Application Schemas that are flat (e.g. simple properties) and which may not even use geometry or other core elements of GML unless you want them). Why do this? Well it constrains the XML Schema so that it is very simple – GML schemas (hence the data) just look like Named property lists.

3
gravel

This would easily ride along as a KML payload and like KML also can use xlink:ref to reference other content.

Bravo on your statement!: “it’s easy/ease of adoption/only have to parse a single file ideal.” if OGC gets it right, I can see KML becoming the SINGLE file that could replace all the files that make up a shapefile, that ubiquitous GIS format all GIS pros are familiar with.

The .SHP, ,DBF, .SBN, .SBX, .SHX, .PRJ, .XML, .AVL, and .LYR. Just imagine it! Geometry, attributes, the index between the two, metadata, and symbology all wrapped into one! Talk about REAL geopublication!

Now the geodatabase may bring this eventually and I believe its been deemed an “open”, but I have yet to see anything of real “WOW” potential yet.

I’ll be following your posts. Keep up the good work.

Some of the things I’m writing up to propose as better long term solutions lie somewhere in the middle of fully structured geodata and things like GeoRSS or just plain ‘ol XHTML in the description field. I hope to have that post written up in the next couple days and hopefully have it spark some interesting discussion.

I actually agree with you fully re: KML being the “powerpoint of geo-spatial data” — but that’s kind of the kicker. At least for our purposes, we need something that is widely accepted and used, otherwise we’re asking our users to convert their data into something that they might not have used otherwise, and the more work that is entailed, the harder it is to see widespread use and adoption, and we do really feel that making the data and the analysis as open and accessible to as many people as possible benefits everyone.

I guess the thing to walk away with from that post is essentially “Presentation is good, feature data is good, leveraging a widely-adopted format like KML has many benefits, and we’re not too far off from having perhaps not the best of both worlds, but quite enough to do 90% of what we need 90% of the time quickly and easily.”

The million dollar question is what data format should you use to store the data. I really think GeoRSS (another format working it’s way through the OGC) is better suited to the job, but I fear it has fractured into too many sub-formats already. I believe there is something like 6 different versions. I’m curious to see what you like to see for a long term solution.