[georss] What's next--a query API

Pat Cappelaere pat at cappelaere.com
Mon May 8 23:24:09 EDT 2006


Jeff,

I truly follow you.  We are doing something similar for the EO1 GeoBliki.
We have EO1 GeoRSS data feeds that are stored locally (as well as being
published to interested parties).
As soon as you open pandora's box and provide BBOX queries.  The next thing
is the timespan query, then ... the keyword query.
So you quickly end up having to support a subset of the filter spec (might
as well to avoid reinventing the wheel)
So you quickly end up with a WFS.  Since users make comments you need
transactions...
Thematic content segregation is provided by using categories (built into
ATOM spec).  It turns out that they happen to be the "features"... Small
world...

Pat/ 

> From: Jeff Harrison <jharrison at thecarbonproject.com>
> Date: Mon, 8 May 2006 23:03:11 -0400
> To: 'Pat Cappelaere' <pat at cappelaere.com>, 'Ron Lake' <rlake at galdosinc.com>,
> 'Raj Singh' <raj at rajsingh.org>, 'Danny Ayers' <danny.ayers at gmail.com>,
> <georss at lists.eogeo.org>
> Subject: RE: [georss] What's next--a query API
> 
> Pat,
> 
> I wouldn't want to make folks that are interested in creating a geoRSS
> "FeedReader" have to stand up a WFS Transactional to read/write geoRSS :)
> But adopting the grammar from existing specs is a good idea for
> interoperability and rapid adoption.
> 
> I think keeping the focus on 'BBOX queries' would be desirable since this
> seems to be the most straightforward method to meet requirements and ensure
> rapid adoption in many different types of software.
> 
> As for querying a geoRSS "Aggregator" it might be simpler (at least
> initially) for content providers to break thematic geoRSS content into
> separate feeds (Weather, Traffic, Yard Sales, etc.). Don't know for sure
> though.
> 
> Regards,
> Jeff
> 
> 
> 
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org [mailto:georss-bounces at lists.eogeo.org]
> On Behalf Of Pat Cappelaere
> Sent: Monday, May 08, 2006 9:05 PM
> To: Ron Lake; Raj Singh; Danny Ayers; georss at lists.eogeo.org
> Subject: Re: [georss] What's next--a query API
> 
> GeoRSS enabled software would store GeoRSS feeds in a WFS (or equivalent).
> Users could then do spatio-temporal queries (why stop at BBOX queries!) and
> keyword search based on contents of the feed.
> For instance, a user could specify start/end time and/or BBOX and/or
> keywords and retrieve the information based on the GeoRSS feeds that have
> been collected/aggregated.
> 
> As Ron said, this is in the WFS domain with the filter specification to
> retrieve the information.
> 
> V/R
> Pat.
> 
> 
>> From: Ron Lake <rlake at galdosinc.com>
>> Date: Mon, 8 May 2006 17:51:48 -0700
>> To: Raj Singh <raj at rajsingh.org>, Danny Ayers <danny.ayers at gmail.com>,
>> <georss at lists.eogeo.org>
>> Conversation: [georss] What's next--a query API
>> Subject: RE: [georss] What's next--a query API
>> 
>> I could agree to this but I think you should reference WFS rather than
>> WMS since you are asking for data and not pictures.
>> 
>> Cheers
>> 
>> Ron
>> 
>> -----Original Message-----
>> From: georss-bounces at lists.eogeo.org
>> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Raj Singh
>> Sent: May 8, 2006 5:45 PM
>> To: Danny Ayers; georss at lists.eogeo.org
>> Subject: [georss] What's next--a query API
>> 
>> What's the first thing you want to do after you have a GeoRSS feed?
>> Do a geographic query of course.
>> 
>> I'm sure we can think of all kinds of interesting and useful spatial
>> queries, like distance from something else or the overlap of two
>> geographies, but the thing people will probably want to do 95% of the
>> time
>> is get only things in a specified bounding box.
>> 
>> How about we promote this as a recommended feature of GeoRSS-enabled
>> software? Here's the proposal:
>> 
>> 1. A GeoRSS bounding box query consists of a feed URI plus a BBOX
>> parameter,
>> consisting of minx,miny,maxx,maxy. This is the same as the WMS BBOX
>> parameter.
>> 
>> 2. A service can optionally support multiple coordinate reference
>> systems by
>> adding support for an SRS parameter, which would contain an EPSG code
>> (once
>> again like WMS).
>> 
>> --
>> Raj
>> 
>> 
>> _______________________________________________
>> 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