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

Wed Feb 9 12:48:09 EST 2011

HI Raj 

the time extension (that we included together with the geo extension in the OGC document) defines time:start and time:end as request parameters but not as response elements 
so you can make a 
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
but is not defined the time:start and time:end elements for the response

what the nasa's echo project did and I'm proposing to include it, is the possibility have it also in the response atom feed as 
<feed>
...
<entry>
 ....
<time:start>2009-05-01T00:30:00.000Z</time:start>
<time:end>2009-05-01T00:35:00.000Z</time:end>
...
</entry>
</feed>

ciao 

pedro  

On Feb 9, 2011, at 6:40 PM, Raj Singh wrote:

> Doesn't the OpenSearch Time extension handle this type of query on start and end time?
> http://www.opensearch.org/Specifications/OpenSearch/Extensions/Time/1.0/Draft_1
> 
> ---
> Raj
> The OGC: Making location count...
> http://www.opengeospatial.org/contact
> 
> 
> On Feb 9, at 8:29 AM, Pedro Gonçalves wrote:
> 
>> 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
>>> 
>> 
>> _______________________________________________
>> Standards mailing list
>> Standards at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/standards
> 