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.
@cholmes @m-mohr During development of the Collection Spec, was there ever consideration of a Collection also being consumable as a GeoJSON (e.g. having
I'm working through a scenario at the moment with a number of stand-alone collections that would greatly benefit from having their footprint/extent represented in a simple and consumable manner. The data is mainly linear captures with film / digital aerial photography, where a bounding box is a very poor representation of project extent. In a large number of instances we also don't have any mosaic assets that show the project's full extent. While we've tried to represent the data in the summaries object under
proj:geometry, this resulting file is certainly not as usable to rapidly query or visualise as a GeoJSON.
While I can't find any mention in the STAC spec and OGC API - Features spec, I notice that in PySTAC there is support for a Properties object in the collections class. Is this from earlier iterations of the spec, or for collection level properties to be represented?
As always, your support and insights are greatly appreciated. I know our use cases can be a bit left of field sometimes.