[Esip-discovery] Orbit Metadata in OpenSearch Metadata

[Hua, Hook (388C)]

The current spec probably can support orbit-based files. Three possible ways to express it in the response:

(1) define the required bbox covering the minimum bounding region of the orbit. Especially for repeating orbits, the bbox may cover much of the globe.
(2) as Chris L. said, represent the swath region as a set of tile boxes. ok to over estimate region.
(3) define the orbit with polygon.

But I think one key usefulness of any one of these approaches is that the clients get coordinates consistently in WGS84. But this may require some work on the server to convert the orbit-based metadata.

--Hook

________________________________________
From: esip-discovery-bounces at lists.esipfed.org [esip-discovery-bounces at lists.esipfed.org] On Behalf Of Lynnes, Christopher S. (GSFC-6102) [christopher.s.lynnes at nasa.gov]
Sent: Friday, March 18, 2011 8:47 AM
To: Cechini, Matthew F. (GSFC-423.0)[RAYTHEON COMPANY]
Cc: esip-discovery at lists.esipfed.org
Subject: Re: [Esip-discovery] Orbit Metadata in OpenSearch Metadata

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


_______________________________________________
Esip-discovery mailing list
Esip-discovery at lists.esipfed.org
http://www.lists.esipfed.org/mailman/listinfo/esip-discovery