Re: [Geotools-devel] Re: GIS raster data coloring

[Martin D. <mar...@te...>]

Andrea Aime a =E9crit:
>>P.S.: For styling, the "Recolor" operation could probably be of some
>>       help. However, it would need to 1) be extended in order to
>>       accepts Integer quantity as well as String and 2) maybe renamed
>>       "ColorMap" for consistency with OpenGIS styling specification.
>>
>=20
>=20
> It should be extended so that it accepts double quantities, since the
> sld specification accepts this kind of values. Then, if needed, it will
> convert quantities back to the integer format in order to apply them
> to categories.

Right.


> I was just having a look at the operation... why do we need an IndexCol=
orModel
> in the input?

Because it was the easiest to implements for a first version, and the=20
one that I needed for my own project. We should extends this operation=20
in order to accept other ColorModel needed.


  Say I'm loading data from an ArcGrid file... no color
> information whatsoever... my plan was to do something like:
> * read the floating point matrix, and compute max and min values;
> * use these to create a transformation that turns these values into int=
eger=20
> data...

Sound like a perfectly good approach to me.


  but here I'm a little stuck. If I choose to use the range 0..256 the
> data type will be byte, if I choose 0..65000 the data type will be u_sh=
ort...
> what does the user wants? Can I change the range of a SampleDimension
> at run time?

Yes, but it is cumbersome at this time. We have to create a new=20
GridCoverage for sure, since GridCoverage are immutable. We have to=20
create new SampleDimensions for this GridCoverage since SampleDimension=20
are immutable as well. We would have to use some code like this:

SampleDimension oldSD =3D ...
Category[] categories =3D oldSD.getCategories[];
for (int i=3D0; i<categories.length; i++) {
     Category old =3D categories[i];
     categories[i] =3D new Category(old.getName(), old.getColors(),=20
newRange, old.geophysics(true).getRange());
}
SampleDimension newSD =3D new SampleDimension(categories, oldSD.getUnits(=
));

This code replace the integer values range of all categories by a new=20
one. The name, colors and geophysics values range stay the same. Since=20
this code is not convenient to use, a convenience method or an operator=20
should probably be added. We just have to agree on the semantic of this=20
method and/or operator.

A possible way to make life easier may be to make the GridCoverage=20
constructor more intelligent. GridCoverage accept null SampleDimensions.=20
It could do a more intelligent work when the user didn't provides=20
explicitely sample dimensions. GridCoverage constructor could do by=20
itself exactly what you suggested: compute min and max value (probably=20
using the JAI "extrema" operator) and use these to compute scale and=20
offset value. This work could be done in the following package-private=20
method:

org.geotools.gc.GridSampleDimension.create(...)



> If I understand properly, the original floatin point resolution won't b=
e lost,
> anyway, isn't it? So it's possible to create an operation that changes =
the
> way data is discretized for display purposes.

Right.


> If we extend the operations available, also an Integer discretization w=
ould
> be possible, in order to support true color visualization, but this tim=
e the
> transformation would turn floatin point numbers into ARGB colors packed
> into a 32 bit value...
>=20
> Is this reasonable?

Yes, it sound all right to me :)

	Martin.