Project TS

[ingalls]

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: #36

cc/ @geohacker

[geohacker]

@ingalls this is looking really great! thanks so much! One question I have is about mosaics (imagery source). I think we should have a table that registers mosaics which the frontend can list. And eventually the frontend will allow an interface to create them with the Planetary Computer API.

It can certainly be a separate PR but I do think currently it's unclear how we store mosaics.

cc @vgeorge

[batpad]

I needed to make a small change to the Helm templates for deploy to work on newer versions on Kubernetes: 1497007

These changes are now in develop + main and deployed here. It would be create if we could rebase this PR on develop / main and then I'll be able to deploy them onto our new cluster. @ingalls do you think you'd be able to rebase develop here and let me know, and then I can attempt a deploy? Thanks!

[LanesGood]

@geohacker should this be merged to a v2 branch?

[geohacker]

I'm tempted to merge this to develop. Let me mull a bit