[georss] Time and Space

Knoth, Brian D. bknoth at mitre.org
Tue Feb 13 07:24:57 EST 2007


Raj,

I'm definitely no expert in GML profiling, but I know that we have some
other teams looking at a GML profile for other purposes and they are
using the gml:EnvelopeWithTimePeriod to associate time with spatial
boundaries.

My personal opinion, is that if the GML geoRSS profile were to include
the gml:EnvelopeWith TimePeriod object, then it is a pretty fair
adjustment for increasing expressiveness while still keeping the
profile simple. Although, it would mean that one could not associate
time with any arbitrary shape (point, polyline, etc), they could
associate with essentially a cube which might be a fair tradeoff. 

The only other adjustment would then be, as you mention, a need to
allow for multiple geometries within the <georss:where> node.

I am really glad to have gotten some of this discussion vetted out with
you and others, but I am running into a problem of time (meaning,
schedule, not georss). I'd like to have some direction with which to
build a solution to right now, hopefully, one that the GML geoRSS spec
would be planning to incorporate. Right now, that solution is the
TimePeriod one that I posed to this newsgroup initially, but I have a
small window to alter that if yourself and others can provide guidance
as to what you feel the right approach with the spec would be.

Appreciate all feedback and help,

brian

-----Original Message-----
From: Raj Singh [mailto:raj at rajsingh.org] 
Sent: Monday, February 12, 2007 4:56 PM
To: Knoth, Brian D.
Cc: Mikel Maron; georss at lists.eogeo.org
Subject: Re: [georss] Time and Space

Brian's right about having one GML geometry in <georss:where>. The  
real issue here is universal interoperability. The more we expand the  
functionality of generic GeoRSS the harder it is for software  
developers to handle any GeoRSS they come across. It's already been  
hard to get people to support GeoRSS GML in its current state. That's  
why I hesitate to add major new features to the basic spec.

However, everyone knows generic functionality never works for  
everyone, and I think we always envisioned extensions to GeoRSS. This  
is probably a good point to start framing the discussion in terms of  
a GeoRSS Time extension, and think about what information a generic  
GeoRSS client would get from a time-enabled feed as well as defining  
a robust time extension. Defining that extension should probably  
support multiple GML geometries and look at the time proposals Mikel  
mentions.
---
Raj


On Feb 12, 2007, at 2:58 PM, Knoth, Brian D. wrote:

> Mikel,
>
> What you say in your second paragraph is exactly what we are  
> looking for (well, with the addition of time also), but I'm a  
> little confused by it because I thought that the GML geoRSS was  
> defined to be only those GML elements defined here: http:// 
> www.georss.org/gml.html and not "any" GML payload. Also, I did not  
> think that multiple ones could be present in there.
>
> Could you give me a specific example of a <georss:where> node with  
> multiple geometries and is compliant with the GML geoRSS definition?
>
> thanks,
> brian
>
> From: Mikel Maron [mailto:mikel_maron at yahoo.com]
> Sent: Monday, February 12, 2007 2:50 PM
> To: Knoth, Brian D.; georss at lists.eogeo.org
> Subject: Re: [georss] Time and Space
>
> Brian
>
> There was a thread on this last month that went into the issues ..  
> http://lists.eogeo.org/pipermail/georss/2007-January/
>
> But I should've been more specific .. you can include any kind of  
> GML payload in GeoRSS GML, which could have multiple geometries,
> but those all would be included in a single georss:where.
>
> -Mikel
>
>
> ----- Original Message ----
> From: "Knoth, Brian D." <bknoth at mitre.org>
> To: Mikel Maron <mikel_maron at yahoo.com>; georss at lists.eogeo.org
> Sent: Monday, February 12, 2007 7:41:39 PM
> Subject: RE: [georss] Time and Space
>
> Mikel,
>
> I'll take a look at your links in a moment, but just quickly wanted  
> to respond to the issue of not being able to have multiple  
> <georss:where> nodes under an <item>. I know that I read this  
> restriction somewhere else and my only question is simply why not?   
> I don't know of any restriction defined in the RSS specification  
> that limits child elements to only a single occurrence, is there?
>
> thanks,
> brian
>
> From: Mikel Maron [mailto:mikel_maron at yahoo.com]
> Sent: Monday, February 12, 2007 2:38 PM
> To: Knoth, Brian D.; georss at lists.eogeo.org
> Subject: Re: [georss] Time and Space
>
> Hi Brian
>
> I'm very interested in incorporating time, visualizing and acting  
> on change. Gave a presentation outlining some thoughts on this      
> foss4g..
> http://www.foss4g2006.org/contributionDisplay.py? 
> contribId=161&sessionId=47&confId=1
>
> Like Raj, I think time could be seen as having wider application  
> than just space. I've re-used the RSS and Atom time-oriented fields  
> for some
> basic stuff.
>
> http://worldkit.org/doc/time.php
>
> For richer time specifications, there hasn't been agreement on a  
> single encoding. Upcoming.org has a bit to say on this..
>
> http://community.upcoming.org/w/index.php/ 
>
Nerdy_Questions#What_are_the_guidelines_you_follow_when_creating_RSS_f 
> eeds.3F
>
> They're using xCal. There's also an old RSS 1.0 module called  
> Event .. http://web.resource.org/rss/1.0/modules/event/
>
>
> While writing this I just saw your followup. One thing about your  
> usage, you can't associate multiple georss:where elements with a  
> single item;
> it's a one to one relationship.
>
> Best
> -Mikel
>
> ----- Original Message ----
> From: "Knoth, Brian D." <bknoth at mitre.org>
> To: georss at lists.eogeo.org
> Sent: Monday, February 12, 2007 1:40:54 PM
> Subject: [georss] Time and Space
>
> Hi,
>
> I'm new to this mailing list, yet have been advocate of RSS and
geoRSS
> on some internal projects for a while. I do have a few concerns with
> regard to real practical acceptance of geoRSS, yet, I understand the
> need to try and balance simplicity and expressiveness. As such, we
are
> attempting to utilize GML geoRSS, however, we have needed to extend  
> the
> GML geoRSS with the ability identify time as well as space.
>
> I wanted to just send out our approach to doing this to get comments
> from anyone else who might be interested in this on the mailing list.
> Simply put, we have added a GML TimePeriod to each of the geoRSS
nodes
> along with the spatial representation. Here is an example:
>
> <georss:where>
>     <gml:TimePeriod>
>            <gml:begin>2006-06-17T09:55:00Z</gml:begin>
>         <gml:end>2006-06-17T10:30:00Z</gml:end>
>     </gml:TimePeriod>
>     <gml:Point>
>         <gml:pos>37.65356495497155 -114.5048399056895</gml:pos>
>     </gml:Point>
> </georss:where>
>
> All comments would be appreciated.
>
> Regards,
> brian
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss




More information about the georss mailing list