There has been a meme floating around about the new “Geotag Icon” that was originally proposed here and now has an officious site: Geotag Icon Project

There has been a lot of dialog. Sean discusses a lot of his thoughts about semantic interoperability and formats. There has also been a number of discussions on the design itself - everything from the color, to the pushpin being indicative of points only - maybe reinforcing the “red dot fever” that plagues many maps.

These are really minor quibbles. Overall I think it’s a decent design that gives some simple meaning to what the icon conveys. However, the problem I do have is the Usage guidelines & examples. Essentially, they are saying it should be used for all geospatial formats.

Example from the site:

Bruce defends this:

Whereas the Geotag Icon describes a general concept (”This item is geotagged”) the KML icon and GeoRSS favicon each proclaim a file format. This is analogous to the Feed Icon: can you imagine having a different orange icon for each web feed format? There’s no reason why the Geotag Icon can’t sit side-by-side with file format icons if that’s what folk wish to do. But a well-recognized Geotag Icon (in time!) adjacent to the text description “Download KML file (opens in Google Earth)” could well be more informative to the majority users than what is otherwise sure to be a growing set of vaguely-related file format icons with which to become familiar. The power of de facto standard icons is in instant recognition—and the fewer the merrier!

I disagree, he’s proposing this one icon should be used for a multitude of different formats that each have different capabilities and uses. It’s not like the difference between RSS and Atom, it’s the difference between HTML and RSS or CSS. Or a Video and a Photo. Sure, they’re both images, but they’re also very different in what they do.

He’s creating additional confusion by using the Geotag icon for GeoRSS. GeoRSS isn’t even a file format, it’s an extension to another file format: RSS / Atom, and they already have a recognizable icon that has meaning to users. I wouldn’t want to put yet another icon in front of them that meant something slightly different. And KML is a visualization format, similar to HTML + CSS. GPX is a very specific format that works for handheld GPS units and PND’s. I’m surprised the Geotag Icon wasn’t proposed to be used for Geo and Adr Microformats, since it matches this formula of all things geo.

This is the follie of the greater GIS community - assuming something is primarily geo first, and general information second. I’m surprised this is idea is also followed by people outside the GIS world.

So I only ask that the Usage guidelines of the Geotag icon be scaled back. It’s interesting that it’s been incorporated into Minimap Sidebar - good idea, but perhaps again confusing application with format? Using it in a photograph or video is nice because it’s clear to me that the format is a video (and I don’t care if it’s mov, fla, et al.) and useful to be alerted that it has geocoded content inside. I also think it could be useful as a link to a page of Geospatial formats. Why not even use it like the Share this on… on the Geotag project page itself?

GPX icon is from Garmin’s Communicator Plugin. You could optionally replace the format names (like KML) with suggestion applications, but I find this a little to vendor specific. Don’t you dislike it when people say things like “I opened the Internet Explorer page…”?

I think this set of links is how I would do it in GeoPress. But don’t suggest that Geotag Icon become the over-arching marker for other formats that happen to contain geo-data. Otherwise, I’ll be suggesting a family of icons like Timetag, and Titletag.

A commonly requested feature addition to GeoRSS has been multiple locations per entry. Currently, GeoRSS only adds a single geometry per RSS or Atom entry. This was pragmatic and served the general goals of GeoRSS.

There are several commonly encountered use cases. News reports typically mention several locations. Bloggers using GeoPress may tell a story about a trip and want to reference several spots along their trip - especially if they are documenting a tour that includes a path and sites along that path such as in EveryTrail. Dan Schultz talks about why “One Location Doesn’t Cut It”, citing other examples from news journalism.

Adrian and I recently sat down together to quickly brainstorm on what this may look like. The features we were looking to add were: multiple geometries, excerpt for that geometry, and toponym for that location (venue, city, etc.) Additionally, we didn’t want to break current compatibility.

Other services are already including multiple locations in different ways. Flickr outputs a single location in two different formats of GeoRSS: Simple, and some odd form of deprecated W3C. MetaCarta’s RSS-to-GeoRSS converted currently just dumps multiple locations into the entry, but without identifying if these are unique locations, or just variations in format type or hierarchy.

We wanted to call out that this is in fact a different type of geometry - a multi-geometry. Both KML and WKT support multi-geometry, but without being able to reference what the points are individually about. That’s useful if you are, say, marking all the holes in a field, but not for narratives.

Another feature we wanted to try and support was to be able to reference geometries stored elsewhere. Currently in GeoRSS feeds you’ll typically see references to a City or Country just include a point to the center of that geography. Not really indicative of what the article was about, or useful when trying to find all the geographic data about an area. So it’s important to include lines and areas as appropriate. However, including huge outlines of states or nations, potentially multiple times within a single feed, can have drastically bad consequences of increasing feed file size and complexity.

Here is a snippet of what we are proposing:

The first part to notice is that we wrapped the multiple geometries in a georss:collection. This allows current parsers to not be confused by encountering multiple georss elements unwrapped and being unclear if they are multiple representations of the same geometry, or different geometries.

We also included a excerpt attribute that allows you to include some text referencing what this location is specifically about. This can be text from the article itself, or some other useful information. One concept we had considered was using some reference to the text wrapped in the article itself, but this seemed burdensome and prone to problems using an attribute of one element to embedded text in another element.

The second element is a georss:polygon that includes a src reference to the geometry stored elsewhere. The rel tag specifies that it is the geometry of this element, and the type helps the tool know what the representation is of the stored geometry. This way a tool that is consuming the GeoRSS can go and fetch the geometry if it wants, or if it already has a cached version, say referenced elsewhere in this same feed, then it doesn’t have to request it again.

Of course, with a standards development, it is useful to consider how a user interface might provide for including multiple locations in an entry. Here is a mockup of how I imagine a simple interface would appear, and probably how we’d implement it in something like GeoPress:

Article: We went to visit downtown Cedarburg before the conference. Had some great sandwiches at Joe’s. If you haven’t been to Cedarburg, Wisconsin, then you haven’t really experienced the MidWest…

Locations:
- Excerpt: Went to visit downtown Cedarburg…
- Type: Point
- Geometry: 43.296700 -87.987500
- Name: Cedarburg, Wis.

To promote ideas and discussion around these and other proposals, I’ve created proposals at GeoRSS.org on multiple location and referencing external geometry. Please let us know what you think about the idea and format. We know that we can’t please everyone, but like the origins of GeoRSS, we’re just trying to address a real need with a simple format.

There has recently been a lot of discussion around KML becoming part of the OGC and the future of GeoRSS and KML. Will GeoRSS use KML payloads, or vice versa? Will one just subsume the other? After speaking with a bunch of people at Where, and also thinking about various announcements and talks given by Google-ites, Geo-ers, and standards makers, I’m proposing the following practice for using GeoRSS and KML together along with other formats.

In the talk announcing KML submission to OGC, the phrase “KML is HTML for the geospatial web” was used. I think this is a perfectly apt analogy. To complete the analogy, (taking you back to your SAT days)

HTML : RSS :: KML : GeoRSS

The purpose of the following examples is to illustrate the use of GeoRSS to syndicate KML content, similar to RSS support in HTML. GeoRSS merely adds a geographic component to the common RSS that syndicates web content. KML similarly offers a geospatial alternative representation of HTML content.

Syndication

Therefore, as appropriate, GeoRSS should be used based on existing usages of RSS. This means providing a rel=”alternate” link in both HTML and KML files. Conversely, an Atom or RSS feed requires use of a ‘link’ element to reference the originating content of the syndication. A rel=”alternate” can then be used in a GeoRSS feed to reference the KML version of that content.

Within a GeoRSS file, the entire feed, or channel, can link to the content in type=”text/html” and type=”application/vnd.google-earth.kml+xml”. Within a single entry, the GeoRSS feed can then link to the specific anchor, or element, within the original HTML or KML content using an anchor in the href.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>KML GeoRSS Example</title>
  <link href="http://example.org/"/>
  <updated>2007-06-04T12:34:02Z</updated>
  <author>
    <name>Andrew Turner</name>
  </author>
  <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
  <link rel="alternate" type="test/html"
    href="http://example.org/"/>
  <link rel="alternate" type="application/vnd.google-earth.kml+xml"
    href="http://example.org/kml_georss.kml"/>

  <entry>
    <title>This is my first article</title>
    <link href="http://example.org/2007/06/04/article"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2003-12-13T18:30:02Z</updated>
    <summary>
      KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you’re here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark" type="application/vnd.google-earth.kml+xml kml">favorite park</a>.
    </summary>
    <link rel="alternate" type="application/vnd.google-earth.kml+xml"
     href="http://example.org/kml_georss.kml#article1"/>
  </entry>
</feed>

Documentation

Within an HTML file, the <head> element can contain alternate links to the KML representation as well as the GeoRSS syndication. Similarly, KML 2.2 can contain an <atom:link> alternate representation back to the original HTML content and GeoRSS syndication of the geospatial information. By using these links, a resource can offer multiple formats as appropriate, syndication for alerting users of updates to the content, or visualization for a richer geospatial view.

For a specific KML Placemark, an <atom:link> can be used to link to the original HTML element using the anchor support in the href. Conversely, the HTML element, similar to a GeoRSS item, can use an <a> element to link to the specific KML Placemark representation. This similarly allows for the documentation element to reference the richer visualization of the feature. Clicking this link would either launch a KML viewer, or the original HTML renderer could render the KML element inline, within the browser.

<html>
<head>
  <title>KML GeoRSS Example</title>
  <link rel="alternate" type="application/rss+xml"
    href="http://example.org/kml_georss.rss" title="GeoRSS feed for My Page">
  <link rel="alternate" type="application/vnd.google-earth.kml+xml"
    href="http://example.org/kml_georss.kml"/>
</head>

<body id="kml_georss">
    <h1>Example of KML, GeoRSS, and HTML being used together</h1>

    <h2 id="article1">This is my first article</h2>
    <p>KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark"    type="application/vnd.google-earth.kml+xml">favorite park</a>.
    </p>

</body>
</html>

Notice that by using the type attribute in the <a> we can link to other KML elements, similar to an HTML document linking to elements in other HTML documents.

Visualization

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
  <name>kml_georss.kml</name>
  <atom:link type="text/html"
    href="http://example.com" title="My Page"></atom:link>
  <atom:link rel="alternate" type="application/rss+xml"
    href="http://example.com/kml_georss.rss" title="GeoRSS feed for My Page"></atom:link>
  <Placemark id="article1">
    <name>This is my first article</name>
    <atom:author>
      <atom:name>Andrew Turner</atom:name>
    </atom:author>
    <atom:link href="http://example.org/kml_georss.html#article1"></atom:link>
    <description>
      KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you’re here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark" type="application/vnd.google-earth.kml+xml">favorite park</a>.
    </description>
    <Point>
      <coordinates>-122.370533,37.823842,0</coordinates>
    </Point>
  </Placemark>
</Document>
</kml>

Together, these suggestions allow for parallel use of KML and HTML for content, and GeoRSS for syndication (notification of updates) to that content. It keeps the GeoRSS as a pure markup of the new information, and keeps styling information in HTML and KML.

Here is a spiffy diagram to help illustrate linking the documents and articles together:

A last consideration about linking HTML content and KML content. Both formats are merely markups for storing and rendering information and not bound to a specific renderer (e.g. Firefox or GoogleEarth). However, it is still beneficial to link to a richer geospatial markup from an HTML file. <a> elements can optionally utilize the type attribute to specify the link follows to a KML file. It should explicitly noted that opening a link to a KML type should not necessarily open in GoogleEarth. Again, KML is just a richer geospatial markup of information.

For example, if a user is viewing a location from a GeoRSS file loaded in a 2D map representation, and link in the content points to a KML type, clicking this link should first open the location in the same 2D map representation. If the link is clicked in an HTML file, the appropriate MIME-type handler should be invoked. This is similar to a user clicking a link in an HTML document and opening the link in the HTML renderer.

Depending on the 2D map rendered, an optional “view in 3D” link could be offered to open the Placemark in GoogleEarth or other KML renderer.

OpenSearch

This proposal is just a suggestion, and doesn’t require a change to any of the included formats. In fact, it is just a recommendation for a common usage of these formats to provide for better user experience and linking together your content. Additionally, my previous discussion on OpenSearch Geo fits perfectly with this as you can specify search mechanism for the same content-types. So if you just want the recent changes, request the RSS. Then you could use those results (page) to query specific KML rich placemarks for visualizing.

Mickaël ‘Korbinus’ Graf has released an improved geo:truc. If you haven’t tried it yet, geo:truc is a great and simple service for generating the GeoData markup in currently 8 different formats: Machine tags, geo Microformat, GeoJSON, GeoRSS (GML), GeoRSS (simple), HTML, KML, and GeoRSS-W3C.

To use it you can just click on the map, or enter a location in the form field. Then click on the link for the format you want to see. Read more about it on Mickaël’s blog. One of the neatest improvements, and very useful for integrating into another application, is the webservice:

• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=georss
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=w3cgeo
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=machine
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=geo
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=geojson
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=gml
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=html
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=kml

What is really great about geo:truc is that it provides a very simple and easy to use tool for users to get somewhat complex information. I believe his primary purpose was to provide scientists a mechanism for geocoding their specimen identification experiments. These are non-GIS users who want to store geographic information. Now, they can do it and include it on their websites/documents and share with the world.

But why geo:truc? Mickaël’s reasoning behind the name explains it very well:

“Truc” is a french word meaning an undefined thing, so I joked by calling it “geo:truc”.

As I posted on the GeoRSS Blog, we just recently relaunched the site using a CMS. Specifically, we’re using Drupal because of its excellent support of geospatial standards (and being the one who did the migration, it was very easy to setup - there are definitely other great GeoCMSs out there).

One of the main purposes behind moving to a more dynamic CMS was to involve the community in helping to document and forward the standard. Since there are now more people interested in GeoRSS, there have been lots of questions on format, examples, libraries, and so on that can now be easily added to the site.

In addition, there are typically very long discussions on email on adding new features to the standard. These usually get a really good discussion going, but then kind of fade out without any resolution. While it’s good for a standard to be ’stable’, it’s not good for it to be ’stagnant’ - or just overly frustrate people who are trying to extend it.

Therefore, we’re trying out a new process by which anyone can add a Proposal for extension to GeoRSS. The community can comment and finally vote on it (any member of the community can vote, this means you too!). Even if the proposal is not accepted, the proposal remains as a central point of documentation of the discussion, decision, reasons, and how users implemented the standard for their own uses (you still need to finish your projects).

Then, if and when the proposed addition is accepted, the page can serve as documentation on how to migrate from the proposed format to the finally accepted format.

Anyways, hop on over to the new GeoRSS Site, let me know if you see anything ‘funny’ (e.g. missing images, dead links, etc.) and get yourself an account (they’re free and come with a scoop of ice cream).