Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RasterSources should not be case classes #228

Open
echeipesh opened this issue Aug 12, 2019 · 0 comments
Open

RasterSources should not be case classes #228

echeipesh opened this issue Aug 12, 2019 · 0 comments

Comments

@echeipesh
Copy link
Collaborator

echeipesh commented Aug 12, 2019

The source of the issue is running into cases where I needed to override GDALRasterSource and MosaicRasterSource methods for application specific reasons. However, that is not possible because GDALRasterSource is a case class and can't be extended and MosaicRasterSource is a trait and its constructor isn't accessible (more on this later).

Here is my list of reasons why our RasterSource should not be case class.

  1. It is not a case class. Case class is supposed to be a named data container with light functionality, that has meaningful equality and can be matched against. RasterSource represents a set of rich I/O functionality and is basically the furthest thing from "data container".
  2. Many RasterSources don't have meaningful unapply: is a great example. It has multiple constructors
  3. Sometimes it's reasonable to override RasterSource methods. I don't know why exactly but changing the behavior under reproject or resample are at least two perfectly reasonable things to do. Why require creating an adapter?
  4. Controlling toString. With as much crud as we shove into the conductors the case class toString implementation becomes unhelpful.
  5. The case class equality does not have a clear and unsurprising meaning for lots of RasterSources. Are two GeoTiffRasterSources equal only if they share the same baseTiff or if they point to the same source file with the same "view" (CRS/pixelGrid) of the data?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant