some function parity with MVT

[CraigglesO]

With MVT the VectorTile has a 'layers' object property where you access the VectorTileLayer via its layer name as the key.

The VectorTileLayer has a feature function for accessing features like so:

feature (i: number): VectorTileFeature {
    // ...
}

lastly, the VectorTileFeature has a loadGeometry() function and the before mentioned S2 spec has a loadGeometryFlat() function.

While this may not take full advantage of the COVT performance benefits, I argue that at a minimum the same function names should exist/overlap with existing tools. That way existing tools can look something like this:

processVector (
    // ...
    vectorTile: VectorTile | JSONVectorTile | CloudOptimizedVectorTile
  ): void {
    // grab the layer of interest from the vectorTile and it's extent
      const vectorLayer = vectorTile.layers[sourceLayerName]
    // iterate over the vector features, filter as necessary
      for (let f = 0; f < vectorLayer.length; f++) {
        const feature = vectorLayer.feature?.(f)
        if (feature === undefined) continue
        const { properties } = feature
        // filter out features that are not applicable, otherwise tell the vectorWorker to build
        if (filter(properties)) {
          const wasBuilt = workers[type]?.buildFeature(tile, feature, sourceLayer as any)
          if (wasBuilt === true && layers[layerIndex] !== undefined) layers[layerIndex]++
        }
      }
}

While this is much less important but to showcase the current code for parsing polygons:

buildFeature (...inputs): boolean {
    // ...
    const [geometry, indices] = feature.loadGeometryFlat !== undefined
      ? feature.loadGeometryFlat()
      : [feature.loadGeometry?.(), [] as number[]]
   // ...
  }

[nyurik]

In MVT, layers are stored as an array of Layer objects, and each object is required to have a string name property. So the "access by name" is a feature of the access library, not the format itself, which also means that it is used as a document (pre-parse everything into memory) rather than as a stream (produce a stream of items, minimal mem requirement). I would argue that for COV-Tiles, we should focus on the actual storage format and an absolute minimal IO library, rather than on extra features like in-memory representation of the parsed values

[CraigglesO]

That is a good point, if it prohibits properly interacting with the library or adding unnecessary overhead than you can ignore my initial points. However, if some of the functions mentioned above make it into the codebase, it would be great to have overlapping naming.

To give another example here is how maplibre-gl-js loads geometry. Not having to write two separate load_geometry functions where you can access feature.extent, feature.properties and feature.loadGeometry() would be a nice way for COVT to introduce less friction.

Maybe non of this is possible, but something to consider.