The two paths described in this chapter serve different purposes and are both maintained. The raquet path is a self-contained MEOS value type: it carries its pixels and its QUADBIN georeferencing in a single value and needs no PostgreSQL to evaluate, so it is available to every language binding derived from MEOS. The PostGIS raster path offers the far richer raster processing of the postgis_raster extension, map algebra, statistics, resampling, clipping, conversion to polygons, inside PostgreSQL only.
Neither path replaces the other. Work on the raquet path extends what a cloud-native tile can do along a trajectory; it is not an attempt to reimplement raster processing.
A multi-spectral coverage is read band by band on either path. The RaQuet specification gives each band of a tile a column of its own, band_1, band_2 and so on, so such a coverage is a set of single-band tiles sharing one QUADBIN cell and rasterTileValue samples the band it is given, while on the PostGIS raster path the band argument names it. What a raquet value does not carry is the interleaved layout the specification offers for RGB imagery, which packs the bands of a tile into a single JPEG- or WebP-compressed column.
The extensions below require a general raster data model, that is, arbitrary spatial reference systems and arbitrary affine georeferencing. The extent and the pixel grid of a raquet value follow from its QUADBIN cell, so these lie outside that model and remain available through the PostGIS raster path:
Arbitrary spatial reference systems, tiles outside the Web-Mercator grid, and reprojection between reference systems.
Raster processing, map algebra, summary statistics, resampling, and conversion to polygons, together with clipping a tile to a region, such as the extent a set of trajectories visits over a time interval.