Class DefaultParameterValue<T>

Object
FormattableObject
DefaultParameterValue<T>
Type Parameters:
T - the type of the value stored in this parameter.
All Implemented Interfaces:
Serializable, Cloneable, Lenient­Comparable, Printable, General­Parameter­Value, Parameter­Value<T>
public class DefaultParameterValue<T> extends FormattableObject implements ParameterValue<T>, LenientComparable, Serializable, Cloneable
A single parameter value used by an operation method. Each Parameter­Value is a (key, value) pair, and an arbitrary number of those pairs can be stored in a a parameter value group. In the context of coordinate operations, parameter values are often numeric and can be obtained by the int­Value() or double­Value() methods. But other types of parameter values are possible and can be handled by the more generic get­Value() and set­Value(Object) methods. All xxx­Value() methods in this class are convenience methods converting the value from Object to some commonly used types. Those types are specified in ISO 19111 as a union of attributes, listed below with the corresponding getter and setter methods:
Mapping from ISO attributes to getters and setters
ISO attribute Java type Getter method Setter method
Object getValue() setValue(Object)
stringValue String stringValue() setValue(Object)
value double doubleValue() setValue(double)
double doubleValue(Unit) setValue(double, Unit)
valueList double[] doubleValueList() setValue(Object)
double[] doubleValueList(Unit) setValue(double[], Unit)
integerValue int intValue() setValue(int)
integerValueList int[] intValueList() setValue(Object)
booleanValue boolean booleanValue() setValue(boolean)
valueFile URI valueFile() setValue(Object)
valueFileCitation Citation getValue() setValue(Object)
The type and constraints on parameter values are given by the descriptor, which is specified at construction time. The parameter type can be fetch with the following idiom: 
Class<T> valueClass = parameter.getDescriptor().getValueClass();

Resolution of URI parameter values

Parameters that are too complex for being expressed as an int[], double[] or String type may be encoded in auxiliary files. It is the case, for example, of gridded data such as datum shift grids. The name of an auxiliary file is given by value­File(), but often as a relative path. The directory where that file is located depends on the operation using the parameter. For example, datum shift grid files used by coordinate transformations are searched in the $SIS_DATA/Datum­Changes directory, where $SIS_DATA is the value of the environment variable. However, this approach requires that all potentially used auxiliary files are preexisting on the local machine. This assumption may be applicable for parameters coming from a well-known registry such as EPSG, but cannot work with arbitrary operations where the auxiliary files need to be transferred together with the parameter values. For the latter case, Apache SIS fallbacks on URI relative to the directory of the JSON, GML or WKT document where the parameter value appears. This resolution can be done only if the document directory is specified by the get­Source­File() method.

URI parameter values are not resolved by this class, but by the operation which uses this parameter. For security reasons, an operation may reject URIs that are not in the expected directory. For controlling which URIs to accept, see Math­Transform­Builder​.set­Access­Control(Bi­Function).

Instantiation of parameter values

A parameter descriptor must be defined before parameter value can be created. Descriptors are usually predefined (often hard-coded) by map projection or process providers. Given a descriptor, the preferred way to create a parameter value is to invoke the Parameter­Descriptor​.create­Value() method. It is also possible to invoke the constructor directly, but the former is recommended because it allows descriptors to return specialized implementations.

Implementation note for subclasses

All read and write operations except constructors, equals(Object) and hash­Code(), ultimately delegates to the following methods: Consequently, the above-cited methods provide single points that subclasses can override for modifying the behavior of all getter and setter methods.
Since:
0.4
See Also: