Sounds great, Martin! Thanks for the update. Don't forget to include EPSG:4326 :)
A On Sun, Feb 22, 2015 at 7:18 PM, Martin Desruisseaux < [email protected]> wrote: > 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 > >
