Create TMS Generation web service

[lossyrob]

Create the service that listens for requests to tile an imagery set, whether this is called on new imagery uploaded by an HOT user or as a request from the OAM Catalog.

This service will validate the request, kick off the TMS creation processing, and notify OAM Catalog when the processing is complete, with metadata about the newly minted TMS service.

[mojodna]

How should we persist the existence and settings for a given tile service? How do we discover it on server startup?

[lossyrob]

I was thinking that OAM Server would be dumb about this, and just pass the information to OAM Catalog. It would maybe be worth having a log of processing requests and completions that could be queried via another endpoint, running alongside the same server that the request endpoints are running on. Not sure...we can figure out how much it make sense to store on that server, where a spectrum would be from running a PostgreSQL instance for keeping tabs no everything, to it being completely dumb and relying on OAM Catalog to store any info.

[mojodna]

From conversation:

The VRT is the manifestation of the imagery set that was requested (which may contain subsets of multiple sources (nodes/locations/nomenclature tbd)).

[mojodna]

VRT → configuration, loaded dynamically by one or more tessera instances (running in containers or otherwise). Tradeoffs with running a single tessera instance with multiple configurations vs. multiple instances with individual configurations.

[mojodna]

Important metrics to track: number of requests waiting to enter the threadpool / threadpool utilization

[lossyrob]

The tile server will be able to point to the VRT that represents the raw imagery set (fully dynamic) and also imagery that is fully tiled/overviews are generated in a preprocessing step (fully static).

We'll have to measure these against each other considering:

• performance
• storage
• cost
• flexibility