For a non-earth viewing instrument, such as the SORCE instruments which monitor the sun, how should the spatial metadata be specified?

At the collection level should there be a Spatial BoundingRectangle defined (-90 to +90 latitude, -180 to +180 longitude) so that its implied the product is applicable for the entire globe even though the instrument is not viewing the earth? Or should there be absolutely no Spatial BoundingRectangle specified?

We do not receive granule spatial metadata for these types of data, as they are not earth-viewing, so we set the Granule_Spatial_Representation attribute to NO_SPATIAL. This has consequences in earthdata search client. If the search doesn't include a spatial search area (i.e. its left blank), then the client returns the data correctly. But if the user supplies an arbitrary spatial search area, then the client will not return the data. To me that is incorrect. If the data are applicable to the entire globe, then any spatial search, including none, should always return these solar data products.

  • No labels

8 Comments

  1. user-7b92a

    A response from Jon Pals via email:

    It seems to me that if a collection has a GranuleSpatialRepresentation specified as "NO_SPATIAL", then its granules should be returned in search results no matter what a user puts in for spatial constraints.  In my mind, a spatial constraint of -90 to +90 latitude and -180 to +180 longitude is just as invalid as a spatial constraint of -1 to +1 latitude and -1 to +1 longitude for a "NO_SPATIAL" collection.  I suggest that for "NO_SPATIAL" collections the spatial part of any search not be performed.

  2. user-7b92a

    A response from Patrick Quinn via email:

    It's an interesting case. I think it should be left as-is, because I think there are two ideas the data provider could want to express through spatial:

    1. This collection/granule has no particular spatial extent, and it makes sense for it to be returned if the user asks for data in a given location
    2. This collection/granule has no particular spatial extent, and it does not make sense for it to be returned if the user asks for data in a given location
    In this case, my limited understanding of SORCE data says that it should probably have a global extent, or (half-global) extent applied to its granules, because it's measuring incoming solar radiation, and that will be incident on roughly a full hemisphere, so it makes sense to search for it and deal with it in Earth-spatial terms.
    My question is whether use case #2 is actually valid for the CMR. Is there any conceivable case where data exists, indexed by the CMR, which cannot and should not be attached to any particular location on Earth? Something like data from Pathfinder would fall into that category (if I put a bounding box over the Chesapeake Bay, it really shouldn't return any results). Given the "E" in EOSDIS, though, it may be the case that there will never be data like that.
  3. user-7b92a

    Patrick Quinn, What would happen right now in EDSC if a collection had a global spatial area and the granules were set to NO_SPATIAL and a user searched spatially, found the collection, and then did a granule search? Would they even get that far? The CMR would report through included granule counts that 0 granules were found in the collection matching the conditions so I'm guessing EDSC wouldn't even show the collection in the collection search results.

    You make a good point about the existence of data not attached to any particular location on Earth. I think you're right that there may never be a case like that in the CMR. I looked over the collections in the CMR which did not have any spatial. Out of the ~35k collections 2018 do not have a defined spatial area. Looking through a subset of them it seems like almost all of them should either have a specific area and do not or should be considered matching the whole world. I list some of the examples below. I'm going to file a new issue in the CMR that a collection or granule without any spatial region should be considered as having global coverage.

    A Subset of Collections without defined spatial area:

    • Collections which don't seem to be collections
      • CDDIS_MISC_information - Miscellaneous documentation, information, and ancillary data to be used with GNSS, laser ranging, VLBI and DORIS data and analyzed products available through the CDDIS.
        • This seems less like a collection and more like documentation. This might be a candidate for moving to a new type of concept in the future.
    • Collections which do not have spatial bounds but which probably should
      • Ozone Monitoring Instrument Near Real Time Data for v3 - This collection contains Near Real Time Data from the Ozone Monitoring Instrument(OMI).The OMI instrument employs hyperspectral imaging in a push-broom mode to observe solar backscatter radiation in the visible and ultraviolet.
      • MERIS Full Resolution Geolocated and Calibrated TOA Radiance (MER_FR_1P)
      • AVHRR Polar Pathfinder (APP) and Extended AVHRR Polar Pathfinder (APP-x) Climate Data Records

      • Many more like this

    • 231 LARC_ASDC collections which do not have spatial but define granules with GEODETIC spatial areas.
      • There are many LARC_ASDC collections like this. These won't currently be found by a spatial search at the collection level in EDSC. This makes them very hard to to discover.
      • Examples
        • North American Research Strategy for Tropospheric Ozone (NARSTO) SOS South Carolina Upstate PM 2.5 Compostion (NARSTO_SOS_SC_UPSTATE_PM25_COMPOSITION)
        • Airborne Multi-angle Imaging SpectroRadiometer Smithsonian Environmental Research Center Maryland 2003. (AIRMISR_SERC_2003)
        • First ISCCP Regional Experiment (FIRE) ASTEX Surface of the Ocean, Fluxes and Interaction with the Atmosphere (SOFIA) Avion de Recherche Atmospherique (ARAT) Fokker F27 Aircraft Flight Data in Native format (FIRE_AX_SOF_ARAT_FLT)

     

     

     

  4. user-7b92a

    I filed  CMR-3038 - Getting issue details... STATUS

  5. Does anybody know how LaRC aka ASDC is doing the ACRIM data? That is a set of data collections that are like the SORCE data, looking at the Sun rather than the Earth. I think it would be bad if GES DISC does their solar data one way in CMR, and another center does it a completely different way. There should be a standard way of describing these data, so that a tool such as ESDC can handle them consistently.

  6. Though the ACRIM III data are not currently available through the OPS CMR, they are defined as having no collection-level spatial coordinate metadata, a SpatialKeyword set to "Global", and a GranuleSpatialRepresentation of "NO_SPATIAL".  Each granule has a LocalityValue set to "Global".  In the UAT CMR, the granules are only returned if no spatial region is specified in the search client.

  7. Hi Jon, thanks for the info. I use the UAT-CMR DIF10 interface, but I don't see a SpatialKeyord = "Global" field. Where do I find this?

  8. Hi James.  SpatialKeyword is in the ECHO 10 format.  I think that "Location" with a "Location_Category" of "GEOGRAPHIC REGION" and a "Location_Type" of "GLOBAL" is the DIF equivalent.