Adrian Custer a écrit :
Coverage seems confounded with imagery which I find confusing since
these are completely different ideas in Geospatial science. (Yes,
historically the two have often been associated but mostly because of
technological limitations not because of a logical dependency). In
2.2.RC2, module/coverage defines classes in three packages:
org.geotools.coverage
org.geotools.image
org.geotools.resources
org.geotools.resources should be ignored (no matter in which module they appears). It is a kind of
internal package, which contains some methods shared by more than one package (so they can't be
package-protected), but should be treated as if it were not public.
org.geotools.image contains stuff relying only on java.awt.image or javax.imageio API. So it should
not contains anything related directly to coverage (GeoAPI). It can been seen as a kind of low-level
processing stuff for coverage packages.
org.geotools.coverage is the package for coverage stuff. It is called "coverage" because it doesn't
need to be a grid (or an image). Actually the later is a special case of coverage called "grid
coverage". A coverage can be a purely mathematical function as well.
org.geotools.data.coverage could live in org.geotools.coverage.io (or something similar as well).
Personnally, I would prefer org.geotools.coverage.io. But this kind of package name change would
need to be discussed on a community level.
.../data/coverage/ which seems like an
unessary imposition on the nature of grids. Couldn't this be data/grid
instead?
Well, "coverage" is supposed to be more general than "grid" ("grid" is a special case of
"coverage").
module/referencing:
------------------
This is currently a grab-bag of different packages, many related to
geospatial measurement and science, some of strictly programming utility
(factories, maps (the coding structure)), lots of other stuff. Is there
any plan to refactor this into nice, self-coherent pieces?
The referencing module also contains the following:
metadata - because CRS need them, and metadata need CRS. In other words, both
metadata and
CRS are related, so it was not very convenient to split them in separated
module (but it
could be done if peoples really wish).
parameter - because CRS need them. Actually, the parameter stuff was
originally defined in
ISO 19111 (the ISO specification about CRS stuff). We generalized it a little
bit in GeoAPI,
but CRS still its mean user.
nature - this very small package is actually not used anywhere in Geotools,
and not really
that much GIS relevant. The JScience project (www.jscience.org) would
actually be a more
appropriate location for those small classes than in the Geotools project. I
already offered
those class to the JScience project and the project ower accepted them, but I
didn't had the
time to make the move yet.
Except for the org.geotools.nature package that I would like to move to the JScience project (but I
guess that nobody use this package anyway), the referencing module is very stable and has no planned
refactoring at this time, unless users ask for some changes.
Martin.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
