Question
--------

Does geowatch integrate with STAC?


Answer
------

Yes, we use STAC.

In fact STAC is the basis for all of our geospatial-first data interchange.
Kitware is a performer in the IARPA SMART program, which provides all data via
STAC endpoints. We started using it in early 2021, and we've seen it improve
over the past 3 years. Kitware's entry for this challenge is powered by our
geowatch software.

We have a process to convert STAC to KWCOCO, which puts the geospatial data
into a pixel-first context. The end-to-end pipeline is outlined here:
geowatch/cli/prepare_ta2_dataset.py where the input is a geojson file
indicating the spacetime area of interest. The output is a corresponding kwcoco
dataset.

The above just defines the pipeline. The information flow is as follows:

* Run geowatch.cli.stac_search to identify matching STAC entries.

* Run geowatch.cli.baseline_framework_ingress  which converts query results to a STAC catalog.

* Run geowatch.cli.stac_to_kwcoco which does the conversion to kwcoco (note: no data is pulled here, we just make a kwcoco file that points at the remote URLs for each relevant asset)

* Run geowatch.cli.coco_align which uses GDAL to download crops / overviews of the underlying assets. This is what puts the data on disk and lets the ML engineers play with it. Everything in the geowatch system is KWCOCO from this point on, but I do see a future where predicted heatmaps added as new raster bands to the KWCOCO file are then indexed via STAC and pushed back up to some storage location.

Once inside of a kwcoco file we have a fairly sophisticated dataloader that
allows users to request data in arbitrary resolutions. This logic lives in
geowatch.tasks.fusion.datamodules.kwcoco_dataset. It's powered by the
delayed-image library.
