For some reason the link in the first comment does not work, but this should...

<a href="http://www.google.com/earth/outreach/tutorial_spreadsheet.html"> http://www.google.com/earth/outreach/tutorial_spreadsheet.html</a>

[More]

Some more information can be found here on the Google Earth Outreach site: http://www.google.com/earth/outreach/tutorial_spreadsheet.html.

[More]

My worry about new paper journals is that libraries don't buy them, or at least too few do. T&F seem to me to be one company that specialises in journals no-one can read, and they are not keen to let you post your own pdf files. I suspect that established journals adapt at a rate that is faster than take-up of new journals.

I may post my "fun" experiences with T&F in a quiet moment for people's amusement.

[More]

Thanks for posting about Geosphere, Toby.  Open access is great and yes, we should check out the other journals in this regard.  Having glanced at the Geosphere web pages, I couldn't find many (or indeed any) articles about informatics, data or software - it was mostly geology articles.  Nothing wrong with this per se, but perhaps a more focussed journal is more appropriate, since I can't see Geosphere having much visibility in the informatics community with its current content.

(I just remembered that I'd forgotten about Computers and Geosciences - I'll post to the Wiki now!)

[More]

I've added a link to your wiki page: the Geological Society of America's online-only journal, who say:

"As the field of geoinformatics has emerged over the past few years, a common theme has been the need for researchers who have developed databases and software to have an outlet to publish their results in a peer-reviewed forum. Thus, we have established “data contributions” and “software contributions” as categories of publication"

http://geosphere.geoscienceworld.org/

This one has the advantage of

• not being owned by Taylor and Francis (some people don't like them)
• being fully open-access - ie everyone will be able to read your articles.

If anyone has the time to do so, I'd be interested in the open-access-ness of the other journals listed.

[More]

Toby - I think that's a pretty interesting idea (embedding data in XML and providing an XSLT transform to HTML). Clearly this is beyond most end-users, but data providers should be able to handle this sort of thing and it's a good way to carry data that can be rendered human-readable.

I've created a "Wish list" Wiki page to capture ideas like this and bring them to the attention of software providers: http://scispace.niees.group.cam.ac.uk/geobrowsers/page/Wish+list

[More]

This is interesting - but I guess this only works if it's meaningful to view your data as contours (which must be common so well worth doing).  For "raster" visualisation I guess we're stuck with multiple polygon tiles, unless someone can come up with an alternative (like creating a vertical wall in Sketchup and projecting an image onto it - tricky for large-scale objects due to the curvature of the earth!)

But yes, given the awkwardness of creating such vertical section data (as polygons or contours) this could be a valuable addition to the Fortran library. 

[More]

It's probably worth mentioning that there's an overlap here with some work that Gen-Tao & I did (which is mentioned in another blog entry by Martin).

While for images on the surface of the earth it's possible to construct images and project them onto a globe, we found this unsatisfactory for various reasons. Our first solution was to follow the same strategy as mentioned here, and just write out a lot of polygons - but that rapidly proved too cumberrsome at increasing data resolutions. So in the end, we wrote a library to read arbitrary data and produce filled contour plots built from KML Polygons. This conveys the same information at significantly lower cost in lines of KML.

The same approach ought to be applicable here. Our code won't do this straight away, though it shouldn't be too hard to adapt.  

[More]

This seems an entirely sensible approach - but if I were them I wouldn't call it obsKML! I don't see that anything they are doing is particular to KML. Designing a language (and associated toolkits and infrastructure) to support their needs seems a very useful task, but I if I were them I would want to be able to embed it in other languages (not least GML) where appropriate.

 I really don't believe that extending KML would be appropriate in this instance (not that they are intending to as far as I can see).

We approached precisely this problem in the Fortran/XML workshop we ran in January 2007. Given a code (hypoDD) which outputs data on earthquakes, some of which is geospatial (earthquake location) some of which is not (earthquake magnitude), and some of which is incidental but should be stored (when did you run the analysis), how do you usefully mark it up? Our answer was:

1. you use KML for the geolocation portion (you could equally use GML, but KML visualization is easier)
2. you use some XML vocabulary suitable to your task at hand (QuakeML in that case) for additional data
3. for incidental metadata, choose a suitable vocabulary (in this case Dublin Core, but there are others)

I think the biggest question to ask when approaching this sort of problem is 'what do you want to do with the data'. In both the ObsKML and the hypoDD case, the geo-coding chosen was KML, not GML. Why? Well, simply the availability of KML-aware tools. GML for all I know could be a much better fit, but I don't have anything that reads GML files (it's not hard to convert to KML, but it is an extra step)

With respect to the rest of the data, it's no use inventing an XML language - or using an existing one - if you don't have tools to understand, analyse, and visualize it. Currently the problem that needs solved is two-fold. One is easy to solve (and this is what has been addressed above) - how do you encode additional information in an XML file. Well, that's easy - er, you put it there! The other is much more difficult - how do you do anything with it? Well, you can write your own tools. And you'll have to. But work from geobrowser vendors could help us here.

Martin said above "KML is really missing a lot of the additional capability you want." I refute this completely - KML is not missing any capability. Rather, Google Earth is missing the capability to make use of any additional data fed to it. 

What I would really like to be able to do is to use foreign namespace elements inside KML, with some GE-comprehensible annotation saying 'this data can be visualized like so:'

• This could be an XSLT stylesheet which extracts data and writes an HTML table - that GE can display as it would a <description> tag,
• or it could be a redirect to an external web service which reads the data and renders an image, which GE then places appropriately.
  
• or it could be a redirect to an RIAwhich allows manipulation/exploration of the data in concert with GE, 
• or ...
  

Doing this would enable me to have single XML documents which contain all necessary data/metadata, in some well-established format which I or anyone else can write tools to use, but can also be immediately visualized in GE.

 I can imagine syntax like:

 <Placemark>

   <Description>

      <Foreigndata xslt-transform="http://www.example.com/geodata/myXml2Kml.xsl">

        <myXml xmlns="http://www.example.com/geodata/">

          ...

        </myXml>

      </ForeignData>

   </Description>
 

   <Point>

     <coordinates>-122.0822035425683,37.42228990140251,0</coordinates>

   </Point>

</Placemark> 

[More]

KML was not designed to carry data (it's a visualization format really) so I guess we have to be careful to avoid scope-creep.  There are probably two points of view:

• Let KML do what it does best and leave other stuff to other formats (e.g. GML)
• Let KML be extensible and make sure that applications gracefully ignore anything they don't understand

I'm not sure which is better. You could embed GML in KML, but you might end up with things being georeferenced twice (once in the KML, once in the embedded GML).  This kind of happens in the example on the ObsKML front page: the elevation of each observation is encoded in the <obs> tags, but could also be encoded in the KML - the appropriateness of this would depend on the application.

My personal preference at the moment is to use KML to geolocate a "thing" (so it can be plotted on a map) and then link to a website (or Web Service, or GML document) that describes the thing in more detail.  I'm not too convinced yet by efforts to put data into KML and I can see things getting confused.  We shall see!

[More]