[Esip-discovery] Orbit Metadata in OpenSearch Metadata

Fri Mar 18 11:30:32 EDT 2011

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.

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
>
>