General
Metadata and utilities
org.geotools.util splitted
ObjectCache rewritten
Referencing
ProjectionException thrown
MathTransform providers moved
Coverage
Display
Other
Geotk uses the mercurial distributed version control system whereas GeoTools 2 uses the a centralized version control system Subversion. Since it is expected that many uses will want to use a modified version of the library, either because they have local changes particular to their own work or because they do not agree with a technical decision made by the Geotk project, it was considered useful to move to a distributed versioning system. Mercurial was selected because it combined an easy to use command-line interface, good support by the NetBeans IDE, and because already in use for the development of major software projects such as Java itself, OpenOffice, OpenSolaris, NetBeans, Firefox and Python.
| [top] |
Geotk targets Java 6 while GeoTools 2 targets the older Java 5. This allowed Geotk to integrate the use of the new annotations defined in the new version. The code in several methods saw significant speed improvements due to the leveraging of new API defined in Java 6. The transition fixed the compilation errors when using Java 6. The dependency to the JAXB JAR was removed since this is now part of the Java runtime itself.
| [top] |
In the transition to Geotk almost all of the several thousand javac and
javadoc warnings were fixed. The build was made more robust so that the
javadoc could be built and the site fully deployed.
| [top] |
The last remaining trace of Java Advanced Imaging (JAI) dependencies were removed from the referencing module. Log4J and commons-logging dependencies were also removed from the core modules and provided instead as independent plugins. JAXB annotations rely only on the library provided in Java 6.
| [top] |
GeoTools 2 organized the modules in library, plugin,
extension and unsupported sub-directories. In Geotk
those directories are gone. They are replaced by "general topic" directories like
metadata, referencing and coverage. Each of
those directories regroup the core library and the plugins related to their topic.
For example the referencing directory contains the core referencing
library and all EPSG plugins.
Note that there is no concept of "unsupported modules" in this structure. Since we migrated to Mercurial versioning system, experimental work can be done on a clone of the public repository.
| [top] |
In addition to the usual compressed JAR files deployed to the Maven repository, the build process creates also bundles. When using those bundles, most of Geotk code and dependency (including GeoAPI) are available in a single JAR file.
| [top] |
GeoTools 2 contains a number of command-line tools scattered through the class hierarchy.
Some of them are quite useful but largely ignored. In Geotk, all command-line tools are
centralized in the org.geotoolkit.console package. The amount of main classes
has been reduced by regrouping functionalities in only a few (but more powerfull) main classes.
Their capabilities are better documented with help screen and usage examples.
| [top] |
Together with the development of Geotk, a set of implementation-independant validators has been commited to GeoAPI. Those validators (and some related classes) can be shared by other projects than Geotk. Objects that are created during Geotk test suite can be checked by those validators, which perform a more extensive object inspection than GeoTools 2 ever had.
More about GeoAPI conformance module.
| [top] |
A partial list of bug fixes is provided in the GEOT-2117 task. This list is only partial since many fixes were applied when the bugs were noticed, without corresponding JIRA tasks.
| [top] |
Geotk is built fully every day by the Hudson build tool. The build includes running the complete test suite and performing an analysis of the code base. Successful builds are then deployed to the maven repository. Hudson provides a web page which lists the information for the recent daily builds.
| [top] |
In GeoTools 2, the metadata module was also a home for a large set of utility classes, including a growing set of collection implementations, the factory registry, etc. In Geotk the utility classes moved to their own module, and the metadata module is now focusing specifically on metadata.
| [top] |
org.geotools.util splitted
In GeoTools 2, the org.geotools.util package has grew considerably.
In Geotk it has been splitted. The numerous collection implementations moved to
the org.geotoolkit.util.collection subpackage.
The GenericName implementations and related classes moved to a new
package, org.geotoolkit.naming.
| [top] |
In GeoTools 2, some implementation classes begin with the Default prefix and
some other ones end with the Impl suffix. The former was the usage in the referencing
module while the later was the usage in the metadata module.
In Geotk a more consistent naming scheme is applied. The prefix approach has been preferred
to the suffix one because it is a slightly more etablished practice in the standard JDK, and it
leads more naturally to different prefix. Default and Abstract are the
most common, but there is also a few others. For example General is used in order
to communicate that a particular implementation can work with an arbitrary number of dimensions,
as opposed to implementations specialized in the 2D or 3D case.
While it sound like a massive esthetical change, this one is easily handled by an automatic migration tool.
| [top] |
Support of system properties has been removed (it was there mostly for GeoTools 2.0 compatibility). Management of default hints has been simplified in the hope to get ride of the bugs that caused developers to still use the system properties.
Ordering based on priority level has been removed. They are replaced by the pair-wise
ordering mechanism bundled in Java ServiceRegistry class, and controlled in
Geotk by the Factory.Organizer inner class.
| [top] |
ObjectCache rewritten
ObjectCache and related classes have been removed. They are replaced by
Cache, which offer in a unique place the union of the ObjectCache
concurrency (improved by the removal of a global lock) and the SoftValueHashMap
capability to turn strong references into soft of weak ones.
| [top] |
Statistics, Plane and Line classes now compute
their sums using the Kahan
summation algorithm for reducing the numerical errors.
| [top] |
Threaded EPSG factories were added to GeoTools 2, but this work has been done in a context that resulted in lot of code duplication. In Geotk that work has been entirely rewriten, code duplication removed, some global locks removed for higher concurrency and some deadlocks removed. In addition the EPSG factory has been made compatible with PostgreSQL 8.3 and tested against latest EPSG database.
The EPSG factory benefits also from new capabitilies of the referencing module, notably NADCON support and a slightly wider range of projections.
| [top] |
A copy of the EPSG database is embedded in the
geotk-epsg module. This is no longer a dump of the HSQL database, but rather
a copy of the original SQL scripts except for a minor edition in Tables.sql,
more compact statements in Data.sql and the addition of Indexes.sql.
This allows more flexibility in two ways:
geotk-epsg.There is no longer different plugins for different databases (gt-epsg-hsql,
gt-epsg-postgresql, gt-epsg-access, gt-epsg-oracle,
etc.). The geotk-epsg module is used only for creating the
EPSG database when first needed. Once created, the geotk-referencing module
alone is suffisient for different kind of databases.
| [top] |
In GeoTools 2, MapProjection was a base class doing the full projection
process, including the conversion of (longitude, latitude) from
degrees to radians, scaling the projection result to the Earth's dimension and applying
the easting/northing offsets.
In Geotk all the above steps, which are linear, are delegated to affine transforms.
Consequently the base class is now concerned exclusively about the non-linear part, defined
as projections on an ellipse having a semi-major axis length of 1. The base class has been
renamed UnitaryProjection to reflect that fact.
The advantage of this approach is that affine transforms are easy to concatenate. With this new architecture, it is easier for Geotk to find the most efficient transformation path in a inverse projection - forward projection concatenation, for example when going from a Mercator projection to an other Mercator projection on the same ellipsoid. It is also much easier to implement projections having non-standard orientation, like South Orientated projections.
Developers who use the projections through the factory API are not affected by this
change, except for the performance and accuracy improvement in some cases. However vendors
who created their own implementations of MapProjection will need to adapt
their code.
| [top] |
Some parameter have different names depending on the map projection that use them, while serving the same purpose. For example "False northing" used in Lambert Conic Conformal (1SP) is called "Northing at false origin" in the 2SP case.
GeoTools 2 put all parameter names in the same bag. For example the two above names are declared for the same parameter no matter the projection using it. In Geotk, parameter names are declared on a case-by-case basis with only the relevant name for a given projection. Concequently WKT parsing in Geotk is stricter regarding the parameter names, and WKT formatting writes the correct names (GeoTools 2 writes the wrong names in many cases).
| [top] |
ProjectionException thrown
In GeoTools 2, any attempt to project a point outside the projection valid area result
in an exception being thrown. In Geotk, not-a-number (NaN) or infinite
values are returned when appropriate. For example applying the Mercator projection on the
North pole or the South pole now result in +∞ or -∞ respectively, while applying the
projection on a latitude further than 90°N or 90°S result in NaN.
The inverse projections are kept consistent with the forward projections. For example in the Mercator case, the inverse projection of +∞ or -∞ results in 90° and -90° respectively. This is verified by new test cases added to the build process.
Note that ProjectionException may still be thrown in some cases,
for example if an iterative calculation does not converge.
| [top] |
MathTransform providers moved
In GeoTools 2, MathTransformProvider were defined as static inner classes
named Provider and defined in the MathTransform class that they
build. Unfortunatly experience has show that math transforms and their providers do not
always have a one-to-one relationship. For example "Mercator1SP" and "Mercator2SP"
are two ways (and consequently two distinct providers) to define the same math transform.
In Geotk providers are defined in their own package, and their class name match the
OGC name.
| [top] |
In GeoTools 2 the user had to manually download the NADCON grids, save the files in a
directory of his choice and specify this directory to GeoTools by running the main method
of NadconTransform. In Geotk a Graphical User Interface is provided in
the geotk-setup module for
performing all those steps automatically. It also provides a central place where the user
can choose and download all data used by Geotk, not just NADCON grids.
In addition the downloaded NADCON grids are now automatically used by the EPSG-backed coordinate operation factory. Consequently the transformation of coordinates over the United States using NADCON grids is now available almost "out of the box", requirying only the execution of a graphical setup program.
| [top] |
ImageWorker trimmed down
API has been trimmed down, with fewer methods and less overloaded flavors of them. In
particular every ImageWorker method related to I/O operations was removed,
since their functionalities are expected to move in some Image I/O framework (to be
determined). Various methods doing almost the same thing like retainFirstBand(),
retainFirstBands(int), retainLastBand(), etc. were
consolidated in a single methods like retainBands(int,int).
In addition all methods returning this for chain method calls
purpose are now declared with void return type - so chain method calls are not
supported anymore. This was done in order to reduce the risk of confusion, given the large
amount of getter methods returning many different kind of values, and because we may want
to return some meaningful values in the future. For example the rescaleTo(int)
method could return the scales and offsets coefficients that it computed.
| [top] |
Axis2D package moved
The package org.geotools.axis moved to org.geotoolkit.display.axis
to better emphase that it is mostly a drawing tool. The coordinates changed from float
type to double type.
| [top] |
XML marshalling and unmarshalling in Geotk are totally different than what they were in GeoTools 2. Geotk uses the JAXB implementation bundled in Java 6 while GeoTools uses an Eclipse-based technology. In Geotk, developers marshall and unmarshall directly the metadata and referencing classes they use instead than intermediate classes generated automatically from the XML schema.
| [top] |