ColorMap => String - #1512

To test:

sbt
project raster
console
import geotrellis.raster.render.ColorMap
val m = ColorMap.fromString("23:cc00ccff;30:aa00aaff;120:ff0000ff").get
ColorMap.breaksString(m.breaksMap)

Really, the best thing would be for ColorMap to be polymorphic on its internal number type:

trait ColorMap[T] extends Serializable { ... }

And then duplicate code between IntColorMap and DoubleColorMap could be removed. Then, the ColorMap trait could ask for a def breaksMap: Map[T,Int], and breaksString could be moved into the trait defined as:

def breaksString: String = {
  breaksMap  // was `breaksToColors` passed in as an argument
       .toStream
       .map({ case (k,v) => s"${k}:${Integer.toHexString(v)}"})                                           
       .mkString(";")
}

The huge downside of this would be that client code would have to care about the parameterized ColorMap[T], unless we used some cool type aliasing so nothing breaks.
Thoughts, @lossyrob @echeipesh ?

@lossyrob why I'm not in favour of just defining the .toString this way is because it's considered bad form in Haskell-land to have custom output for the show :: Show t => t -> String function, which is similar to toString. Typically show gives you the raw serialized form of the object, such that:

read . show == id

and other "pretty printing" functions are given obvious names.

Another trip-up: the user-level API doesn't expose IntColorMap, etc, only ColorMap. The colouring function has to be visible to the trait. You could put it in the companion object (as I've done initially here) but then the arguments to it must also be visible to the trait. IntCachedColorMap throws a wrench into that, as it has no Map internally, but still extends ColorMap.

Your hitting up against the need for us not to abstract over Int and Double typed things due to performance implications. We jump through hoops to have Double and Int versions of things because if we try to make it generic, things slow down in very painful ways - boxing is the enemy, and ColorMaps are performance critical code that must not box.

I'm not sure "it not being good form in Haskell" is a good reason to avoid using the method that's there, defined as returning a string representation of the object. One could argue that the string representation of a color map that you are concocting is actually a good representation for a user trying to read what the color map is; however, even if we wanted to differentiate between a "show" toString and some other form (def breaksString: String), we could still use implementations in the concrete classes to take care of the Double vs Int bits and avoid the generic breaksString method you have.

haskell

That was more of an explanation as to my natural want to avoid that pattern, not necessarily that we should do it that way "cause Haskell". The question becomes, where do we want the isomorphism? Between ColorMap.fromString <-> breaksString or ColorMap.fromString <-> toString?

re: my last comment. override toString could work for the inheritance problems. I'm not a fan of the duplicate code, but if this is performance critical than I can see the need.

Gotcha. Yeah I think the argument could be made though that we would want to avoid using toString because it's too generic of a thing, and instead use the breakString with inheritance.

Meaning the actual definition of breaksString will be duplicated between the *ColorMap classes for performance reasons? I'll do it that way if that's the prevailing pattern.

More to do with why we can't do

trait ColorMap[T] extends Serializable { ... }

and be generic on T.

But code duplication in this case might be tough to avoid, since the code to deal with doubles and ints will look the same (but not with the cached version of int, which you mentioned above).

Good to go, @lossyrob .