Multiple geometries in an GeoRSS item

[Tim Leigh]

Hi

I work for a state government fire agency and we are keen to use GeoRSS
as a data distribution format.  One of our requirements is to embed
multiple geometries per RSS item (in our case burnt area for a fire).

Is the following valid GeoRSS (I can't find any online source to
determine yes or no)?

    <item>
      <title>..</title>
      <link>http://...</link>
      <category>..</category>
      <pubDate>..</pubDate>
      <description>...</description>
      <georss:point>[coordinate pairs]</georss:point>
      <georss:polygon[coordinate pairs]</georss:polygon>
      <georss:polygon[coordinate pairs]</georss:polygon>
      <georss:polygon>[coordinate pairs]</georss:polygon>
      <georss:polygon[coordinate pairs]</georss:polygon>
    </item>

Thanks for your help.

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,
GeoRSS only supports one geometry per entry in order to support the  
widest variety of clients and consumers. The reason is pretty simple.  
I have no idea what is meant by the assortment of geometries in the  
example. GeoRSS is more of an announcement than data distribution  
format, so usage which requires special knowledge is not really in the  
spirit.

There are a couple of alternatives. You can make several entries and  
connect them with a category or link. There are several ideas for this  
circulating. You can also insert a full (GML) feature as content or as  
a link or just as an external element, with the GeoRSS tags (e.g.  
centerpoint) as a more general summary. The your specific consumers  
can extract the feature while general readers can filter and map the  
entry using the point.

Cheers, Josh

Joshua Lieberman
Roving Geo-architect

On Feb 24, 2009, at 23:56, "Tim Leigh" <Tim.Leigh@...> wrote:

> Hi
>
> I work for a state government fire agency and we are keen to use  
> GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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

[Christopher Schmidt]

On Wed, Feb 25, 2009 at 08:28:32AM -0500, Joshua Lieberman wrote:

> Tim,
> GeoRSS only supports one geometry per entry in order to support the  
> widest variety of clients and consumers. The reason is pretty simple.  
> I have no idea what is meant by the assortment of geometries in the  
> example. GeoRSS is more of an announcement than data distribution  
> format, so usage which requires special knowledge is not really in the  
> spirit.
>
> There are a couple of alternatives. You can make several entries and  
> connect them with a category or link. There are several ideas for this  
> circulating. You can also insert a full (GML) feature as content or as  
> a link or just as an external element, with the GeoRSS tags (e.g.  
> centerpoint) as a more general summary. The your specific consumers  
> can extract the feature while general readers can filter and map the  
> entry using the point.

Of course, another option is just to deliver what you have. Most GeoRSS
clients won't understand it -- they'll probably display the first
geometry -- but your client can consume them and do what you like with
them.

Regards,
--
Christopher Schmidt
Web Developer
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Andrew Turner-8]

As you can gather by the responses - it's not clear yet. As Chris
said, clients will most likely quietly ignore the other geometries.

To help the discussion, can you share what the multiple geometries
are? Part of a location hierarchy? Multiple locations found in the
content? That would help in the discussion.

Andrew


On Tue, Feb 24, 2009 at 11:56 PM, Tim Leigh <Tim.Leigh@...> wrote:

> Hi
>
> I work for a state government fire agency and we are keen to use GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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
>

--
Andrew Turner
mobile: [phone]
andrew@...
http://highearthorbit.com

http://geocommons.com           Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Sean Gillies]

On Feb 24, 2009, at 9:56 PM, Tim Leigh wrote:

> Hi
>
> I work for a state government fire agency and we are keen to use  
> GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>

Hi Tim,

I'm going to take you literally when you say "data distribution".

Atom's content model is better suited for delivering data than RSS 2  
because atom:content is more general purpose than RSS enclosures. To  
deliver complex feature data, put GML in an atom:content element. Put  
the feature's bounding region in a georss:where element in the  
enclosing entry. Like this:

<feed>
   ...
   <entry>
     <id>...</id>
     <title>Alpha Fire</title>
     <summary>The Alpha Fire has burned 5 patches of land totaling 12  
hectares</summary>
     <link rel="alternate" href=".../alpha-fire/analysis.html"/>
     <georss:where>
       <!-- Bounding box metadata -->
       <gml:Polygon>...</gml:Polygon>
     </georss:where>
     <content type="application/vnd.ogc.gml">
       <!-- Detailed GML in here -->
     </content>
   </entry>
   ...
</feed>

Everything in the entry outside the content element is metadata.

Another nice feature of Atom is that is equally suited for delivering  
data to clients or servers (for storage).

Now, if you're actually more interested in delivering text content  
(not data) and using detailed multipart locations as metadata, that's  
a different problem, and one for which GeoRSS doesn't currently have a  
good solution.

Cheers,
Sean

> 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

[Ron Lake]

Hi,

Using GML you can do this quite easily. You would create a BurnedArea
feature type - this might have other properties besides the extent of
the burned area.  This might look something like:

<abc:BurnedArea gml:id="F1">
        <abc:extent>
                <gml:Polygon><gml:exterior>
                                        <gml:LinearRing><gml:posList> ..
coordinates .. <gml:posList><gml:<LinearRing>
                                 </gml:exterior>
                </gml:Polygon>
        </abc:extent>
        <abc:cause>Arson</abc:cause>
        <abc:date>12-01-98</abc:date>
</abc:BurnedArea>

Each BurnedArea would be assigned an identifier (gml:id).  

GML is quite extensive and offers many elements for describing geometry,
topology, time, units of measure etc.  You should note that there is a
simple profile of GML for RSS called GeoRSS GML (see
http://georss.org/gml  ).  This likely will fill of your needs.  Note
that GML encoding is a bit longer than simple GeoRSS because it can
handle things like polygons bounded by different curve types, and
polygons with holes etc.

Cheers

Ron

rlake@...


-----Original Message-----
From: georss-bounces@...
[mailto:georss-bounces@...] On Behalf Of Tim Leigh
Sent: February 24, 2009 8:57 PM
To: georss@...
Subject: [georss] Multiple geometries in an GeoRSS item

Hi

I work for a state government fire agency and we are keen to use GeoRSS
as a data distribution format.  One of our requirements is to embed
multiple geometries per RSS item (in our case burnt area for a fire).

Is the following valid GeoRSS (I can't find any online source to
determine yes or no)?

    <item>
      <title>..</title>
      <link>http://...</link>
      <category>..</category>
      <pubDate>..</pubDate>
      <description>...</description>
      <georss:point>[coordinate pairs]</georss:point>
      <georss:polygon[coordinate pairs]</georss:polygon>
      <georss:polygon[coordinate pairs]</georss:polygon>
      <georss:polygon>[coordinate pairs]</georss:polygon>
      <georss:polygon[coordinate pairs]</georss:polygon>
    </item>

Thanks for your help.

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

[Andrew Turner-8]

On Wed, Feb 25, 2009 at 12:37 PM, Ron Lake <rlake@...> wrote:
> Hi,
>
> Using GML you can do this quite easily. You would create a BurnedArea
> feature type - this might have other properties besides the extent of
> the burned area.  This might look something like:

This is *not* quite easy. Both from production and definitely
consumption side. It takes *5* nested elements to actually provide the
geographic information? Really?

Sean - re: putting the GML in the atom:content. Where would you
actually put the description or report? Summary is meant to be an
excerpt or abstract. This would be particularly troublesome when
simple readers then displayed the GML markup in the "View" of a
window.

What both of these suggestions is missing is understanding the
*simplest* use case, from a consumer's perspective. Someone can simply
subscribe to this URL in their vanilla feed reader and get a stream of
reports - without concern of geography. It also removes the need for
the developer to maintain 2 "feeds": GML complete and Atom with GML
content.

I'm still curious to hear back from Tim on his more explicit use case
of the multiple geometries.

Andrew

>
> <abc:BurnedArea gml:id="F1">
>        <abc:extent>
>                <gml:Polygon><gml:exterior>
>                                        <gml:LinearRing><gml:posList> ..
> coordinates .. <gml:posList><gml:<LinearRing>
>                                 </gml:exterior>
>                </gml:Polygon>
>        </abc:extent>
>        <abc:cause>Arson</abc:cause>
>        <abc:date>12-01-98</abc:date>
> </abc:BurnedArea>
>
> Each BurnedArea would be assigned an identifier (gml:id).
>
> GML is quite extensive and offers many elements for describing geometry,
> topology, time, units of measure etc.  You should note that there is a
> simple profile of GML for RSS called GeoRSS GML (see
> http://georss.org/gml  ).  This likely will fill of your needs.  Note
> that GML encoding is a bit longer than simple GeoRSS because it can
> handle things like polygons bounded by different curve types, and
> polygons with holes etc.
>
> Cheers
>
> Ron
>
> rlake@...
>
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
> Sent: February 24, 2009 8:57 PM
> To: georss@...
> Subject: [georss] Multiple geometries in an GeoRSS item
>
> Hi
>
> I work for a state government fire agency and we are keen to use GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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
>

--
Andrew Turner
mobile: [phone]
andrew@...
http://highearthorbit.com

http://geocommons.com           Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Sean Gillies]

No, the GeoRSS GML profile won't fill his needs because it doesn't  
cover heterogeneous geometry collections.

On Feb 25, 2009, at 10:37 AM, Ron Lake wrote:

> Hi,
>
> Using GML you can do this quite easily. You would create a BurnedArea
> feature type - this might have other properties besides the extent of
> the burned area.  This might look something like:
>
> <abc:BurnedArea gml:id="F1">
> <abc:extent>
> <gml:Polygon><gml:exterior>
> <gml:LinearRing><gml:posList> ..
> coordinates .. <gml:posList><gml:<LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </abc:extent>
> <abc:cause>Arson</abc:cause>
> <abc:date>12-01-98</abc:date>
> </abc:BurnedArea>
>
> Each BurnedArea would be assigned an identifier (gml:id).
>
> GML is quite extensive and offers many elements for describing  
> geometry,
> topology, time, units of measure etc.  You should note that there is a
> simple profile of GML for RSS called GeoRSS GML (see
> http://georss.org/gml  ).  This likely will fill of your needs.  Note
> that GML encoding is a bit longer than simple GeoRSS because it can
> handle things like polygons bounded by different curve types, and
> polygons with holes etc.
>
> Cheers
>
> Ron
>
> rlake@...
>
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
> Sent: February 24, 2009 8:57 PM
> To: georss@...
> Subject: [georss] Multiple geometries in an GeoRSS item
>
> Hi
>
> I work for a state government fire agency and we are keen to use  
> GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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

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

[Ron Lake]

Then use GML

R

-----Original Message-----
From: georss-bounces@...
[mailto:georss-bounces@...] On Behalf Of Sean Gillies
Sent: February 25, 2009 9:45 AM
To: GeoRss georss@...
Subject: Re: [georss] Multiple geometries in an GeoRSS item

No, the GeoRSS GML profile won't fill his needs because it doesn't  
cover heterogeneous geometry collections.

On Feb 25, 2009, at 10:37 AM, Ron Lake wrote:

> Hi,
>
> Using GML you can do this quite easily. You would create a BurnedArea
> feature type - this might have other properties besides the extent of
> the burned area.  This might look something like:
>
> <abc:BurnedArea gml:id="F1">
> <abc:extent>
> <gml:Polygon><gml:exterior>
> <gml:LinearRing><gml:posList> ..
> coordinates .. <gml:posList><gml:<LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </abc:extent>
> <abc:cause>Arson</abc:cause>
> <abc:date>12-01-98</abc:date>
> </abc:BurnedArea>
>
> Each BurnedArea would be assigned an identifier (gml:id).
>
> GML is quite extensive and offers many elements for describing  
> geometry,
> topology, time, units of measure etc.  You should note that there is a
> simple profile of GML for RSS called GeoRSS GML (see
> http://georss.org/gml  ).  This likely will fill of your needs.  Note
> that GML encoding is a bit longer than simple GeoRSS because it can
> handle things like polygons bounded by different curve types, and
> polygons with holes etc.
>
> Cheers
>
> Ron
>
> rlake@...
>
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
> Sent: February 24, 2009 8:57 PM
> To: georss@...
> Subject: [georss] Multiple geometries in an GeoRSS item
>
> Hi
>
> I work for a state government fire agency and we are keen to use  
> GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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

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

[Ron Lake]

Hi,

I don't see why heterogeneous geometry collections are needed?  Each BurnedArea is a GML feature instance.  The collection of BurnedAreas is a FeatureCollection.  GML FeatureCollections and full GML Polygon are supported in the GeoRSS GML profile.

R

-----Original Message-----
From: ajturner@... [mailto:ajturner@...] On Behalf Of Andrew Turner
Sent: February 25, 2009 9:44 AM
To: Ron Lake
Cc: Tim Leigh; georss@...
Subject: Re: [georss] Multiple geometries in an GeoRSS item

On Wed, Feb 25, 2009 at 12:37 PM, Ron Lake <rlake@...> wrote:
> Hi,
>
> Using GML you can do this quite easily. You would create a BurnedArea
> feature type - this might have other properties besides the extent of
> the burned area.  This might look something like:

This is *not* quite easy. Both from production and definitely
consumption side. It takes *5* nested elements to actually provide the
geographic information? Really?

Sean - re: putting the GML in the atom:content. Where would you
actually put the description or report? Summary is meant to be an
excerpt or abstract. This would be particularly troublesome when
simple readers then displayed the GML markup in the "View" of a
window.

What both of these suggestions is missing is understanding the
*simplest* use case, from a consumer's perspective. Someone can simply
subscribe to this URL in their vanilla feed reader and get a stream of
reports - without concern of geography. It also removes the need for
the developer to maintain 2 "feeds": GML complete and Atom with GML
content.

I'm still curious to hear back from Tim on his more explicit use case
of the multiple geometries.

Andrew

>
> <abc:BurnedArea gml:id="F1">
>        <abc:extent>
>                <gml:Polygon><gml:exterior>
>                                        <gml:LinearRing><gml:posList> ..
> coordinates .. <gml:posList><gml:<LinearRing>
>                                 </gml:exterior>
>                </gml:Polygon>
>        </abc:extent>
>        <abc:cause>Arson</abc:cause>
>        <abc:date>12-01-98</abc:date>
> </abc:BurnedArea>
>
> Each BurnedArea would be assigned an identifier (gml:id).
>
> GML is quite extensive and offers many elements for describing geometry,
> topology, time, units of measure etc.  You should note that there is a
> simple profile of GML for RSS called GeoRSS GML (see
> http://georss.org/gml  ).  This likely will fill of your needs.  Note
> that GML encoding is a bit longer than simple GeoRSS because it can
> handle things like polygons bounded by different curve types, and
> polygons with holes etc.
>
> Cheers
>
> Ron
>
> rlake@...
>
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
> Sent: February 24, 2009 8:57 PM
> To: georss@...
> Subject: [georss] Multiple geometries in an GeoRSS item
>
> Hi
>
> I work for a state government fire agency and we are keen to use GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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
>

--
Andrew Turner
mobile: [phone]
andrew@...
http://highearthorbit.com

http://geocommons.com           Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Sean Gillies]

On Feb 25, 2009, at 10:43 AM, Andrew Turner wrote:

> On Wed, Feb 25, 2009 at 12:37 PM, Ron Lake <rlake@...>  
> wrote:
>> Hi,
>>
>> Using GML you can do this quite easily. You would create a BurnedArea
>> feature type - this might have other properties besides the extent of
>> the burned area.  This might look something like:
>
> This is *not* quite easy. Both from production and definitely
> consumption side. It takes *5* nested elements to actually provide the
> geographic information? Really?
>
> Sean - re: putting the GML in the atom:content. Where would you
> actually put the description or report? Summary is meant to be an
> excerpt or abstract. This would be particularly troublesome when
> simple readers then displayed the GML markup in the "View" of a
> window.

Andrew, he said "data distribution", not "report distribution", and I  
took him literally. The solution is a little different in each case.  
I'll propose one for report distributions if Tim is interested.

A reader that disregards the content/@type attribute and dumps GML or  
anything that's not HTML/XHTML on a user is broken.

>
>
> What both of these suggestions is missing is understanding the
> *simplest* use case, from a consumer's perspective. Someone can simply
> subscribe to this URL in their vanilla feed reader and get a stream of
> reports - without concern of geography. It also removes the need for
> the developer to maintain 2 "feeds": GML complete and Atom with GML
> content.

But if you have data resources *and* report resources, you might need  
two feeds. The sources might be produced by different agencies, served  
from different domains, be updated asynchronously.

Sean

>
>
> I'm still curious to hear back from Tim on his more explicit use case
> of the multiple geometries.
>
> Andrew
>
>>
>> <abc:BurnedArea gml:id="F1">
>>        <abc:extent>
>>                <gml:Polygon><gml:exterior>
>>                                        
>> <gml:LinearRing><gml:posList> ..
>> coordinates .. <gml:posList><gml:<LinearRing>
>>                                 </gml:exterior>
>>                </gml:Polygon>
>>        </abc:extent>
>>        <abc:cause>Arson</abc:cause>
>>        <abc:date>12-01-98</abc:date>
>> </abc:BurnedArea>
>>
>> Each BurnedArea would be assigned an identifier (gml:id).
>>
>> GML is quite extensive and offers many elements for describing  
>> geometry,
>> topology, time, units of measure etc.  You should note that there  
>> is a
>> simple profile of GML for RSS called GeoRSS GML (see
>> http://georss.org/gml  ).  This likely will fill of your needs.  Note
>> that GML encoding is a bit longer than simple GeoRSS because it can
>> handle things like polygons bounded by different curve types, and
>> polygons with holes etc.
>>
>> Cheers
>>
>> Ron
>>
>> rlake@...
>>
>>
>> -----Original Message-----
>> From: georss-bounces@...
>> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
>> Sent: February 24, 2009 8:57 PM
>> To: georss@...
>> Subject: [georss] Multiple geometries in an GeoRSS item
>>
>> Hi
>>
>> I work for a state government fire agency and we are keen to use  
>> GeoRSS
>> as a data distribution format.  One of our requirements is to embed
>> multiple geometries per RSS item (in our case burnt area for a fire).
>>
>> Is the following valid GeoRSS (I can't find any online source to
>> determine yes or no)?
>>
>>    <item>
>>      <title>..</title>
>>      <link>http://...</link>
>>      <category>..</category>
>>      <pubDate>..</pubDate>
>>      <description>...</description>
>>      <georss:point>[coordinate pairs]</georss:point>
>>      <georss:polygon[coordinate pairs]</georss:polygon>
>>      <georss:polygon[coordinate pairs]</georss:polygon>
>>      <georss:polygon>[coordinate pairs]</georss:polygon>
>>      <georss:polygon[coordinate pairs]</georss:polygon>
>>    </item>
>>
>> Thanks for your help.
>>
>> 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
>>
>
>
>
> --
> Andrew Turner
> mobile: [phone]
> andrew@...
> http://highearthorbit.com
>
> http://geocommons.com           Helping build the Geospatial Web
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

--
Sean Gillies
sean.gillies@...
http://sgillies.net

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

[joshli]

Ron,

Use of a GML feature per se as below in the content of an Atom entry  
is exactly what both Sean and I have suggested. However, the GeoRSS  
profile of GML (http://georss.org/xml/1.1/gmlgeorss.xsd) specifically  
excludes multi-geometries and other curve types in order to enforce  
GeoRSS-like simplicity.

The feature could simply be inserted into the entry XML and doesn't  
have to be included in <atom:content> which some readers may expect to  
be HTML. Anything from an another namespace inside the <atom:entry>  
element is supposed be ignored by an Atom reader if it isn't understood.

You are right, though, that it could be a collection of features each  
with simple geometries instead.

Cheers,

Josh

On Feb 25, 2009, at 12:37 PM, Ron Lake wrote:

> Hi,
>
> Using GML you can do this quite easily. You would create a BurnedArea
> feature type - this might have other properties besides the extent of
> the burned area.  This might look something like:
>
> <abc:BurnedArea gml:id="F1">
> <abc:extent>
> <gml:Polygon><gml:exterior>
> <gml:LinearRing><gml:posList> ..
> coordinates .. <gml:posList><gml:<LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </abc:extent>
> <abc:cause>Arson</abc:cause>
> <abc:date>12-01-98</abc:date>
> </abc:BurnedArea>
>
> Each BurnedArea would be assigned an identifier (gml:id).
>
> GML is quite extensive and offers many elements for describing  
> geometry,
> topology, time, units of measure etc.  You should note that there is a
> simple profile of GML for RSS called GeoRSS GML (see
> http://georss.org/gml  ).  This likely will fill of your needs.  Note
> that GML encoding is a bit longer than simple GeoRSS because it can
> handle things like polygons bounded by different curve types, and
> polygons with holes etc.
>
> Cheers
>
> Ron
>
> rlake@...
>
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
> Sent: February 24, 2009 8:57 PM
> To: georss@...
> Subject: [georss] Multiple geometries in an GeoRSS item
>
> Hi
>
> I work for a state government fire agency and we are keen to use  
> GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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

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

[Ron Lake]

Hi Josh:

I understand that geoRSS GML does not support multiple geometries, nor
non-linear bounding curves and for this reason I suggested the solution
of encoding this as a feature collection.  Further, if the objective is
data transfer/distribution this approach allows other properties (e.g.
cause, date_of_fire etc) to be included in the payload.  I think we are
all in violent agreement?

Ron

-----Original Message-----
From: Joshua Lieberman [mailto:josh@...]
Sent: February 25, 2009 10:01 AM
To: Ron Lake
Cc: Tim Leigh; georss@...
Subject: Re: [georss] Multiple geometries in an GeoRSS item

Ron,

Use of a GML feature per se as below in the content of an Atom entry  
is exactly what both Sean and I have suggested. However, the GeoRSS  
profile of GML (http://georss.org/xml/1.1/gmlgeorss.xsd) specifically  
excludes multi-geometries and other curve types in order to enforce  
GeoRSS-like simplicity.

The feature could simply be inserted into the entry XML and doesn't  
have to be included in <atom:content> which some readers may expect to  
be HTML. Anything from an another namespace inside the <atom:entry>  
element is supposed be ignored by an Atom reader if it isn't understood.

You are right, though, that it could be a collection of features each  
with simple geometries instead.

Cheers,

Josh

On Feb 25, 2009, at 12:37 PM, Ron Lake wrote:

> Hi,
>
> Using GML you can do this quite easily. You would create a BurnedArea
> feature type - this might have other properties besides the extent of
> the burned area.  This might look something like:
>
> <abc:BurnedArea gml:id="F1">
> <abc:extent>
> <gml:Polygon><gml:exterior>
> <gml:LinearRing><gml:posList> ..
> coordinates .. <gml:posList><gml:<LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </abc:extent>
> <abc:cause>Arson</abc:cause>
> <abc:date>12-01-98</abc:date>
> </abc:BurnedArea>
>
> Each BurnedArea would be assigned an identifier (gml:id).
>
> GML is quite extensive and offers many elements for describing  
> geometry,
> topology, time, units of measure etc.  You should note that there is a
> simple profile of GML for RSS called GeoRSS GML (see
> http://georss.org/gml  ).  This likely will fill of your needs.  Note
> that GML encoding is a bit longer than simple GeoRSS because it can
> handle things like polygons bounded by different curve types, and
> polygons with holes etc.
>
> Cheers
>
> Ron
>
> rlake@...
>
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Tim Leigh
> Sent: February 24, 2009 8:57 PM
> To: georss@...
> Subject: [georss] Multiple geometries in an GeoRSS item
>
> Hi
>
> I work for a state government fire agency and we are keen to use  
> GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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

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

[crschmidt]

On Wed, Feb 25, 2009 at 10:04:55AM -0800, Ron Lake wrote:
> Hi Josh:
>
> I understand that geoRSS GML does not support multiple geometries, nor
> non-linear bounding curves and for this reason I suggested the solution
> of encoding this as a feature collection.  Further, if the objective is
> data transfer/distribution this approach allows other properties (e.g.
> cause, date_of_fire etc) to be included in the payload.  I think we are
> all in violent agreement?

Except me, but that's to be expected :)

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Ron Lake]

What is your disagreement?

R

-----Original Message-----
From: Christopher Schmidt [mailto:crschmidt@...]
Sent: February 25, 2009 10:18 AM
To: Ron Lake
Cc: Joshua Lieberman; Tim Leigh; georss@...
Subject: Re: [georss] Multiple geometries in an GeoRSS item

On Wed, Feb 25, 2009 at 10:04:55AM -0800, Ron Lake wrote:
> Hi Josh:
>
> I understand that geoRSS GML does not support multiple geometries, nor
> non-linear bounding curves and for this reason I suggested the
solution
> of encoding this as a feature collection.  Further, if the objective
is
> data transfer/distribution this approach allows other properties (e.g.
> cause, date_of_fire etc) to be included in the payload.  I think we
are
> all in violent agreement?

Except me, but that's to be expected :)

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[crschmidt]

On Wed, Feb 25, 2009 at 10:18:17AM -0800, Ron Lake wrote:
> What is your disagreement?

I think the way that the original poster has it encoded is perfectly
reasonable. Given that GeoRSS primarily defines a set of properties to
be attached to items, and does not primarily seek to describe RSS
itself, I don't see a problem with multiple georss:polygon elements
attached to a single item. Since it's unlikely that any non-custom
reader is going to be able to understand *any* of the stuff described
here, I don't see the multiple locations as being any different from
anything else from a practical standpoint.

So, I disagree that GML is a path worth travelling down. You're creating
a dataformat that requires a consumer to understand it. It doesn't hurt
anybody to just use multiple georss:geometry elements in your items.

I realize that this is not a purist view, and most people here probably
disagree with me, but I think that doing anything else is just
unneccesary.

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Ron Lake]

Hi Chris:

If the intent of the encoding is a private communication or is to be
interpreted by a knowledgeable human reader I agree with you.  One could
have (in GML) a BurnedAreas feature which has an extent property which
is multi-polygon valued also.  I think if you are actually trying to
describe and transmit information about a collection of BurnedAreas the
feature per BurnedArea is more appropriate.  I guess it is a question of
what you want to do.

R

-----Original Message-----
From: Christopher Schmidt [mailto:crschmidt@...]
Sent: February 25, 2009 10:45 AM
To: Ron Lake
Cc: Joshua Lieberman; Tim Leigh; georss@...
Subject: Re: [georss] Multiple geometries in an GeoRSS item

On Wed, Feb 25, 2009 at 10:18:17AM -0800, Ron Lake wrote:
> What is your disagreement?

I think the way that the original poster has it encoded is perfectly
reasonable. Given that GeoRSS primarily defines a set of properties to
be attached to items, and does not primarily seek to describe RSS
itself, I don't see a problem with multiple georss:polygon elements
attached to a single item. Since it's unlikely that any non-custom
reader is going to be able to understand *any* of the stuff described
here, I don't see the multiple locations as being any different from
anything else from a practical standpoint.

So, I disagree that GML is a path worth travelling down. You're creating
a dataformat that requires a consumer to understand it. It doesn't hurt
anybody to just use multiple georss:geometry elements in your items.

I realize that this is not a purist view, and most people here probably
disagree with me, but I think that doing anything else is just
unneccesary.

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Sean Gillies]

On Feb 25, 2009, at 11:44 AM, Christopher Schmidt wrote:

> On Wed, Feb 25, 2009 at 10:18:17AM -0800, Ron Lake wrote:
>> What is your disagreement?
>
> I think the way that the original poster has it encoded is perfectly
> reasonable. Given that GeoRSS primarily defines a set of properties to
> be attached to items, and does not primarily seek to describe RSS
> itself, I don't see a problem with multiple georss:polygon elements
> attached to a single item. Since it's unlikely that any non-custom
> reader is going to be able to understand *any* of the stuff described
> here, I don't see the multiple locations as being any different from
> anything else from a practical standpoint.
>
> So, I disagree that GML is a path worth travelling down. You're  
> creating
> a dataformat that requires a consumer to understand it. It doesn't  
> hurt
> anybody to just use multiple georss:geometry elements in your items.
>
> I realize that this is not a purist view, and most people here  
> probably
> disagree with me, but I think that doing anything else is just
> unneccesary.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta

I think multiple georss elements is a bad practice, Chris. Akin to  
putting multiple published or updated elements in an entry/item. The  
GeoRSS spec doesn't forbid it (which is a bug, IMO), but it's not  
something we should recommend.

--
Sean Gillies
sean.gillies@...
http://sgillies.net

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

[Tim Leigh]

Hi

Our use case for the multiple geometries are a point for the origin of a fire, and zero to many polygons for the burnt area/s of the fire.  As the point and all the polygons relate to the one fire incident (which may cover several distinct areas which do or do not overlap), I'd like to be able to encode all geometries in the one RSS item to avoid duplication or external linking.

As a side note, the google maps georss parser supports multiple geometries in georss using the simple profile which is our planned viewer of the georss feed.

As a developer I would prefer to use the simple method of encoding geometries for simplicity, however I couldn't find much detail in the XSD on georss.org for simple geometry encoding.  The GML profile XSD on georss.org does not appear to be specific about the number of geometries which may be encoded in an RSS item, as it seems I've opened a can of worms on this topic.

To sum up, could the simple profile XSD have the minoccurs and maxoccurs populated to avoid confusion?  Obviously I'd like to implement it as below, however it appears this will require further discussion.

Thanks

Tim

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://georss.org/georss" elementFormDefault="qualified" xmlns="http://georss.org/georss" xmlns:mstns="http://georss.org/georss" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="georss">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="point" type="doubleList" maxOccurs="unbounded" minOccurs="0" />
        <xs:element name="line" type="doubleList" maxOccurs="unbounded" minOccurs="0"/>
        <xs:element name="polygon" type="doubleList" maxOccurs="unbounded" minOccurs="0" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="doubleList">
    <xs:annotation>
      <xs:documentation>XML List based on XML Schema double type, identical to gml:doubleList.  An element of this type contains a space-separated list of double values</xs:documentation>
    </xs:annotation>
    <xs:list itemType="xs:double" />
  </xs:simpleType>
</xs:schema>


-----Original Message-----
From: ajturner@... [mailto:ajturner@...] On Behalf Of Andrew Turner
Sent: Thursday, February 26, 2009 12:42 AM
To: Tim Leigh
Cc: georss@...
Subject: Re: [georss] Multiple geometries in an GeoRSS item

As you can gather by the responses - it's not clear yet. As Chris
said, clients will most likely quietly ignore the other geometries.

To help the discussion, can you share what the multiple geometries
are? Part of a location hierarchy? Multiple locations found in the
content? That would help in the discussion.

Andrew


On Tue, Feb 24, 2009 at 11:56 PM, Tim Leigh <Tim.Leigh@...> wrote:

> Hi
>
> I work for a state government fire agency and we are keen to use GeoRSS
> as a data distribution format.  One of our requirements is to embed
> multiple geometries per RSS item (in our case burnt area for a fire).
>
> Is the following valid GeoRSS (I can't find any online source to
> determine yes or no)?
>
>    <item>
>      <title>..</title>
>      <link>http://...</link>
>      <category>..</category>
>      <pubDate>..</pubDate>
>      <description>...</description>
>      <georss:point>[coordinate pairs]</georss:point>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>      <georss:polygon>[coordinate pairs]</georss:polygon>
>      <georss:polygon[coordinate pairs]</georss:polygon>
>    </item>
>
> Thanks for your help.
>
> 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
>

--
Andrew Turner
mobile: [phone]
andrew@...
http://highearthorbit.com

http://geocommons.com           Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography
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,

Not to worry, the can of worms was opened a while ago. A look in the  
email archives will uncover long threads of discussion about how many  
geometries it makes sense to allow within a single RSS item / entry.

As far as the schema documents, they can only cover definition of the  
GeoRSS elements, not the rules for how they occur within a particular  
RSS encoding. <georss:georss> is not a part of GeoRSS and defeats the  
simplicity of GeoRSS Simple. So we can only state that only one GeoRSS  
Simple geometry should occur in an entry.

The GeoRSS schema does constrain one and only one choice of 5 gml  
geometries within georss:where for GeoRSS GML. You are of course free  
as far as an RSS format, e.g. Atom to add as many foreign elements as  
you like, and a robust parser will try to interpret as much as it can,  
however it does go against the letter and spirit of the spec to expect  
that all GeoRSS readers must parse and interpret multiple geometries  
in order to make sense of your feed.

Cheers,

Josh


On Feb 25, 2009, at 11:32 PM, Tim Leigh wrote:

> Hi
>
> Our use case for the multiple geometries are a point for the origin  
> of a fire, and zero to many polygons for the burnt area/s of the  
> fire.  As the point and all the polygons relate to the one fire  
> incident (which may cover several distinct areas which do or do not  
> overlap), I'd like to be able to encode all geometries in the one  
> RSS item to avoid duplication or external linking.
>
> As a side note, the google maps georss parser supports multiple  
> geometries in georss using the simple profile which is our planned  
> viewer of the georss feed.
>
> As a developer I would prefer to use the simple method of encoding  
> geometries for simplicity, however I couldn't find much detail in  
> the XSD on georss.org for simple geometry encoding.  The GML profile  
> XSD on georss.org does not appear to be specific about the number of  
> geometries which may be encoded in an RSS item, as it seems I've  
> opened a can of worms on this topic.
>
> To sum up, could the simple profile XSD have the minoccurs and  
> maxoccurs populated to avoid confusion?  Obviously I'd like to  
> implement it as below, however it appears this will require further  
> discussion.
>
> Thanks
>
> Tim
>
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema targetNamespace="http://georss.org/georss"  
> elementFormDefault="qualified" xmlns="http://georss.org/georss"  
> xmlns:mstns="http://georss.org/georss" xmlns:xs="http://www.w3.org/2001/XMLSchema 
> ">
> <xs:element name="georss">
>   <xs:complexType>
>     <xs:sequence>
>       <xs:element name="point" type="doubleList"  
> maxOccurs="unbounded" minOccurs="0" />
>       <xs:element name="line" type="doubleList"  
> maxOccurs="unbounded" minOccurs="0"/>
>       <xs:element name="polygon" type="doubleList"  
> maxOccurs="unbounded" minOccurs="0" />
>     </xs:sequence>
>   </xs:complexType>
> </xs:element>
> <xs:simpleType name="doubleList">
>   <xs:annotation>
>     <xs:documentation>XML List based on XML Schema double type,  
> identical to gml:doubleList.  An element of this type contains a  
> space-separated list of double values</xs:documentation>
>   </xs:annotation>
>   <xs:list itemType="xs:double" />
> </xs:simpleType>
> </xs:schema>
>
>
> -----Original Message-----
> From: ajturner@... [mailto:ajturner@...] On Behalf Of  
> Andrew Turner
> Sent: Thursday, February 26, 2009 12:42 AM
> To: Tim Leigh
> Cc: georss@...
> Subject: Re: [georss] Multiple geometries in an GeoRSS item
>
> As you can gather by the responses - it's not clear yet. As Chris
> said, clients will most likely quietly ignore the other geometries.
>
> To help the discussion, can you share what the multiple geometries
> are? Part of a location hierarchy? Multiple locations found in the
> content? That would help in the discussion.
>
> Andrew
>
>
> On Tue, Feb 24, 2009 at 11:56 PM, Tim Leigh  
> <Tim.Leigh@...> wrote:
>> Hi
>>
>> I work for a state government fire agency and we are keen to use  
>> GeoRSS
>> as a data distribution format.  One of our requirements is to embed
>> multiple geometries per RSS item (in our case burnt area for a fire).
>>
>> Is the following valid GeoRSS (I can't find any online source to
>> determine yes or no)?
>>
>>   <item>
>>     <title>..</title>
>>     <link>http://...</link>
>>     <category>..</category>
>>     <pubDate>..</pubDate>
>>     <description>...</description>
>>     <georss:point>[coordinate pairs]</georss:point>
>>     <georss:polygon[coordinate pairs]</georss:polygon>
>>     <georss:polygon[coordinate pairs]</georss:polygon>
>>     <georss:polygon>[coordinate pairs]</georss:polygon>
>>     <georss:polygon[coordinate pairs]</georss:polygon>
>>   </item>
>>
>> Thanks for your help.
>>
>> 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
>>
>
>
>
> --
> Andrew Turner
> mobile: [phone]
> andrew@...
> http://highearthorbit.com
>
> http://geocommons.com           Helping build the Geospatial Web
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
> 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