[georss] Time and Space - Vote Tally
Knoth, Brian D.
bknoth at mitre.org
Mon Mar 5 08:37:26 EST 2007
Raj,
Are you saying that you voted against the suggestion before you voted
for the suggestion? I'm not sure that the vote matters anymore. I was
hoping to get a recommendation for this fairly quickly but I see it's
not going to be easy to reach consensus.
My suggestions for the time period specification have been the
following:
1. Allow for gml:EnvelopeWithTimePeriod within the geoRSS GML profile.
2. Allow for external namespace global attributes in the
<georss:where> element to specify time period begin and end. (No
changes to existing GML profile)
3. Add optional attributes georss:begin and georss:end to the geoRSS
application profile
I've received many alternatives, however, to me they boil down to one
of either:
1. Use one item per geo-location and use time/dates of the item as
time periods
2. Create my own (or utilize exiting) extensions that captures the
information needed and don't use geoRSS.
I've posted some reasons, in our case, which make #1 very difficult and
I'm hoping to avoid #2.
As I've said before, I have an increasingly smaller window to affect
how our contractor implements its location data publishing with RSS. It
seems that I'm not the only one who would like to see similar support
in geoRSS, so if I could get any insight as to the most favorable way
forward for geoRSS with respect to this then we could continue to
leverage this specification.
I'm hoping otherwise, but if the answer is that I've gotten all the
suggestions I can get and there's nothing with the spec that will
change to adopt these requirements then I'll go away now.
Thanks again,
brian
-----Original Message-----
From: georss-bounces at lists.eogeo.org
[mailto:georss-bounces at lists.eogeo.org] On Behalf Of Raj Singh
Sent: Monday, March 05, 2007 12:52 AM
To: Allan Doyle
Cc: georss at lists.eogeo.org
Subject: Re: [georss] Time and Space - Vote Tally
I just voted and noticed there are 9 votes now. Both new ones are -0.
One of those was mine, but in hindsight I should have voted -1 since
I have already posted arguments against.
---
Raj
On Feb 19, 2007, at 10:51 AM, Allan Doyle wrote:
> So, the votes are "in": http://www.yourfreepoll.com/vmarsybosr.html
>
> +1 - 2
> +0 - 2
> 0 - 1
> -0 - 1
> -1 - 1
> Total votes: 7
>
> The +1 and -1 voters owe a message to the group identifying
> themselves.
>
> There are 135 subscribers on this mailing list. Even accounting for
> people signed up with more than one email address, it would be safe
> to say that 7 votes represents no more than 6% of the people.
(http://
> lists.eogeo.org/mailman/listinfo/georss)
>
> Thus the remaining 94% can be considered "0" votes.
>
> You can make of this what you will. My personal opinion is that this
> is not enough support to warrant a spec change.
>
> Allan
>
>
> On Feb 14, 2007, at 10:20, Allan Doyle wrote:
>
>> I would be most interested in an outcome that reflects the "rough
>> consensus and running code" mantra. I.e. no spec changes without
>> independent implementations that interoperate. Thus, the question
>> would be whether there would be at least two independent services
out
>> there generating this and/or two independent clients consuming it.
If
>> not, then it would seem to me that no spec change is needed.
>>
>> To that end, I've created a poll. Let's see if this can help us
>> figure out how close anyone is to agreement on this. It may help
>> reduce Jeff's email load.
>>
>> How about if people vote before ~midnight on Sunday in your own time
>> zone, then on Monday, we can peek at the vote and start another
email
>> barrage?
>>
>> Vote: http://www.yourfreepoll.com/vmarsybosp.html
>> Results: http://www.yourfreepoll.com/vmarsybosr.html
>>
>> Allan
>>
>>
>> On Feb 14, 2007, at 09:45, Knoth, Brian D. wrote:
>>
>>> Right, so on that note, I'll wrap it up.
>>>
>>> To summarize:
>>>
>>> - we have a project in which we would like to associate multiple
>>> timewindows/positions with items using geoRSS
>>>
>>> - we started out with an extension to the <georss:where> which, in
>>> retrospect, does not seem consistent with the original intent of
the
>>> spec
>>>
>>> - instead, I would like to suggest an additional geometry, namely
>>> gml:EnvelopeWithTimePeriod, be added to the GML geoRSS profile
>>>
>>> - I previously offered up a new gmlgeorss.xsd with this extension
>>> made
>>> and, if accepted by majority consensus, I'd like to understand
>>> how to
>>> get the changes posted to the geoRSS website in order to point
>>> developers to.
>>>
>>> I have appreciate everyone's feedback on this and hopefully I can
>>> just
>>> get confirmation as to whether my suggestions can be incorporated
or
>>> not.
>>>
>>> Thanks,
>>> brian
>>>
>>> -----Original Message-----
>>> From: Jeff Harrison [mailto:jharrison at thecarbonproject.com]
>>> Sent: Tuesday, February 13, 2007 8:11 PM
>>> To: 'Ron Lake'; Knoth, Brian D.; 'Mikel Maron';
>>> georss at lists.eogeo.org
>>> Subject: RE: [georss] Time and Space
>>>
>>> This email thread is taking up a lot of "Time and Space"
>>>
>>> Jeff
>>>
>>> -----Original Message-----
>>> From: georss-bounces at lists.eogeo.org
>>> [mailto:georss-bounces at lists.eogeo.org]
>>> On Behalf Of Ron Lake
>>> Sent: Tuesday, February 13, 2007 8:05 PM
>>> To: Knoth, Brian D.; Mikel Maron; georss at lists.eogeo.org
>>> Subject: Re: [georss] Time and Space
>>>
>>> Hi,
>>>
>>> All I could see in your last email example was the use of a text
>>> description. Is that what you meant?
>>>
>>> R
>>>
>>> -----Original Message-----
>>> From: Knoth, Brian D. [mailto:bknoth at mitre.org]
>>> Sent: February 13, 2007 4:45 PM
>>> To: Ron Lake; Mikel Maron; georss at lists.eogeo.org
>>> Subject: RE: [georss] Time and Space
>>>
>>> The example I had in mind I did specify in my last email.
>>>
>>> brian
>>>
>>> -----Original Message-----
>>> From: Ron Lake [mailto:rlake at galdosinc.com]
>>> Sent: Tuesday, February 13, 2007 5:57 PM
>>> To: Knoth, Brian D.; Mikel Maron; georss at lists.eogeo.org
>>> Subject: RE: [georss] Time and Space
>>>
>>> Could you give an example of this? - I would not use description
>>> since
>>> it is totally open ended!
>>>
>>> R
>>>
>>> -----Original Message-----
>>> From: Knoth, Brian D. [mailto:bknoth at mitre.org]
>>> Sent: February 13, 2007 11:02 AM
>>> To: Ron Lake; Mikel Maron; georss at lists.eogeo.org
>>> Subject: RE: [georss] Time and Space
>>>
>>> Ron,
>>>
>>> I believe that "role" of a geometry can already be conveyed within
>>> the
>>> existing GML geoRSS profile. There are description/name/metadata
>>> elements associated with every geometry at the abstract base
>>> level. I
>>> would think these elements could be used to pass additional
>>> information
>>> like role to consumers. Based off my previous example, here is
>>> what I
>>> am thinking (note: allowing multiple geometries within a where
>>> node):
>>>
>>>
>>> <item>
>>> <title>Flight 1995</title>
>>> <link>http://..flightdetails</link>
>>> <description>some desc</description>
>>> <guid
>>> isPermaLink="false">id:flight-0A05000760l02yz</guid>
>>> <pubDate>2006-03-02T20:36:12Z</pubDate>
>>> <georss:where
>>> xmlns:georss="http://www.georss.org/georss">
>>> <gml:Point
>>> xmlns:gml="http://www.opengis.net/gml">
>>>
>>> <gml:description>takeoff</gml:description>
>>> <gml:pos>30.8944
>>> -124.5270</gml:pos>
>>> </gml:Point>
>>> <gml:Envelope
>>> xmlns:gml="http://www.opengis.net/gml">
>>> <gml:description>turn point
>>> A</gml:description>
>>> <gml:lowerCorner>43.8944
>>> -123.5270</gml:lowerCorner>
>>> <gml:upperCorner>44.3444
>>> -122.9002</gml:upperCorner>
>>> </gml:Envelope>
>>> <gml:EnvelopeWithTimePeriod
>>> xmlns:gml="http://www.opengis.net/gml">
>>>
>>> <gml:description>rendezous</gml:description>
>>> <gml:lowerCorner>30.8944
>>> -107.5270</gml:lowerCorner>
>>> <gml:upperCorner>35.3444
>>> -108.9002</gml:upperCorner>
>>> <gml:timePosition
>>> indeterminatePosition="before">2006-03-02T21:30:00Z</
>>> gml:timePosition>
>>> <gml:timePosition
>>> indeterminatePosition="after">2006-03-02T21:40:00Z</
>>> gml:timePosition>
>>> </gml:EnvelopeWithTimePeriod>
>>>
>>> </georss:where>
>>> </item>
>>>
>>> Regards,
>>> brian
>>> ________________________________
>>>
>>> From: Ron Lake [mailto:rlake at galdosinc.com]
>>> Sent: Tuesday, February 13, 2007 11:32 AM
>>> To: Mikel Maron; Knoth, Brian D.; georss at lists.eogeo.org
>>> Subject: RE: [georss] Time and Space
>>>
>>>
>>>
>>> Mike:
>>>
>>>
>>>
>>> If you do that - allow multiple geometries inside a single
>>> "where" property - how does anyone know what they mean? In GML a
>>> property (like where) is used to describe the role of the geometry
-
>>> e.g.
>>>
>>>
>>>
>>> <abc:centerLine>
>>>
>>> <gml:LineString> ... </gml:LineString>
>>>
>>> </abc:centerLine>
>>>
>>> <abc:position>
>>>
>>> <gml:Point>... </gml:Point>
>>>
>>> </abc:Point>
>>>
>>>
>>>
>>> How does that work in GeoRSS? How do you know the roles of
>>> Point and LineString otherwise?
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>> Ron
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: georss-bounces at lists.eogeo.org
>>> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Mikel Maron
>>> Sent: February 12, 2007 11:50 AM
>>> 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&sessionI
>>> d=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_feeds.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
>>
>> --
>> Allan Doyle
>> +1.781.433.2695
>> adoyle at eogeo.org
>>
>>
>>
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>
> --
> Allan Doyle
> +1.781.433.2695
> adoyle at eogeo.org
>
>
>
> _______________________________________________
> 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