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.
8 Comments
user-7b92a
A response from Jon Pals via email:
user-7b92a
A response from Patrick Quinn via email:
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:
AVHRR Polar Pathfinder (APP) and Extended AVHRR Polar Pathfinder (APP-x) Climate Data Records
Many more like this
user-7b92a
I filed CMR-3038 - Getting issue details... STATUS
James Johnson
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.
Jon Pals
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.
James Johnson
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?
Jon Pals
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.