This PR adds support for downloading WorldView NITF imagery.
On the STAC server, NITFs are stored in the worldview-nitf collection. I created a new module, rdwatch.core.utils.worldview_nitf, that mirrors the existing rdwatch.core.utils.worldview_processed with a few key differences:
1) I removed pan-sharpening logic from worldview_nitf.
2) rio-tiler gets stuck indefinitely if you give it an S3 URL to a NITF file directly. I assume it's struggling with the size somehow, as obviously unlike COGs it must download the entire image (on the order of gigabytes) every time it wants to chip out a small bounding box. To get around this, I download the NITF image from S3 directly using boto3 to a temporary file and pass rio-tiler the path to that, and it works.
3) Following on from 2), because we need to do that explicit image download to the worker's filesystem, it is not really possible to have the region-level on-demand imagery from an endpoint. Thus the only way to use NITF imagery in this PR is in the site/observation-level chips; see the GIF I posted in Slack.
Going forward I'd like to clean up some of the image fetching architecture and logic (especially if we're going to add dev docs on how this stuff is structured/how to add new image sources). Currently there are a lot of complicated functions that are tighly coupled to each other and difficult to reason about. But for the purposes of keeping this PR well-scoped, I haven't made any attempts at that here.
This PR adds support for downloading WorldView NITF imagery.
On the STAC server, NITFs are stored in the
worldview-nitfcollection. I created a new module,rdwatch.core.utils.worldview_nitf, that mirrors the existingrdwatch.core.utils.worldview_processedwith a few key differences:1) I removed pan-sharpening logic from
worldview_nitf. 2)rio-tilergets stuck indefinitely if you give it an S3 URL to a NITF file directly. I assume it's struggling with the size somehow, as obviously unlike COGs it must download the entire image (on the order of gigabytes) every time it wants to chip out a small bounding box. To get around this, I download the NITF image from S3 directly using boto3 to a temporary file and passrio-tilerthe path to that, and it works. 3) Following on from 2), because we need to do that explicit image download to the worker's filesystem, it is not really possible to have the region-level on-demand imagery from an endpoint. Thus the only way to use NITF imagery in this PR is in the site/observation-level chips; see the GIF I posted in Slack.Going forward I'd like to clean up some of the image fetching architecture and logic (especially if we're going to add dev docs on how this stuff is structured/how to add new image sources). Currently there are a lot of complicated functions that are tighly coupled to each other and difficult to reason about. But for the purposes of keeping this PR well-scoped, I haven't made any attempts at that here.