Hello all
Summary or recent work: SIS got its first "math transform factory"
ported. The concept of "math transform" come from an old OGC standard,
OGC 01-009 [1], which in theory is superseded by ISO 19111 for the
Coordinate Reference System (CRS) model and by the upcoming ISO 19162
for the Well Known Text (WKT) part, but still have a few areas not yet
covered by newer standards. The MathTransform interface is one of them
(maybe the last one).
MathTransform is the interface that does the actual work of converting
or transforming coordinates from one CRS to an other CRS. MathTransform
are created by a MathTransformFactory from a group of parameters [2].
The framework must be able to:
* Allow users to plugin their own map projection implementations. We
do that by the use of java.util.ServiceLoader.
* Be able to describe their parameters (name, type, default value)
since each map projection have their own set of parameters. ISO
19111 gives us structures for that [3].
* Supports aliases, since the same parameters often have different
names depending on the software vendor.
* Supports identifiers (e.g. "EPSG:9624" for "Affine parametric
transformation"), which as of ISO 19162 is the recommended way to
identify parameters in order to solve the confusion caused by the
differences in the names.
Special care must be taken to "not lie", i.e. if we said that an
operation method is "EPSG:9624", then the parameter definitions shall
match exactly the EPSG:9624 definition. I think it is okay to add
aliases or optional parameters, but at least the main characteristics
shall not be modified, otherwise this is not EPSG:9624 anymore. The "do
not lie" rule is surprisingly often broken in many existing software,
where unit of measurement and axis order are often altered while the
software continue to claim to be EPSG compliant. This is one of the
major interoperability problem we face. I would like Apache SIS to be
exemplary regarding respect of EPSG and other standard definitions. But
ironically, it may put us on a odd vis-à-vis other players.
The first operation method ported to SIS is "Affine parametric
transformation" (EPSG:9624). It has been long because of all the
framework to put in place, and also because of the differences between
EPSG and OGC parameters that we wanted to handle as transparently as
possible. Compared to what we had in Geotk, the Apache SIS code tries
harder to match the EPSG definition. Other operation methods will
hopefully be faster.
Martin
[1] http://www.opengeospatial.org/standards/ct
[2]
https://builds.apache.org/job/sis-dev/javadoc/org/apache/sis/referencing/operation/transform/DefaultMathTransformFactory.html
[3]
https://builds.apache.org/job/sis-dev/javadoc/org/apache/sis/referencing/operation/DefaultOperationMethod.html
