Multiple geometries in an GeoRSS item (again)

[Chris Krahe]

Some parts of this message have been removed. Learn more about Nabble's security policy.

As I'm looking at rendering 3rd party (and eventually indexing) GeoRSS with multiple geometries, I'm going to throw my 2 cents in on the unfinished discussion that started with this Tim Leigh post (http://lists.eogeo.org/pipermail/georss/2009-February/001960.html).  Granted, this GeoRSS comes from none other than MetaCarta, so I wouldn't be surprised if Chris Schmidt had a hand in generating it :)

First off, unless I'm missing something, I can't find anything at GeoRSS.org that discourages multiple geometries per item.  Given that, and the simplicity that GeoRSS is meant to bring, I'm OK with Chris Schmidt's response (http://lists.eogeo.org/pipermail/georss/2009-February/001975.html) to do exactly that.

What's funny, though, is that given all the ideas discussed in this list, I actually prefer the shelved georss:collection proposal (http://georss.org/proposals/multiple_locations), with two tweaks.  I like the original proposal because: (a) readers that ignore the georss:collection can still process each (or the first) georss geometry; and (b) "advanced" readers can use the excerpts if they want to better-understand things. 

The two tweaks: (1) Drop the reference to external geometries -- it's a great idea but shouldn't be mixed with this proposal.  (2) Allow, but don't require, a single georss geometry _outside_ the georss:collection to act as the "main" geometry for the item.  I could be talked out of this, but it seems valuable because: (a) readers otherwise thrown by georss:collection would still get a geometry to work with, (b) it lets the author mark the most important geometry, or if they choose, simply wrap the geometries inside the collection with a bounding geometry.

Chris

p.s. Tim -- good luck with your work ... with all the fires Australia has had this season, I expect your hands have been full.

Chris Krahe
GeoWeb Architect & Developer
DNI ICES Contractor, Hewlett-Packard
chris.krahe@...
410-854-9655, 904-5187 secure

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

Chris,

Thanks for your interest in extending GeoRSS. I think, though, that the discussion is only termed "unfinished" by those who are still unsatisfied by the result. The effect of GeoRSS is too create a feature out of what a feed entry refers to. The intent of GeoRSS is to make that feature widely interpretable. Chris Schmidt's point was "do whatever you want" as long as you are not assuming that anyone outside of a small circle of friends will understand it. The primary scope of GeoRSS itself is to support widely accessible location-enabled "news" and discovery, rather than precise and complex feature representations. There are other standards for that purpose.

Every proposal so far to have a standard way of packing more geometries into an entry has failed to reach consensus because (at least in my view) it tried to overload the original simplicity. Either it did not specify the intent of the multiple geometries, tried to cover too many intentions, or simply violated the basic model and schema (c.f. georss:collection). Are the multiple geometries intended to be part of a single multi-geometry (close but not identical to TIm Leigh's use case), or alternatives for a single geometry, or geometries characterizing different, possibly linked features in the referenced resource, or some or all of the above, or possibly something else? It may seem picky, but it is vitally important to have a clear meaning in a widely applicable standard.

As has been mentioned a number of times before, feel free to insert anything you want into an Atom item for interpretation by a particular community where the meaning is communicated out-of-band. GML application features intended specifically to model what is being represented are a good choice, although not everyone is happy with that approach. If you want to start using ck:collection, that's fine, but it won't validate it against the georss schema if it redefines georss:point, etc., as shown in the proposal.

Despite the apparent greater wordiness (i.e. an entry for each geometry) of the link approach to multiple geometries, it has two great benefits. 1) It allows clear definition of the relationship between one geometry and another, as well as between a geometry and other information, and 2) it doesn't clutter the basic definition of GeoRSS. We do need, I agree, to document linking practices clearly and concisely on georss.org. In fact, a number of improvements and corrections need to be made to the site. Hopefully that will happen soon.

That said, it is a community effort, and if you'd like to put together a "GeoRSS Complex" proposal and try to reach consensus on it, I'd suggest working at it as an extension rather than an alteration of the current model, making it easier for most feed handlers to continue targeting the basic GeoRSS Simple or GML.

Regards,

Josh Lieberman

On Apr 20, 2009, at 1:03 PM, Chris Krahe wrote:

As I'm looking at rendering 3rd party (and eventually indexing) GeoRSS with multiple geometries, I'm going to throw my 2 cents in on the unfinished discussion that started with this Tim Leigh post (http://lists.eogeo.org/pipermail/georss/2009-February/001960.html).  Granted, this GeoRSS comes from none other than MetaCarta, so I wouldn't be surprised if Chris Schmidt had a hand in generating it :)

First off, unless I'm missing something, I can't find anything at GeoRSS.org that discourages multiple geometries per item.  Given that, and the simplicity that GeoRSS is meant to bring, I'm OK with Chris Schmidt's response(http://lists.eogeo.org/pipermail/georss/2009-February/001975.html) to do exactly that. 

What's funny, though, is that given all the ideas discussed in this list, I actually prefer the shelved georss:collection proposal (http://georss.org/proposals/multiple_locations), with two tweaks.  I like the original proposal because: (a) readers that ignore the georss:collection can still process each (or the first) georss geometry; and (b) "advanced" readers can use the excerpts if they want to better-understand things.  

The two tweaks: (1) Drop the reference to external geometries -- it's a great idea but shouldn't be mixed with this proposal.  (2) Allow, but don't require, a single georss geometry _outside_ the georss:collection to act as the "main" geometry for the item.  I could be talked out of this, but it seems valuable because: (a) readers otherwise thrown by georss:collection would still get a geometry to work with, (b) it lets the author mark the most important geometry, or if they choose, simply wrap the geometries inside the collection with a bounding geometry.

Chris

p.s. Tim -- good luck with your work ... with all the fires Australia has had this season, I expect your hands have been full.

Chris Krahe
GeoWeb Architect & Developer
DNI ICES Contractor, Hewlett-Packard
chris.krahe@...
410-854-9655, 904-5187 secure

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Tim Leigh]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Josh et al

 

As Chris mentioned, it would be great if the issue of complex geometry types is addressed at georss.org with a recommended approach using simple geometry types.

 

For the moment I am continuing with the following approach, however I would like to take a standard approach to this issue.  For me, it isn’t practical to duplicate all the item details for each geometry as this breaks the relational nature of the data.  ie. Multiple distinct geometries relate to a single fire.  This then results in a much larger rss file and re linking the geometries to a parent item in the client is messy.  GML encoding of the geometries appears to be unnecessary for my use case.

 

    <item>

      <title>..</title>

      <link>http://...</link>

      <category>..</category>

      <pubDate>..</pubDate>

      <description>...</description>

      <georss:point>[coordinate pair]</georss:point> <!—fire origin location -->

      <georss:polygon[coordinate pairs]</georss:polygon> <!—first burn area -->

      <georss:polygon[coordinate pairs]</georss:polygon> <!—second burn area (distinct from first area, however relating to the same fire incident, such as a spot fire) -->

      <georss:polygon>[coordinate pairs]</georss:polygon> <!—third burn area -->

      <georss:polygon[coordinate pairs]</georss:polygon> <!—fourth burn area -->

    </item>

 

Thanks

 

Tim

This email message is intended only for the addressee(s) and contains information which may be confidential.
If you are not the intended recipient, please notify the sender and delete this email and any copies or
links to this email completely and immediately from your system. Views expressed in this message are
those of the individual sender, and are not necessarily the views of the NSW Rural Fire Service.

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

Tim,

I would love a standard way to accommodate your use case. We seem to be at something of an impasse, however, because most people besides yourself would have no idea that <fire origin>...<first burn area>...etc is what you mean by providing multiple simple geometries, but you are opposed to the suggested ways of making these relationships explicit. Even schematically, there is no way of enforcing the order below which is meaningful for you, so there is every likelihood that not even you would be able to interpret your item once it had passed through some feed integrators, etc. Any other client would likely grab the first georss element it came across, regardless of what it represented, most likely giving an incomplete and incorrect accounting of the event resource it was supposed to communicate.

BTW, going to GeoRSS GML is not a solution, because it also does not support multiple geometries, for the same reasons. The only thing approaching a consensus at this point seems to be to interpret multiple georss elements as alternatives, most likely representing the same feature in different coordinate reference systems. A point and a polygon could conceivably represent scale-dependent alternatives, but defining "appropriate scale" is a pretty difficult problem across wide ranges of applications and technologies, so it would have to be an application choice.

It's hard for me to think of a better approach than providing one GeoRSS summary geometry in the item, then inserting a GML application feature in the contents of the item which is tailored to represent the spatial and temporal burn sequencing which you have below. Something for everyone to interpret correctly, generic or specialized.

As has been said elsewhere, feel free to do what you want, but don't expect that it will necessarily work for others, or for a broadly useful standard.

--Josh

On Apr 21, 2009, at 7:37 PM, Tim Leigh wrote:

Josh et al

 

As Chris mentioned, it would be great if the issue of complex geometry types is addressed at georss.org with a recommended approach using simple geometry types.

 

For the moment I am continuing with the following approach, however I would like to take a standard approach to this issue.  For me, it isn’t practical to duplicate all the item details for each geometry as this breaks the relational nature of the data.  ie. Multiple distinct geometries relate to a single fire.  This then results in a much larger rss file and re linking the geometries to a parent item in the client is messy.  GML encoding of the geometries appears to be unnecessary for my use case.

The multiple distinct geometries appear in your case to be attributes of multiple diachronous features, which have been classified as belonging to a single fire. Except for that link to a "single fire" item (the "foreign key"), there is no particular reason that other item properties have to be the same. Once each geometry is a separate item, even the simplest and most generic GeoRSS client will be able to render them all, leaving the user to examine the other properties and links to see which ones relate to the same event, and in what way. More specialized clients can act on the links in an application-specific manner. There is no particular relational reason that multiple RSS or Atom items /entries cannot refer to the same resource.

georss:collection is problematic for many reasons, not the least of which is that the elements in a feed item /entry are semantically properties or predicates. The other reason is that every time we've begun to describe the relationships to and among sub-geometries across a range of use cases, we've ended up with recursive "mini-entries" anyway, e.g.

<georss:everywhere>

   <georss:Subfeature>

<georss:point>42,-145</georss:point>

<id>qweoijafa</id>

<category term="fire origin location" scheme="http://fire.org/taxonomy" label="origin"/>

   </georss:Subfeaturet

   <georss:Subfeature>

<georss:polygon>42,-145, 43,-145,43,-144,42,-144,42,-145</georss:point>

<id>qweoijafb</id>

<category term="first burn area" scheme="http://fire.org/taxonomy" label="first burn"/>

   </georss:Subfeature>

<georss:everywhere>

etc.

 

    <item>

      <title>..</title>

      <link>http://...</link>

      <category>..</category>

      <pubDate>..</pubDate>

      <description>...</description>

      <georss:point>[coordinate pair]</georss:point> <!—fire origin location -->

      <georss:polygon[coordinate pairs]</georss:polygon> <!—first burn area -->

      <georss:polygon[coordinate pairs]</georss:polygon> <!—second burn area (distinct from first area, however relating to the same fire incident, such as a spot fire) -->

      <georss:polygon>[coordinate pairs]</georss:polygon> <!—third burn area -->

      <georss:polygon[coordinate pairs]</georss:polygon> <!—fourth burn area -->

    </item>

 

Thanks

 

Tim

This email message is intended only for the addressee(s) and contains information which may be confidential.
If you are not the intended recipient, please notify the sender and delete this email and any copies or
links to this email completely and immediately from your system. Views expressed in this message are
those of the individual sender, and are not necessarily the views of the NSW Rural Fire Service.

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss