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

Fri Feb 11 13:47:11 EST 2011

Pedro,
   Not only would a multipolygon be required for us, but the ability to represent inner and outer polygons so that we can address data with exclusion areas.  We expect to see a more common occurrence of that in our data in the coming months.  I'm not sure what our ESIP Discovery cluster feels about extending such a request, but it makes sense to me.

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<mailto:Matthew.F.Cechini at nasa.gov>

From: Pedro Gonçalves <pereira.goncalves at gmail.com<mailto:pereira.goncalves at gmail.com>>
Date: Fri, 11 Feb 2011 12:40:39 -0600
To: Matt Cechini <Matthew.F.Cechini at nasa.gov<mailto:Matthew.F.Cechini at nasa.gov>>
Cc: Douglas J Newman <Doug.Newman-NR at raytheon.com<mailto:Doug.Newman-NR at raytheon.com>>, "standards at lists.osgeo.org<mailto:standards at lists.osgeo.org>" <standards at lists.osgeo.org<mailto:standards at lists.osgeo.org>>, "Hua, Hook" <hook.hua at jpl.nasa.gov<mailto:hook.hua at jpl.nasa.gov>>, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov<mailto:christopher.s.lynnes at nasa.gov>>, Carl Reed <creed at opengeospatial.org<mailto:creed at opengeospatial.org>>
Subject: Re: [OSGeo-Standards] Proposal for Open Search Geo extension support of point and line

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<mailto:Matthew.F.Cechini at nasa.gov>

From: Pedro Gonçalves <pereira.goncalves at gmail.com<mailto:pereira.goncalves at gmail.com>>
Date: Wed, 9 Feb 2011 07:29:45 -0600
To: Matt Cechini <Matthew.F.Cechini at nasa.gov<mailto:Matthew.F.Cechini at nasa.gov>>
Cc: Douglas J Newman <Doug.Newman-NR at raytheon.com<mailto:Doug.Newman-NR at raytheon.com>>, "standards at lists.osgeo.org<mailto:standards at lists.osgeo.org>" <standards at lists.osgeo.org<mailto:standards at lists.osgeo.org>>, "Hua, Hook" <hook.hua at jpl.nasa.gov<mailto:hook.hua at jpl.nasa.gov>>, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov<mailto: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<http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_response_elements> 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<mailto:Matthew.F.Cechini at nasa.gov>

From: Pedro Gonçalves <pereira.goncalves at gmail.com<mailto:pereira.goncalves at gmail.com>>
Date: Fri, 28 Jan 2011 02:22:36 -0600
To: Douglas J Newman <Doug.Newman-NR at raytheon.com<mailto:Doug.Newman-NR at raytheon.com>>
Cc: "standards at lists.osgeo.org<mailto:standards at lists.osgeo.org>" <standards at lists.osgeo.org<mailto:standards at lists.osgeo.org>>, "Hua, Hook" <hook.hua at jpl.nasa.gov<mailto:hook.hua at jpl.nasa.gov>>, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov<mailto:christopher.s.lynnes at nasa.gov>>, Matt Cechini <Matthew.F.Cechini at nasa.gov<mailto: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<http://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=%7BsearchTerms%7D&pw=%7BstartPage?%7D&line=%7Bgeo:line?%7D&format=rss>

http://example.com/?q={searchTerms}&pw={startPage?}&point={geo:point?}&format=rss<http://example.com/?q=%7BsearchTerms%7D&pw=%7BstartPage?%7D&point=%7Bgeo:point?%7D&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<mailto:Standards at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/standards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20110211/d5b9eab5/attachment-0001.html>