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

Pedro Gonçalves pereira.goncalves at gmail.com
Thu Feb 10 03:34:49 EST 2011 

ok I'll keep the document as it was and not include the time response element present on the echo's response 

On Feb 10, 2011, at 1:08 AM, creed at opengeospatial.org wrote:

> Makes sense to me.
> 
> Carl
>> OK so your proposal is to more fully specify the Time extension to include
>> elements in the response that match those in the request. That makes
>> sense.
>> 
>> You are probably already be doing this, but I want to add that I think the
>> Time and Geo extensions should remain separately specified, as start and
>> end time parameters have wider applicability than just geographic data. In
>> fact, why not have two separate documents?
>> 
>> ---
>> Raj
>> The OGC: Making location count...
>> http://www.opengeospatial.org/contact
>> 
>> 
>> On Feb 9, at 12:48 PM, Pedro Gonçalves wrote:
>> 
>>> 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
>>>> 
>>> 
>> 
>> _______________________________________________
>> Standards mailing list
>> Standards at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/standards
>> 
> 
>

More information about the Standards mailing list