[OSGeo-Standards] Proposal for Open Search Geo extension support of point and line

Fri Feb 11 13:40:39 EST 2011

Hi Matthew

I tried for a while to motivate the georss group to accept at least a multi-polygon on the georss:simple (a huge requirement for the EO groups dealing with atmospheric data) but unfortunately with little reaction  (also the list seems dead)

i wrote a proposal in the georss site back in september  
http://www.georss.org/multi_polygons

Probably we should join efforts and make our requirements there and see what happens  

ciao 

pedro


On Feb 11, 2011, at 7:22 PM, Cechini, Matthew F. (GSFC-423.0)[RAYTHEON COMPANY] wrote:

> Pedro,
>    Thank you for this response.  I find it a little disappointing that the Draft #2 Geo OpenSearch spec handles complex geometries rather well, but the GeoRSS:Simple response does not, forcing us into using GML response elements.  It would be nice if these response and request elements were more similar, but not tragically difficult to work around.  I will be responding to the other messages regarding the time representation and rel links separately.
> 
> Thanks,
> Matt
> 
> Matthew F Cechini
> ECHO Operations Lead - Systems Engineer
> Office: (301) 851-8049
> Cell  : (202) 251-8013
> Fax   : (301) 851-8283
> E-Mail: Matthew.F.Cechini at nasa.gov
> 
> From: Pedro Gonçalves <pereira.goncalves at gmail.com>
> Date: Wed, 9 Feb 2011 07:29:45 -0600
> To: Matt Cechini <Matthew.F.Cechini at nasa.gov>
> Cc: Douglas J Newman <Doug.Newman-NR at raytheon.com>, "standards at lists.osgeo.org" <standards at lists.osgeo.org>, "Hua, Hook" <hook.hua at jpl.nasa.gov>, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov>
> Subject: Re: [OSGeo-Standards] Proposal for Open Search Geo extension support of point and line
> 
> Hi Matthew 
> 
> In fact the response can use the basic opensearch elements (os:Query, os:totalResults, os:itemsPerPage, os:startIndex and so on plus the atom:link for navigation) but the geospatial and temporal extension does not (at least currently) introduce any new response elements and it uses the already defined georss (from  http://www.georss.org/Main_Page) to give geospatial information. 
> However I think we are missing a simple way to define the temporal dimension of the data. The elements already available in atom (like atom:updated and atom:published) are not adequate to most of the use cases in earth observation and geographic data because they refer when the resource was actually created and published and not when it was acquired [1]
> 
> I tried the nasa's echo and I noticed to it's using the query elements also as response elements for the temporal dimensions of the entries 
> For instance this request 
> 
> https://api.echo.nasa.gov/echo-esip/search/granule.atom?dataCenter=LAADS&shortName=MOD02QKM&versionId=5&numberOfResults=10&cursor=0&startTime=2000-02-01&endTime=2000-02-28
> 
> returns entries have the time:start and time:end elements: 
>   ....
> <time:start>2009-05-01T00:30:00.000Z</time:start>
> <time:end>2009-05-01T00:35:00.000Z</time:end>
> ...
> 
> while this currently not defined in the specification I think that this a very good solution for this problem instead of adding a new namespace (e.g. ical) or using the more generic and ambiguous dc:date.
> 
> If you agree I will include this in the draft and also on the OGC specification that I'm editing now. 
> What do you all think ?
> 
> I'll updated the document and send it to the list for your comments 
> 
> best regards
> 
> Pedro
> 
> [1] http://groups.google.com/group/opensearch/browse_thread/thread/cc5e437dbc97a883?hl=en#
> 
> 
> On Feb 8, 2011, at 9:45 AM, Cechini, Matthew F. (GSFC-423.0)[RAYTHEON COMPANY] wrote:
> 
>> All,
>>   Please correct me if I am wrong.  The Draft (#2) OpenSearch Spec contains modifications to the spatial search capabilities, but these modifications do not correspond to changes in the response format, correct?  We should be looking to the GeoRSS (http://www.georss.org/Main_Page) specification for how to format our Atom feed results that include spatial information.  The following text from the Draft spec have me perplexed and I want to make sure I'm on the right page.
>> 
>>> The OpenSearch-Geo response elements can be used by search engines to augment existing XML formats with search-related metadata. See the OpenSearch response definition for a general overview of the response options.
>>> The following examples illustrate Geo-specific responses. For RSS and Atom responses, it is suggested to use the GeoRSS channel elements in addition to the OpenSearch-Geo elements. 
>> 
>> 
>> Thanks,
>> Matt
>> 
>> Matthew F Cechini
>> ECHO Operations Lead - Systems Engineer
>> Office: (301) 851-8049
>> Cell  : (202) 251-8013
>> Fax   : (301) 851-8283
>> E-Mail: Matthew.F.Cechini at nasa.gov
>> 
>> From: Pedro Gonçalves <pereira.goncalves at gmail.com>
>> Date: Fri, 28 Jan 2011 02:22:36 -0600
>> To: Douglas J Newman <Doug.Newman-NR at raytheon.com>
>> Cc: "standards at lists.osgeo.org" <standards at lists.osgeo.org>, "Hua, Hook" <hook.hua at jpl.nasa.gov>, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov>, Matt Cechini <Matthew.F.Cechini at nasa.gov>
>> Subject: Re: [OSGeo-Standards] Proposal for Open Search Geo extension support of point and line
>> 
>> Hi Douglas
>> 
>> Probably the Geo Extension already covers that request using the geometry parameter.
>> With this you can specify a WKT (POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON) directly on this parameter 
>> Something like 
>> 
>> http://example.com/?q=pizza&geometry=LINESTRING(-111.032,42.943,-119.856,43.039)&format=rss
>> 
>> http://example.com/?q=pizza&geometry=POINT(-111.032,42.943)&format=rss
>> 
>> would this be in accordance with your needs ? 
>> 
>> btw... the geo:rss elements are in fact used in the atom xml response not in the request http parameters
>> 
>> best regards
>> 
>> Pedro
>> 
>> On Jan 26, 2011, at 3:31 PM, Douglas J Newman wrote:
>> 
>>> 
>>> The NASA ECHO project (www.echo.nasa.gov) is in the process of
>>> providing a search capability, via an ESIP interface (using the Open
>>> Search standard with Geo extension), by point and line.
>>> 
>>> The current implementation can be seen at https://api.echo.nasa.gov/echo-esip/
>>> 
>>> The http://www.georss.org/simple specification (which I believe the
>>> geo
>>> extension is based on) provides this support and we would like to
>>> propose
>>> it's addition to the open search geo spec.
>>> 
>>> For example,
>>> 
>>> Example URL templates:
>>> 
>>> http://example.com/?q={searchTerms}&pw={startPage?}&line={geo:line?}&format=rss
>>> 
>>> http://example.com/?q={searchTerms}&pw={startPage?}&point={geo:point?}&format=rss
>>> 
>>> Example requests:
>>> 
>>> http://example.com/?q=pizza&line=-111.032,42.943,-119.856,43.039&format=rss
>>> 
>>> http://example.com/?q=pizza&point=-111.032,42.943,-&format=rss
>>> 
>>> I note that the section of the Geo extension on atom responses has the
>>> element,
>>> 
>>> <georss:line>40.73763 -73.9972 40.73519 -73.99167 40.737015 -73.99035
>>> 40.73643 -73.98914 40.734640 -73.990431 40.731617 -73.991504</
>>> georss:line>
>>> 
>>> we propose an additional element for point,
>>> 
>>> <georss:point>40.73763 -73.9972</georss:point>
>>> 
>>> Please let us know if this is proposal is acceptable._______________________________________________
>>> Standards mailing list
>>> Standards at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/standards
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/standards/attachments/20110211/ebfd0738/attachment-0001.html