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

creed at opengeospatial.org creed at opengeospatial.org
Wed Feb 9 19:08:59 EST 2011 

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