ContrastMethod is already a code list so you should be able to add the
options you need no problem.
The interface ContrastEnhancement is here:
public interface ContrastEnhancement {
public ContrastMethod getMethod();
Expression getGammaValue();
}
Where ContrastMethod is an enum:
public final class ContrastMethod extends CodeList<ContrastMethod> {
public static final ContrastMethod NORMALIZE = new
ContrastMethod("NORMALIZE");
public static final ContrastMethod HISTOGRAM = new
ContrastMethod("HISTOGRAM");
}
ContrastMethod is a code list, like an enum exception can add to it from
anywhere. So please create a couple new ContrastMethod values and we can
get on with life.
--
Jody Garnett
On 4 August 2015 at 12:25, Ian Turton <ijtur...@gmail.com> wrote:
>
>
> On 4 August 2015 at 19:26, Jody Garnett <jody.garn...@gmail.com> wrote:
>
>> Added my +1, got a couple questions/clarifications.
>>
>> *ContrastMethod*
>>
>> The proposal has been implemented in such a way that existing code will
>>> compile without change. One item to note is that `ContrastMethod.NORMALIZE`
>>> and `ContrastMethod.HISTOGRAM` are no longer enums but are now Strings.
>>
>>
>> That sentence seems indicates a break with API compatibility. Should this
>> change from an Enum to a CodeList (if the requirement is to add more
>> options at runtime while still retaining type safety). This would be less
>> of a break than changing to a String, indeed client code may not need to be
>> recompiled.
>>
>
> Technically it is an API break (hence why i mentioned it :-)) - but since
> ContrastMethod has become an interface instead of a concrete class I don't
> think they can remain as enums. I haven't found anywhere in the code or the
> tutorials where this change will break the code base. I suspect that
> anyone switching to 14.0 will need to recompile anyway?
>
>>
>> I ask as changing some of these string constants to Enums gave a lot of
>> trouble when migrating from geotools style to geoapi style. And I do not
>> want to repeat the experience.
>>
>
> Can you clarify this?
>
> To be clear I'm not adverse to doing the constants differently but I can't
> see a cleaner way now that ContrastEnhancement holds real objects instead
> of markers.
>
>
>> *Tasks*
>>
>> The tasks section is just boiler plate, I am always interested in making
>> sure we do not miss anything (interface/implementation/tests/docs/update
>> instructions) and confirm resourcing needs are met or we need to ask for a
>> volunteer.
>>
>> In this case are you comfortable writing a documentation example or do
>> you need me to volunteer.
>>
>> I'm already planning to update the docs as soon as we nail down exactly
> what the parameter names and algorithms will be.
>
> Cheers
>
> Ian
>
>
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
