OGC Tiles API- Actual Tiles Onboarding Process

[code-akki]

A few open questions-

• For Vector Tiles generated using Feature Collections, we can be sure that an asset will be available in S3 as a geopackage, do we mandate the requirement that the asset must be a geopackage? (We can use ogr2ogr directly on the geopackage to generate the tiles)
• Where should the source file be located? [Considering /stac/collections-asset might get obsolete]
• What if the Tiles are already generated in the form of directory structure (think of OSM Map tiles) and is residing somewhere else, in which case we would need to either download the whole tileset or move it from one bucket to another?
• Can we run ogr2ogr directly on the source geopackage remotely and generate the tiles on S3 to avoid downloading and uploading?

[ThorodanBrom]

• Consider generating vector tiles from postgres DB feature table and directly write to S3 with ogr2ogr
• See if pre-signed URL can upload a directory of files
  • In case there is an existing set of raster/vector tiles

[DivyaSreeMunagavalasa]

Tiles Onboarding Process

The tiles onboarding process is to facilitate the optimisation aspect of serving feature data in an efficient manner through visualization. If the collection already exists as a feature, the expected process flow begins with the feature onboarding process, followed by the tiles metadata onboarding process, and then the actual tiles onboarding process. However, if the collection is a brand-new tile collection (i.e., it hasn't been onboarded as a feature previously), the tiles metadata onboarding process should occur first, followed by the tiles onboarding process.

There are total two main work flows for tiles onboarding process:

1. Onboarding the tile collection when the collection is already present as feature
2. Onboarding the brand new tile collection (previously collection doesn't exist as a feature)

The input json for tiles onboarding process can be same as feature onboarding process, something like this:
{
"inputs": {
"fileName": "Process-test/Airports.gpkg",
"resourceId": "7155c949-e4d3-478f-a3d4-20c54a796b8d",
}
}

Onboarding a Tile Collection when the Collection Already Exists as a Feature
Steps:

• Check for Existing Collection:
  Verify if the collection exists in the collection_type table as a "FEATURE." If it is present, it confirms that feature onboarding has already occurred.
• Convert Feature to Tile Collection:
  Using the provided file name from the input JSON (e.g., a .gpkg file in S3), employ ogr2ogr commands to convert the feature data into a tile collection.
• Upload the Tile Collection to S3:
  Then upload the tile collection into S3 using ogr2ogr (still need to figure out, how to do this)

Onboarding a Brand-New Tile Collection (No Existing Feature)
Steps:

• Identify New Collection:
  If the collection is not present in collection_type table, then it can be considered as a brand new tile collection
• Generate S3 Pre-Signed URL:
  • Need to use S3 pre-signed url process to generate a link to upload tile collection to S3 (still need to figure out if we have to use existing S3 pre-signed url process or embed the logic in the process itself)

There are two interdependencies of processes for tile onboarding process

• Tiles Meta Data onboarding process (This needs to be triggered before the actual tiles onboarding needs to be done)
• Using S3 pre signed url process in the onboarding flow for brand new tile collection

Given the current time frame, the plan is to integrate these two processes into the tiles onboarding flow at a later stage because we still need to figure out how to integrate multiple processes.