[georss] Time and Space - again

Ron Lake rlake at galdosinc.com
Tue Feb 13 18:25:39 EST 2007 

Hi,

See comments below.

Ron

-----Original Message-----
From: georss-bounces at lists.eogeo.org
[mailto:georss-bounces at lists.eogeo.org] On Behalf Of josh at oklieb.net
Sent: February 13, 2007 8:44 AM
To: georss at lists.eogeo.org
Subject: Re: [georss] Time and Space - again

Brian,

I would be surprised if even much GML software was ready to handle some
of
the time aspects at this point, let alone GeoRSS software. So we do have
a
considerable issue of complexity in that realm.  Also, as Raj and I both
mentioned, it is one thing to have a GML application schema with a
variety
of expressive geometry properties. It is another to overload
georss:where
such that it requires detailed inside knowledge to understand what is
meant by multiple geometries and time slices.

We try always to think of GeoRSS feeds as information packets which may
"escape into the wild" and be usable in some form in anyone's reader,
rather than as point-to-point update transactions (although they also
can
be useful that way).

My recommendations are as follows:

1) Stick with one georss:where and one geometry per (atom) entry. Use
the
entries to express your changes through time. One can, for example, use
atom:id to group events together which form a sequence with different
timestamps. It makes sense to add either OWL-TIME terms or georss:when +
gml:TimePeriod  to each entry alongside georss:where in order to provide
a
more exact time definition for the entry.

[RTL]  This is consistent with the idea of keeping GeoRSS simple.

2) If you really need the expressiveness of a full GML dynamic feature,
use an element such as georss:featureOfInterest to incorporate a feature
from your own application schema where the syntax and semantic of a
sequence of geometries through time along with other dynamic feature
properties is fully defined. In that case, it would be wise to include
an
overall envelope or such (e.g. georss:box) in each entry so that generic
georss readers can do something with it as well. Expected software
behavior is to ignore additional elements which are  not understood, so
complex extensions are fine as long as there is something simpler which
can give something to work with.

[RTL] Makes sense to me.  Otherwise you risk a duplication of effort in
geoRSS and lose the original intended simplicity.

I'd be happy to consider adding georss:when and georss:featureOfInterest
elements, not so happy to complicate the existing georss:where element
with multiple geometries or arbitrary GML.

Sidenote: the current (1.1) proposed schema provides only a choice of
instance of one geometry per georss:where element. I am not sure it
makes
sense to allow more than one type (e.g. one point, one polygon) without
providing some way of deciding between them (e.g. min-max scale).

[RTL]  Ineed.


Comments?

Cheers,

Josh

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