The following are GeoAPI comments (not OGC comments). Those observations were collected during the process of hand-editing the Java interfaces that were created automatically from the UML by a script. In the following discussion, "specification 2003-73" refers to the abstract specification Spatial Referencing by Coordinates (Topic 2), while "specification 2001-009" refers to the implementation specification Coordinate Transformation Services. The later was based on a older abstract specification.
There is no standard parameter names and no "Well Know Text"
(WKT) format in the 2003-073 specification. Standard parameter names and format were proposed
in the 2001-009 specification (e.g. "semi_major", "semi_minor",
"standard_parallel_1", etc.). Some developers have already accepted
those names as "standard". For example, OGC parameter names are listed on the
remotesensing.org web site.
| PROPOSAL: |
Well Know Text format and parameter names from the legacy 2001-009 specification should be ported to the 2003-073 specification. They are proposed standards; we recognize that different vendors already use different sets of parameter names. |
No exception are defined in case of failure (for example if a map projection fails to converge because the coordinate point is outside the valid area).
| PROPOSAL: |
The specification should
defines some minimal set of exceptions (e.g. |
There is no localization support in all specifications I have read up to date.
Localization is an European Union requirement. Some country like Canada requires bilingual software
in their administrations. However, not all CharacterString should be localizable; for
example Well Know Text or code name should probably be language neutral. The way to
localize a character string is profile-dependent, but the UMLs should at least specify which
CharacterString are localizable and which ones are not.
| PROPOSAL: |
Add a new stereotype in UML:
|
The ImageCRS interface is defined as a kind
of engineering CRS, but doesn't extend EngineeringCRS.
Maybe it should (there is no obvious technical reason preventing that).
| PROPOSAL: |
Move (in the hierarchy)
|
"operationMethod" attribute is defined in
CoordinateOperation, but applied only to
Transformation (a sub-interface). Maybe
it should be defined only in Transformation interface.
| PROPOSAL: |
Move down (in the hierarchy)
the " |
CompositeCurve
extends (indirectly) both Primitive and Complex. Consequently,
there is a clash in the semantics of some set theoretic operation. Specifically,
Primitive.contains(...) (returns FALSE for end points) is different
from Complex.contains(...) (returns TRUE for end points).
| PROPOSAL: |
(none at this stage). |
Factory and operations from the legacy 2001-009 specification have been ported to the 2003-073 specification. This is because UML diagrams found in the 2003-073 specification contains only attributes or associations, no operations. Many services found in the legacy 2001-009 specification are not available in latest UML. More specifically:
CT_MathTransform
interface).CT_CoordinateTransformationFactory
interface).Dropped the CRS interface. This has the side effect of
allowing CompoundCRS to contains
other CompoundCRS. An other side effect is to resolves some misleading attribute
or association name. For example "includesCRS" in
CompoundCRS is of type
CoordinateReferenceSystem,
not CRS.
This fix was done because the CRS interface stands between
ReferenceSystem and
CoordinateReferenceSystem
and looks like an anomaly in an otherwise quite natural hierarchy
(CoordinateReferenceSystem extends ReferenceSystem).
"CRS" is just an abbreviation for "CoordinateReferenceSystem";
its name doesn't give any clue about the difference between those two interfaces.
Furthermore, the main "raison d'être" for CRS seems to be related to the
CompoundCRS's contract ("A Compound
CRS is a coordinate reference system that combines two or more coordinate reference systems, none
of which can itself be compound" - emphasis is mine). This contract is enforced
by the hierarchy (CompoundCRS is the only "FooCRS" interface that
extends directly CRS) and by the getCoordinateReferenceSystem
return type. But I question it for the following reasons:
In "Coordinate Transformation Services" (OGC document 01-009), compound CRS was specified as a pair of arbitrary CRS ("head" and "tail"). Each of them can be an other compound CRS, allowing the creation of a tree. This design was convenient to use (see next points below) and avoid a special hierarchy for compound CRS; it is just like any other CRS.
It is convenient to use CompoundCRS as building
block for more complex CompoundCRS, and get back the original one
later. For example a user could creates the following:
CRS vertical = new VerticalCRS(...);
CRS temporal = new TemporalCRS(...);
CRS cs2D = new GeographicCRS(...);
CRS cs3D = new CompoundCRS(cs2D, vertical);
CRS cs4D = new CompoundCRS(cs3D, temporal);
Then, at some later stage, breaks cs4D in its two
components (headCS and tailCS in OGC 01-009's terminology)
and compares the head CRS with cs3D. The user may wants to do
that because its own code may have some special hooks for cs3D,
since he has built this CRS himself. With the current CompoundCRS
speficiation, this approach is not possible since getCoordinateReferenceSystem
allow only a flat view of component's CRS; any user custom CompoundCRS
(and all remarks, identifiers and other useful informations) are lost.
A remaining issue is to define the semantic of getCoordinateSystem()
and getDatum() methods for CompoundCRS.
Various proposal may be considered:
null;UnsupportedOperationException;CoordinateSystem
and Datum, which don't need to be public: the
CompoundCRS implementation can generate them as needed.
Note that this behaviour may actually be quite useful. For example,
a CompoundCRS made of a GeographicCRS with
a VerticalCRS have a 3-D EllipsoidalCS.Moved (in the hierarchy)
CartesianCS as a sub-interface of
ObliqueCartesianCS. This is
because the interface CartesianCS
looks like a special case of ObliqueCartesianCS.
This is a similar argument than the one used in ISO-19107, which said that Circle is a sub-class
of Ellipse since the former is a special case of the later (see 5.1.5 Strong substitutability).
Doing so help to clarify the semantic of ImageCRS:
We dropped "cartesianCS" and "obliqueCartesianCS" attributes and
replaced them by a restriction on the "usesCS" association, exactly like what
is done in ProjectedCRS.
Dropped all classname prefix in "name" and "ID"
attributes. Moved "name", "ID" and "remarks" attributes
in a common super-interface,
Info, which is set as the parent of the following interfaces:
ReferenceSystem,
CoordinateSystem,
CoordinateSystemAxis,
Datum,
PrimeMeridian,
Ellipsoid,
CoordinateOperation,
OperationMethod,
GeneralOperationParameter.
This interface defines the getName, getIdentifiers and
getRemarks methods, which are common to all above-cited interfaces.
This Info root interface is similar to the legacy
CS_Info
interface from the implementation specification 1.0. In the 2003-073 specification, the name
and identifier attributes were duplicated in many interfaces, with different identifier name
(e.g. "ellipsoidName", "datumName", "csName",
"crsName", etc.).
Union structures avoided. While it is possible to mimic C's union
in Java, the hacks are usually unconvenient. Furthermore, union are not type-safe even
in C. Consequently, the following structures were omitted:
CD_SecondDefiningParameter (replaced by an API similar to the legacy
CS_Ellipsoid).
Added a
Projection interface as a special kind of
Conversion. Subinterfaces of
Projection make it possible to check which kind of projection is applied
(planar, cylindrical, conical...).
Added a
Matrix interface as the parent of
CovarianceMatrix.
The legacy 2001-09 specification defined a
PT_Matrix
interface, which is required for derivative computation. The 2003-073 specification
defined only CovarianceMatrix,
which is too restrictive.
Added AxisDirection
code list. It is actually an anticipation on future work planed by the specification team.
The getDirection()
return type was adjusted accordingly. Note that the legacy 2001-09 specification defined a
CS_AxisOrientationEnum
where the 2003-073 specification just used a plain character string.
Added the following methods into
AxisDirection:
inverse() and absolute().
Renamed ParameterValueGroup.getGroup() method as
getDescriptor()
and moved it in the hierarchy up into
GeneralParameterValue.
The getDescriptor() name was choosen because getGroup() seems too
restrictive, misleading (it returns an abstract definition of a group of parameters, not the
actual group), and for consistency with usage in other Java extensions (e.g. JAI's
ParameterList).
Moved the
GeneralOperationParameter,
OperationParameter,
OperationParameterGroup,
GeneralParameterValue,
ParameterValue,
ParameterValueGroup,
InvalidParameterNameException,
InvalidParameterTypeException and
InvalidParameterValueException
interfaces from org.opengis.referencing.operation to org.opengis.parameter
since it is of use for grid coverages as well as operations. The goal is to avoid a
duplicated API for parameters in coordinate operations and grid coverage operations.
Moved up (in the hierarchy) the "maximumOccurs" attribute from
OperationParameterGroup into the
GeneralOperationParameter
super-interface, in order to be on per with the "minimumOccurs" attribute.
Removed the DerivedCRSType code list, since a Java
expression like (baseCRS instanceof FooCRS) provides the same capability
with more flexibility.
Renamed GM_Object as
Geometry
in order to avoid ambiguity with java.lang.Object.
Moved Envelope
and DirectPosition
in the root geometry package (org.opengis.spatialschema.geometry) since they are
used in many places in most packages.
In Coverage, changed
evaluateAsDouble(DirectPosition) into evaluate(DirectPosition, double[])
for reusing optionally pre-allocated array. This is consistent with Java usage in Raster
for example. Same apply to all evaluateAsFoo(DirectPosition) methods.
In GridCoverage, changed
getDataBlockAsDouble(GridRange) into getDataBlock(GridCoverage, double[])
for reusing optionally pre-allocated array. This is consistent with Java usage in Raster
for example. Same apply to all getDataBlockAsFoo(GridRange) methods.
Return type of
Coverage.getSource(int)
was relaxed from GridCoverage to Coverage. Instead, the return
type has been constrained to GridCoverage only in
GridCoverage.getSource(int).
This approach (return type covariance) was already used in "Spatial Referencing by
Coordinates" (ISO 19111). It avoid forward dependency of Coverage toward
GridCoverage and give more flexibility for use of Coverage
with non-gridded data.
In Coverage, added an optional
getRenderableImage
method for interoperability with Java2D.
In SampleDimension, added an optional
getSampleToGeophysics
method as a generalization of scale and offset attributes.
Exceptions
MetadataNameNotFoundException
were declared only once in the CV package, not duplicated in every packages.
Omitted
InvalidIndexException (replaced by IndexOutOfBoundsException) and
ErrorExportingGridCoverageException (replaced by IOException).
Added
CannotEvaluateException as a super-class of
PointOutsideCoverageException.