Raster tile to pixels and back

[vsimko]

While writing a paper about BigGIS architecture, I realized that for the "pixelization" operation, we actually don't want the (ts, lat, lon) coordinates because they are more complicated to use when converting pixels back to a tile.
Instead, I would propose to use (sfc, offset) coordinates.

• Each tile has a space-filling curve index sfc = HASH_SFC(gridx, gridy, ts) generated by geotrellis.
• Each pixel within a tile has an offset = row * width + column

What do you think?

[aklink]

If the sfc hash is unique and we do not get problems with different zoom levels (when combining data from different sources, e.g. Aerial DOP and Sentinel2) while using the offset, then we can go this way.
For data exchange using CSV with software outside of the infrastructure, this would be difficult to handle, but this is not the default case (only using for testing).

[vsimko]

I would treat the layer name/zoom level as some kind of "global parameter" not passed to every pixel-sample. We usually want just the largest zoom of a particular layer anyways. The lower resolutions in a pyramid are computed only for rendering in browser.

Thus, for a particular layer name lname, we take the collection of tiles as T = max_zoom(lname).
Each tile from T has a sfc index assigned by geotrellis.

Here is a pseudo code for pixelizing a single tile:

  foreach row in 1..NROW {
    foreach col in 1..NCOL {
      val pxdata = foreach band in 1..NBANDS {
        yield tile[band, row, col]
      }
      yield (sfc, row, col, pxdata)
    }
  }

And here is a pseudo code for creating a stream of tiles from a stream of pixels pxstream:

pxstream groupBy(sfc) map { (sfc, pixels) =>
  val tile = new Tile(sfc, NBANDS, NROW, NCOL) // empty tile to be filled
  foreach (_, row, col, pxdata) in pixels {
    foreach band in 1..NBANDS {
      tile[band, row, col] = pxdata[band]
    }
  }
  return tile // tile filled with pixels
}

[vsimko]

related to issue #7

[vsimko]

@aklink - can we now close this issue ?

[aklink]

Yes. Can be closed.
There is one open aspect on it, how to handle the time stamp (maybe change SpatialKey to SpaceTimeKey), but this is a separate question with additional issues (how to get the meta data).