[Esip-discovery] Orbit Metadata in OpenSearch Metadata

Fri Mar 18 11:47:39 EDT 2011

On Mar 18, 2011, at 11:30 AM, Cechini, Matthew F. (GSFC-423.0)[RAYTHEON COMPANY] wrote:

> Chris,
>  I'm not sure I understand the tactic of delegating granule-level
> searches back to mirador.  The ability to support spatial searches against
> orbital granules, at least for us, is a separate issue than presenting one
> or more rectangles in a response object specifying a granule's orbital
> spatial coverage.  On our end, we could compute (or pre-compute) the
> bounding boxes which cover an orbital granule and make it available for
> the response object.
>  In light of the current proposed response format, the response object
> should specify the MBR for a granule.  Should we assume that  multiple
> <georss:box> elements in a response object, combined together, represent
> the minimum bounding area?  Do we think there is value in providing the
> original orbit information in the response?  I'm leaning towards "not at
> this time" since we want to keep the spec simple.  For us, we should look
> into calculating the MBR(s) for orbital granules and including those in
> the response object.
> 

I think extra orbital data is going to be of minimal use, as it only works in more specific contexts like NOSE specifications.  If you can compute the set of rectangles, or perhaps a polygon, that would be much more useful and you don't need to delegate the search.  I mostly wanted to bring that up to break our preconceived notions that all steps of a recursive OpenSearch search scenario must necessarily be within a single server or organization.  For example, I have been hinting to Lola Olsen that I would like to register OSDDs in GCMD for each dataset, and have GCMD provide the first (dataset) layer of search, delegating the granule level to us for our datasets.

> 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
> 
> 
> 
> 
> 
> On 3/18/11 11:16 AM, "Lynnes, Christopher S. (GSFC-6102)"
> <christopher.s.lynnes at nasa.gov> wrote:
> 
>> We actually straddle this fence at GES DISC:  we send orbital metadata to
>> ECHO, but we compute assemblages of rectangles (a single bounding box
>> does not work) for Mirador.  Assuming that the spec were modified (or
>> already accommodates?) multiple rectangles per item in the response, it
>> raises the interesting tactic of delegating granule-level OpenSearch back
>> to Mirador for those datasets.  That is, you could return an OSDD which
>> leads to a search against Mirador instead of ECHO.
>> 
>> On Mar 18, 2011, at 10:33 AM, Mattmann, Chris A (388J) wrote:
>> 
>>> Hi Matt,
>>> 
>>> I think the reason we don't see this stuff in GeoRSS is that GeoRSS is
>>> assumed to describe data/documents that are downstream and where spatial
>>> information and geometry has already been computed. Maybe there should
>>> be a SatlelliteRSS (or whatever :) ) as a set of custom extensions to
>>> RSS similar to what GeoRSS does in its own right.
>>> 
>>> Really good topic to discuss in general though.
>>> 
>>> My 2 cents,
>>> Chris
>>> 
>>> On Mar 18, 2011, at 5:14 AM, Cechini, Matthew F. (GSFC-423.0)[RAYTHEON
>>> COMPANY] wrote:
>>> 
>>>> All,  
>>>>  A number of our granules specify orbit metadata (crossing lat,
>>>> crossing longitude, etc) and do not specify a spatial geometry (box,
>>>> polygon).  When returning spatial information for these granules,
>>>> according to the new spec we would need to calculate the MBR for the
>>>> orbit track.  Difficulties of that aside, I don't see any handling of
>>>> orbit information in either of the GeoRSS specifications.  Is this
>>>> something you have discussed before?  Is there another specification
>>>> that we may look to that handles orbit metadata, or are we on our own
>>>> to specify custom tags if we want to return that information?
>>>> 
>>>> 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
>>>> _______________________________________________
>>>> Esip-discovery mailing list
>>>> Esip-discovery at lists.esipfed.org
>>>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
>>> 
>>> 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Chris Mattmann, Ph.D.
>>> Senior Computer Scientist
>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> Office: 171-266B, Mailstop: 171-246
>>> Email: chris.a.mattmann at nasa.gov
>>> WWW:   http://sunset.usc.edu/~mattmann/
>>> Phone: +1 (818) 354-8810
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Adjunct Assistant Professor, Computer Science Department
>>> University of Southern California, Los Angeles, CA 90089 USA
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 
>>> _______________________________________________
>>> Esip-discovery mailing list
>>> Esip-discovery at lists.esipfed.org
>>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
>> 
>> --
>> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
>> 
>> 
> 

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