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

Fri Feb 11 09:22:13 EST 2011

Some interaction between the ECHO team with representatives of OpenSearch and OGC produced the following suggestion as a byproduct, which replaces many of our ESIP-specific "rel" values with standard values from the IANA registry (http://www.iana.org/assignments/link-relations/link-relations.xhtml).

What do you all think?  Are these terms definitive enough to replace our non-standard terms?
> http://esipfed.org/ns/fedsearch/1.0/browse# => "icon"
> http://esipfed.org/ns/fedsearch/1.0/data#" => "enclosure"
> http://esipfed.org/ns/fedsearch/1.1/documentation# => "describedby"

The "describedby" seems logical in place of http://esipfed.org..../documentation#, but I am on the fence for the other two.

Begin forwarded message:

> From: Pedro Gonçalves <pedro.goncalves at terradue.com>
> Date: February 11, 2011 4:42:22 AM EST
> To: Douglas J Newman <Doug.Newman-NR at raytheon.com>
> Cc: "Hua, Hook" <hook.hua at jpl.nasa.gov>, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov>, "Cechini, Matthew F. (GSFC-423.0)[RAYTHEON COMPANY]" <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) 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
> 

--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185