[georss] Multiple Locations and Time

Fri Mar 9 11:06:40 EST 2007

Just to stir the pot a pit, this morning there has been an interesting 
dialogue on an European SDI email list. There was a posting from a professor 
who participates in  the Center for Visualization at a major university in 
Spain. This is his email and thoughts on temporal:

"It depends on what type of glasses you are wearing, I guess. We have
colleagues in the department who analyze temporal data...in many ways we are
doing the same thing except that we do x,y,(sometimes z), and they do t.

They are amazed at how blind our field is to time. "Everything is 
temporal!!!""

Cheers

Carl

----- Original Message ----- 
From: "Knoth, Brian D." <bknoth at mitre.org>
To: "Ron Lake" <rlake at galdosinc.com>; "Andrew Turner" 
<ajturner at highearthorbit.com>; "Raj Singh" <raj at rajsingh.org>
Cc: <georss at lists.eogeo.org>
Sent: Thursday, March 08, 2007 10:03 AM
Subject: Re: [georss] Multiple Locations and Time

> Ron:
>
> Yes, I can understand that if all the geometries happen at the same
> time. In that case, couldn't the georss:relationshipTag specify the
> role as related to the item? In a case, however, where each geometry
> occurs during different and distinct time periods, wouldn't that simply
> represent the location of the item historically, current, and future?
>
> Regards,
> brian
>
> -----Original Message-----
> From: Ron Lake [mailto:rlake at galdosinc.com]
> Sent: Thursday, March 08, 2007 11:58 AM
> To: Knoth, Brian D.; Andrew Turner; Raj Singh
> Cc: georss at lists.eogeo.org
> Subject: RE: [georss] Multiple Locations and Time
>
> Hi Brian:
>
> I think the meaning of <where> becomes ambiguous when you add multiple
> where properties or in the case of the <where> containing multiple
> geometries.  I think additional terms are required to make it clear
> what
> is the role of each geometry.
>
> Cheers
>
> Ron
>
>
> -----Original Message-----
> From: Knoth, Brian D. [mailto:bknoth at mitre.org]
> Sent: March 8, 2007 12:14 AM
> To: Ron Lake; Andrew Turner; Raj Singh
> Cc: georss at lists.eogeo.org
> Subject: RE: [georss] Multiple Locations and Time
>
> Hi Ron,
>
> I'm not sure I understand what you mean by semantic restrictions of a
> single where element. Could you briefly elaborate on that a little?
>
> The point that I'm trying to make is that the RSS 2.0 (and I would
> think Atom as well) specification does not prohibit multiple nodes of
> the same name. I believe this is only restricted in wording of the
> georss specification. So, Andrew's example of:
>
> <georss:where>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
> </georss:where>
>
> Could also be represented as:
>
> <item>
> <georss:where>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
> </georss:where>
> <georss:where>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
> </georss:where>
> <georss:where>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
> </georss:where>
> </item>
>
> Also without needing to add any new support to existing clients (they
> can just continue to get the first one), however, it allows support for
> the existing attributes of <georss:where> to be specific to each
> particular location, rather than to a complete set. Ie, the radius of
> the second point might be different than the radius of the first. Also,
> if we could get time attributes added, like I hope, then likewise those
> time periods become applicable to the specific location enclosed in the
> where node.
>
> brian
>
> -----Original Message-----
> From: Ron Lake [mailto:rlake at galdosinc.com]
> Sent: Wednesday, March 07, 2007 1:25 PM
> To: Knoth, Brian D.; Andrew Turner; Raj Singh
> Cc: georss at lists.eogeo.org
> Subject: RE: [georss] Multiple Locations and Time
>
> Hi,
>
> I think you running into the semantic restrictions of having a single
> property (where) - I think the issue is more than just the multiplicity
> of the where element or the contained Point etc elements.
>
> Ron
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Knoth, Brian D.
> Sent: March 7, 2007 2:46 AM
> To: Andrew Turner; Raj Singh
> Cc: georss at lists.eogeo.org
> Subject: Re: [georss] Multiple Locations and Time
>
> Andrew:
>
> I feel that the multi-location representation *and* time representation
> need to be solved simultaneously. I think it would be rare to have one
> without the other.
>
> To have least impact on programmers, I would think that just allowing
> multiple <georss:where> elements within an RSS item with optional time
> attributes for that <georss:where> node would provide that.  Multiple
> <georss:where> is just simply a wording restriction and not a
> specification restriction in RSS, right?
>
> brian
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Andrew Turner
> Sent: Tuesday, March 06, 2007 6:05 PM
> To: Raj Singh
> Cc: georss at lists.eogeo.org
> Subject: [georss] Multiple Locations and Time
>
> On 3/3/07, Raj Singh <raj at rajsingh.org> wrote:
>>
>> or for multi-geometry objects (simplefeature alludes to the
>> geometries allowed in the GML Simple Features specification available
>> here: http://www.opengeospatial.org/standards/gml)
>>
>> <georss:where>
>>     <georss:simplefeature>
>>        <gml:MultiPoint>...
>>        <gml:MultiPoint>...
>>        <gml:MultiPoint>...
>>     <georss:simplefeature>
>> <georss:where>
>>
>> Encapsulating and naming functionality this way makes it easier for
>> parsers to find the bits they can't handle, and for developers to
>> make decisions about what to support.
>
>
> Eep! adding *more* elements to have to put into a program and parse?
> That's definitely getting a lot more complex.
>
> As a programmer, I can imagine multiple geometries just being that,
> multiple geometries with no special encoding.
> <georss:point/>
> <georss:point/>
> <georss:point/>
>
> or
> <georss:where>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
>   <gml:Point><gml:pos>45.256 -71.92</gml:pos></gml:Point>
> </georss:where>
>
> because most XML parsers you'll use can easily just handle getting all
> the elements like */georss:where/gml:Point, which in this case would
> return an Array rather than a single point. So instead of plotting the
> single point, I walk the array and plot the array.That's a very
> "programming-centric" argument, but I think that's really who you end
> up addressing when you talk about expanding/changing a standard,
> programmers supporting it. :)
>
> Not only that, if you run into a parser that assumes a single point,
> worst case is you just get one point, but don't lose the entire
> geometry.
>
> Andrew
> _______________________________________________
> 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 