Context

Adds support for non-rectangular AOIs

Investigation

• AOI Table already supports arbitrary polygons
• Inference Websocket Messages already support arbitrary polygons

Closes: https://github.com/developmentseed/pearl-frontend/issues/21

Context

Ensure Model.storage & Model.active are true on project creation

Closes: https://github.com/developmentseed/pearl-backend/issues/10

cc/ @geohacker

Context

This PR updates the codebase to more modern ES6 which is increasingly becoming a necessity in order to use underlying project dependencies.

• [x] Update API deps to latest versions where possible
• [x] Update API Codebase to ES6

Actions

The following tests are currently failing:

• [x] tiles.test.js
• [x] project.test.js
• [x] model-osmtag.js
• [x] instance.test.js
• [x] checkpoint-upload.js
• [x] checkpoint.test.js
• [x] checkpoint-geoms.test.js
• [x] batch.test.js
• [x] aoi.test.js
• [x] aoi-share.test.js
• [x] aoi-patch.test.js

Specify exact versions of azurerm and helm providers to use. Refs #12 .

It seems like there are two ways of "locking" versions of providers. One if this, to specify it in the providers.tf. The other would be to create a .terraform.lock.hcl file with the locked dependencies.

The problem with that approach is that I needed to create a separate lockfile for dev, staging, and production, and that seemed like a lot of hassle - to remember to update those all locally, keep in sync, etc.

This seemed cleaner, but we can use the other approach if that seems better.

cc @geohacker

This is all a bit terrible.

So, changes to the azurerm version caused some properties to resources to change. Since terraform isn't great with updating Azure resources in place when properties changed, it wanted to re-create both the cluster and the IP address. This was causing cascading failures.

For now, what I've done is add a lifecycle argument to the Cluster and IP address Azure resources to just not do any updates on those resources.

@geohacker - let's discuss, but I think we should keep it that way. Unfortunately, allowing changes to cluster or IP address properties seems like it just results in too many problems. This is not ideal at all, but I don't have a better way.

For now, going to merge this and have staging work again.

Also, using $refs in the values.schema.json didn't quite work on CI, and had to revert that change as well.

We need to add a constraint on setting active=true on models that have storage=false, my understading is that a model file is required to create and run projects.

What I am changing

Fairly minor - get the $refs in the json schema to actually work - file://./ did the trick.

Tested that the helm chart seems to publish fine. We should keep an eye out on staging, but this shouldn't affect the deploy - just cleans up the values.schema.json file massively.

cc @geohacker

Context

Mosaic data is currently stored at the project level with subsequent AOIs of a given project inheriting the single mosaic type from their parent project. This has worked up until now as we have essentially only used the naip.latest mosaic for all projects.

Adding timeseries data complicates this model as it means that there is no relationship to be made between similiar AOIs that use mosaics with different timestamps. Although a user would be able to manually select mosaics that might overlap and compare them, a DB relationship wasn't possible.

This PR changes the way mosaic data is stored in the database and surfaced via the API. Mosaic data has been removed from the project data and is instead stored

• Project - Just a container for a given Model ID
• AOI - Contains Bound Data & Name
• AOI_TimeFrame - Contains most of the data that AOI formerly did (classes, patches, etc) as well as a new mosaic ID & mosaic Timestamp field

Closes: https://github.com/developmentseed/pearl-backend/issues/36

cc/ @geohacker

Currently we don't store the mosaic and date range an AOI (inference) is generated from. We should do this so downstream consumers can perform better change management.

@developmentseed/pearl

We should look at https://planetarycomputer.microsoft.com/explore?c=-104.9008%2C22.8615&z=4.40&v=2 and prepare a few different seasons of mosaics that we can use as a starter. This is related and required for #32.

We'll support advanced filters but this is important for a start.

cc @developmentseed/pearl

Our current AOI limits are:

• Live inference 100 km²
• Batch inference 200 km²

We should increase this based on what geometry sizes Reforestamos wants to run for. I'll look at that provide the numbers.

cc @ingalls

We should support Sentinel imagery from Planetary Computer. Unlike NAIP, with Sentinel we want to allow the frontend decide a time range for creating a mosaic to inference to run on.

I think the inference endpoint will now have to not only take the imagery id/name but also look for a time range which we need to use to query tiles.

@ingalls @vincentsarago let's chat more specifics about this. The frontend design has some implications. cc @LanesGood @vgeorge @batpad