Investigate the Possibility of a MultipixelTile Type

[jamesmcclain]

As part of #1429, I found that a helpful schema was to think of different configurations of stacks of layers (whether Tiles, MultibandTiles, ordered sequences of Tiles, a Tile, two MultibandTiles and another Tile, &c) as consisting of multipixels (sequences of pixels), indexed by column and row.

This branch contains some work that was done in that direction.

While the idea is unifying and brings some conceptual benefits, there are also performance implications to be sorted out.

The PR comments originally associated with #1429 are reproduced below:

In this pull request the TileFeature[T, D] type is added.

Points to Examine

• The TileFeature[T <: CellGrid,D: ? => BundleMethods[D]] type takes two type parameters, but the merge methods (in both raster and spark assume that T <: Tile. There are no assumptions on D other than it being a member of the bundle type class.
• There is a question of range and precision of the data D. Right now they are treated as integer entities. Double versions are possible as well, but since one of the supported types of D is Seq[Tile], there is a question of how (best) to handle the situation when the data are mixed integers and floats.
• I found that I had to add these secondary conversions from subclasses of BundleMethods[D] to BundleMethods[D] in order to get the constraints on TileFeatureMergeMethods to be satisfied. The issue seems to be that the Scala compiler does not look more than one layer deep when trying to satisfy these constraints. If there is a better way to handle this, I am open to it.

[jamesmcclain]

Perhaps we should close this issue?

[lossyrob]

That makes sense. It will still be search-able in case a similar idea comes up.