Hello all
I noticed that two new experimental modules, "arcgrid" and "ArcGrid_ImageIO"
have been commited to
trunk. Thanks for commiting them on trunk; it make easier for me to take a look
at them soon (I tend
to look at branches much least frequently than trunk). I would like to share
the following though:
* Would it be better to put those modules in "plugins" rather than "ext",
since they looks like Image I/O and GridCoverageExchange plugins to me?
* Since I do not expect "ArcGrid_ImageIO" to be a huge module, and since I
do not expect
most of the other pure-Java Image I/O modules to be huge neither, would it
make sense
to create a plain "plugin/imageio" module instead and put ArcGrid as well
as any other
"reasonably sized" image I/O plugins there? I would prefer a ~500 kb
module instead than
dozen of ~50 kb modules. Of course if a particular plugin produces a big
JAR file alone,
or if a set of plugins are mutually exclusive (for example users typically
use only one
of "epsg-access", "epsg-postgresql" or "epsg-hsql" - choosing one usually
exclude the
others), or if a plugin has a large amont of dependencies that are unique
to this plugin,
then this particular plugin may live in his own module. But otherwise I
would like to
avoid a multiplication of small JAR files.
* Same for "ext/arcGrid". Would it make sense to create a plain
"plugin/coverageio"
module instead?
* Minor note: "ext/ArcGrid_ImageIO" contains "project.xml" and
"run-maven.xml" files,
which are remanescence of the old Maven 1 build system and should be
deleted. Only
"pom.xml" and "LICENSE.txt" should be left in this directory.
* The current package names are:
- org.geotools.gce.imageio.asciigrid
- org.geotools.gce.arcgrid
Can I suggest the following package names instead?
- org.geotools.image.io.<something>
- org.geotools.coverage.io.<something>
Rational:
- "gce" stands for "GridCoverageExchange", which is a name from the
legacy OGC 01-004
specification. The new ISO 19123 specification has nothing similar. I
don't know if
ISO will come with some equivalent classes. But we can said that the
future of the
"GridCoverageExchange" name is not assured.
- "org.geotools.image.io" and "org.geotools.coverage.io" already exist
in current
packages naming. We may have some advantages in leveraging the
existing packages.
- "org.geotools.coverage.io" make clear that this is about I/O of
Coverage objects,
and the relationship with the "org.geotools.coverage" package is
obvious. This is
not true for "org.geotools.gce".
- "org.geotools.image.io" make clear that this is about I/O of
RenderedImage objects,
and the relationship with "org.geotools.image" is obvious. It also
make clear that
Image I/O do not (or should not) depend on coverage ("Coverage"
depends on "Image",
but we should avoid dependency the other way). The
"org.geotools.gce.imageio" name
suggests a relationship with "GridCoverageExchange" that I would like
to avoid. I
think that Image I/O should be independent of coverages as much as we
can.
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&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
