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

Fri Feb 11 13:28:32 EST 2011

Pedro,
   Thank you for these recommendations.  Our OpenSearch interface has been developed in collaboration with an ESIP cluster, which has currently identified the following response format:  http://wiki.esipfed.org/index.php/Discovery_Cast_Atom_Response_Format .  We will work with them to discuss the recommended changes that you have listed.  I am ok with you using our response documents as examples.

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 <pedro.goncalves at terradue.com<mailto:pedro.goncalves at terradue.com>>
Date: Fri, 11 Feb 2011 03:42:22 -0600
To: Douglas J Newman <Doug.Newman-NR at raytheon.com<mailto:Doug.Newman-NR at raytheon.com>>
Cc: "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

After checking the ATOM feed from the ECHO project I'd like to ask you if I can use it in the examples of the OGC OpenSearch GeoSpatial Extension document I'm editing.

I'd also suggest - if I may :) -  some changes on the ECHO results of the atom:rel values that are being used on the atom:link elements so that they are according to the iana registry (http://www.iana.org/assignments/link-relations/link-relations.xhtml) and the OGC document.

My comments regarding the ECHO atom results are the following

#1 Browse Image

So where is the rel = "http://esipfed.org/ns/fedsearch/1.0/browse#
like in
<link href="ftp://ladsftp.nascom.nasa.gov/allData/5/MOBRGB/2009/121/MOBRGB.A2009121.0020.005.2009126214738.jpg" hreflang="en-US" type="image/jpeg" title="" rel="http://esipfed.org/ns/fedsearch/1.0/browse#" length="660988"></link>

you could change it to rel="icon"
<link href="ftp://ladsftp.nascom.nasa.gov/allData/5/MOBRGB/2009/121/MOBRGB.A2009121.0020.005.2009126214738.jpg" hreflang="en-US" type="image/jpeg" title="" rel="icon" length="660988"></link>

#2 Data Access

the same to  the data relation
<link href="ftp://ladsftp.nascom.nasa.gov/allData/5/MOD02QKM/2009/121/MOD02QKM.A2009121.0020.005.2010241162125.hdf" hreflang="en-US" type="application/x-hdfeos" title="" rel="http://esipfed.org/ns/fedsearch/1.0/data#"></link>

it could be changed to the rel="enclosure"

<link href="ftp://ladsftp.nascom.nasa.gov/allData/5/MOD02QKM/2009/121/MOD02QKM.A2009121.0020.005.2010241162125.hdf" hreflang="en-US" type="application/x-hdfeos" title="" rel="enclosure"></link>

#3 Documentation

The relation that you are using to reference the documentation about the data type

http://esipfed.org/ns/fedsearch/1.1/documentation#

can be changed to

describedby

#4 Time Elements

According to the last the suggestions circulated in the last emails, we should use the normal OGC date returnable (dc:date)

So regarding the time elements I would suggest the change of
    <time:start>2009-05-01T00:20:00.000Z</time:start>
    <time:end>2009-05-01T00:25:00.000Z</time:end>
to
<dc:date>2009-05-01T00:20:00.000Z/2009-05-01T00:25:00.000Z

#5 geo namespace and georrs namespace

Please note that as Matthew said in the last email the geo namespace is used to define the queriables (geo:box, geo:geometry, geo:radius and so on) and the georss is used in the return message to express the spatial dimension of the resources (atom:entry) and search engine (atom:feed)

thanks and 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/cb0e427f/attachment.html>