Customizable handling of sample size of a coverage point

[Piero Campalani]

While GML does not provide formal means for describing the sample size (footprint) of a coverage's point, it would be clearly important to implement at least a basic handling of such attribute.

"Basic" means that we can stick to rectilinear n-D cells as representation of footprints (intervals, pixels, voxels, and so on), at first: no circular, hexagonal or other shapes. We can also start with the assumption that the coverage point is placed in the centre of the footprint, while shifting to a later stage the management of different placements of the point, e.g. in the corner/border or a footprint.

At the moment, cells with the same widths as the offset vectors along each dimension are assumed as footprints along regular grid axes (point is area). 0D footprints (point is point) are assumed on irregular axis, otoh.

Being able to configure such behaviors can have double advantage:

1. on regular grids or subsgrid, that would mean that a user can be able to specify that the points are indeed points, and should not be considered areas (e.g. in the GTiff standard you have ​PixelIsPoint and PixelIsArea attributes];
2. on irregular grids or subsgrids, that would mean that a user can specify a spatial or temporal support: an important use case is the ability to have irregular time series of data but which do cover a non 0D time interval (eg temporal aggregates).

Both cases are important and would surely provide a major plus in the capabilities of Petascope.

NOTE: as a workaround for having PixelIsPoint behaviors on regular grids, the coverage can be imported as a referenceable grid (though with regular spacing); as a (not efficient and not always possible) workaround for having footprints on irregular grids, such coverages should be imported as rectified regular grids with empty cells filling the in-between cells.

[Peter Baumann]

hm, what would that mean for point cloud coverages?

[Piero Campalani]

Also point clouds could have this feature (in practice it would mean eg a single vector specifying the half-width of the nD area surrounding every point), tough I feel that point clouds are usually better represented as points.