Sean Gillies made this counter-proposal that I (Andrew) currently favor as well. The premise is that you create a single primary entry that contains the story, bounding box of locations or primary location (or no locations). Then, using atom:link with rel's, append multiple additional entries per each location or event. The rel points back to the primary article (that this is a comment or related to) and can then include snippet, author, time, and locations.

The benefit of this mechanism is that it currently works within the existing spec, so nothing "new" is added, it is just a suggested way of handling multiple locations. Additionally, there is the ability to include more information for each snippet such as time spans, categories, excerpts, etc. without GeoRSS having to extend and add all those as necessary.

The potential detriment is that to "vanilla" readers a single story could show up as multiple stories: the primary and each excerpt.

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
  >
  <entry>
    <id>urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942</id>
    <link href="http://example.org/entries/1"/>
    <title>Cedarburg Trip</title>
    <summary>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...</summary>
    <content type="html" src="http://example.org/entries/1"/>
  </entry>
  <entry>
    <id>urn:uuid:53664db3-4598-45d4-a727-022c6203322e</id>
    <link rel="related" href="http://example.org/entries/1"/>
    <title>Downtown Cedarburg, Wis.</title>
    <summary>Went to visit downtown Cedarburg...</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>43.296700 -87.98750</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:2528d1b4-b5a9-415c-be69-f83974e3e6af</id>
    <link rel="related" href="http://example.org/entries/1"/>
    <title>Convention Center</title>
    <georss:where>
      <gml:LineString>
        <gml:posList>43.296700 -87.987500 43.3 -88 -44 -89</gml:posList>
      </gml:LineString>
    </georss:where>
  </entry>
</feed>

Original Proposal (shelved)

<description>
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...
</description>

<georss:collection>
	<georss:point excerpt="Went to visit downtown Cedarburg..." 
		featurename="Downtown Cedarburg, Wis.">
			43.296700 -87.987500
	</georss:point>
	<georss:polygon rel="geometry" 
		src="http://geonames.org/geometries/5867680" 
		excerpt="..." 
		featurename="Cedarburg, Wisconsin" 
		type="application/vnd.google-earth.kml+xml"/>
	<georss:line featurename="Convention Center">
		43.296700 -87.987500 43.3 -88 -44, -89
	</georss:point>	
</georss:collection>

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 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.