All traits that inherit CellGrid and Grid should be abstract classes

[pomadchin]

Overview

This PR makes Tile, ArrayTile and MultibandTile abstract classes. In our types hierarchy Tile types extend CellGrid and Grid. In 2.x both Tile and CellGrid were traits, and in 3.x CellGrid became an abstract class, so we had a not very usual case, where traits extended abstract classes. This is not possible in Java and creates problems on Spark, for more details looks into #3134

This is the idea suggested by @echeipesh and it is probably the best solution.

Checklist

• docs/CHANGELOG.rst updated, if necessary

Demo

scala> :javap geotrellis.raster.Tile
  Size 11433 bytes
  MD5 checksum 973688ee6c0ddfd43788d33a6cee0989
  Compiled from "Tile.scala"
public abstract class geotrellis.raster.Tile extends geotrellis.raster.CellGrid<java.lang.Object> implements geotrellis.raster.IterableTile, geotrellis.raster.MappableTile<geotrellis.raster.Tile>

scala> classOf[geotrellis.raster.CellGrid[_]].isAssignableFrom(classOf[geotrellis.raster.Tile])
res0: Boolean = true

scala> classOf[geotrellis.raster.CellGrid[_]].isInstance(geotrellis.raster.IntConstantTile(1,2,3))
res1: Boolean = true

scala> classOf[geotrellis.raster.CellGrid[Int]].isAssignableFrom(classOf[geotrellis.raster.Tile])
res2: Boolean = true

Closes #3134

[metasim]

Wow... that's it?

Did you confirm that new Raster(tile, extent) works in Java?

[pomadchin]

@metasim yep:

raster > run
[info] Running RasterInstantiation 
[success] Total time: 3 s, completed Oct 22, 2019 12:27:02 PM

[metasim]

I wonder if the following should preemptively converted to abstract classes:

• geotrellis.raster.RasterRegion
• geotrellis.raster.RasterSource
• geotrellis.raster.MosaicRasterSource
• geotrellis.raster.ProjectedRasterLike
• geotrellis.raster.DelegatingTile
• geotrellis.raster.ConstantTile
• geotrellis.raster.MutableArrayTile

[pomadchin]

@metasim should be (was in progress)

[metasim]

Got some more feedback:

I think this should be the definition for ProjectedRasterLike:

trait ProjectedRasterLike  { _: CellGrid[Int] =>
  def crs: CRS
  def extent: Extent
}

[pomadchin]

@metasim do you want it to be a mixin?

[metasim]

In RF it's used as a means to show conformity among a few different types for operations that want, say just an Extent or CRS, etc.

Not sure if that qualifies as a mix-in, or just "shape compliance" like an old-style interface.

[pomadchin]

@metasim sweet, thanks for looking into it that hard 💯

[pomadchin]

@metasim do we even need this constrain? _: CellGrid[Int] =>

[metasim]

Yes, we need the constraint, because it forces cols and rows to exist. Could use structural types, but ick.

[metasim]

Maybe this instead?

trait ProjectedRasterLike {
  def crs: CRS
  def extent: Extent
  def cellType: CellType
  def cols: Int
  def rows: Int
}

[pomadchin]

@metasim will look into what is possible to do here

[echeipesh]

My vote is for

trait ProjectedRasterLike {
  def crs: CRS
  def extent: Extent
  def cellType: CellType
  def cols: Int
  def rows: Int
}

... version. Trait self typing is another of those weird scala features that isn't really necessary (?). Also proposed variation is more flexible since it doesn't mention CellGrid.

[pomadchin]

@echeipesh yep, my point was that we don't need _: CellGrid[Int] => since it doesnt expose functions that @metasim wants (this was discussed in a gitter channel)

[echeipesh]

Looks good, solves the problem. Wish we could just remove N from CellGrid but that is a tricky thing to do with time we have right now.

[echeipesh]

3.1.0 release

[pomadchin]

requesting the last quick look at the ProjectedRasterLike @metasim @echeipesh

[echeipesh]

@pomadchin this looks good to me. Need changelog entry and version bump to 3.1.0