eo:bandsdefinitions still allowed in Item Properties? The schema still allows them there, but it no longer allows them to be referenced by array index from the Asset. The spec text is "eo:bands: In previous versions eo:bands was allowed to be used on the asset-level referencing via array indices to the actual bands in Item properties. Starting with STAC 1.0.0-beta.1 you are now allowed to place the full eo:bands array with all Band Object information in Item assets as described in general in the STAC Item."
A summary for a field can be specified in two ways:
- A set of all distinct values in an array: The set of values must contain at least one element and it is strongly recommended to list all values. If the field summarizes an array (e.g. instruments), the field's array elements of each Item must be merged to a single array with unique elements.
@ycespb Astraea EOD uses application/json, but I noticed yesterday that @geospatial-jeff had an api that used "application/geo+json".
It is currently not specified what the type should be, and I feel it should. Right now, it only says
"If the /search endpoint is implemented, it is required to add a link with the rel type set to search to the links array in / that refers to the search endpoint in the href property."
I'll create a PR to add to that:
"It is recommended that the
type for this link is
application/geo+json (preferred) or
dist/index.html. I tried prerendering it as well, although I just get errors saying
distis not empty and a few other things that I tried troubleshooting to no avail. Any idea what I'm doing wrong?
const COG_TYPES = [ "image/vnd.stac.geotiff; cloud-optimized=true", "image/x.geotiff", // generated by sat-api "image/tiff; application=geotiff; profile=cloud-optimized" ];
Slowly progressing with work to generate STAC files for our collection. In the process so far, two key questions have emerged from my team. We would greatly appreciate thoughts and opinions on the following:
Standalone Collections -
When creating standalone collections, what is the recommendation for representing footprint geometry (I'm assuming
proj:geometry)? I notice that when validating in STACLint it recommends that values for each attribute in
summaries should be surrounded by
. In the scenario of a standalone collection, should this applied to all attributes in
summaries or only for the attributes where multiple values are present?
Is there any flexibility in the item spec / extensions for MultiPolygon (rather than Polygon) GeoJSON geometries? I'm currently generating STAC collections and items for orthorectified historic aerial photography data, and there are a limited number of instances where a project is split across two distinct polygons due to a missing flightline (or pilot error). All properties are identical, the data asset (e.g. mosaic) just has a gap in the middle.