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

Wed Feb 9 19:08:24 EST 2011

You might also want to check out how a number of internet standards deal
with time, especially from the response perspective. From memory, the NASA
response used in the echo project looks similar.

Carl

> 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
>